Connectivity Problem with SRC 300mw MMCX

[jmeyerhoffer]

Hello everyone, forum newb here looking for a bit of help. I am an IT Analyst at a major Hospital and we are using the Ubiquiti SRC 300mW 802.11a/b/g MMCX PCMCIA cards in HP Laptops running XP-SP3 inside rolling carts (FLO 1800's) with external antennas. We are using EAP-TLS Authentication for Wireless Network Access. We have over 500 of these devices deployed in our environment and these carts are used by the Doctors and Nursing staff to access Hospital applications, Patient Records, etc. They require Intranet AND Internet access.

We are having a MAJOR problem with these devices staying connected to the network. We have experienced a problem with the Mobility 7.7 driver when installed, the card will search for the Farthest signal from it, rather than attempt to connect to the strongest closest signal. Using the supplicant utility, we have verified this is occuring because we can see the device jump to an AP farther away than one we are next to.

This problem is so bad, we have been forced to use a different driver (Atheros v7.6.1.244) and supplicant to get the device to grab the appropriately stronger signal. The two problems with this are;

1- this driver, while correct to the chipset, is NOT from Ubiquiti and therefore changes the identity of the card in Windows to an Atheros AR5004X Wireless card. This obviously creates a support issue with Ubiquiti, but until we can find a solution to the strange behavior of the 7.7 Mobility driver, using the other driver/supplicant is our only option to maintain a reasonable level of network connectivity.

2- Regardless of which driver we use, we are still experiencing continued random drops from the network. The devices have no trouble connecting to the Encrypted hospital network, but at some later point, for whatever reason, they will dissassociate from the network and cannot reassociate on their own. We are then forced to go out to the device and physically reconnect the device to the WIRED network and reboot the Laptop to regain connectivity to the encrypted wireless network.

My question is, is there a way to change the behavior of the card using the 7.7 driver, to stop looking for the farthest signal, and use the closest instead, and what should we be looking at to address the random drop outs???

Also of note, while we have the utility installed, and selected to control the card with the utility, we ARE using the Windows Wireless Zero Config Service because of Active Directory and Group Policy requirements. Will the card support a manual config utilizing Active Directory so we can eliminate the WZC Service from the equation completely to troubleshoot? My goal is to use the supplicant utility MINUS the WZC to control the card, but based on our current infrastructure setup, we are dependent on the WZC Service to maintain connectivity to the Encrypted network.

Help, thoughts or ideas anyone??? We REALLY need help with this weird driver behavior.

I will be happy to provide as many details as possible if you have questions, but we REALLY need a solution as quickly as possible as the uptime on these devices is steadily decreasing. PLEASE HELP!!! :(

[cwong]

Hi Jmeyerhoffer,
We have the SRC 300mw running for almost half year on the test bench without any problem, but recently we experienced similar problem at our client site. After the SRC has been running for a few days, it will drop out the network and would not authenticate until we reboot it.
Our SRC is running on XP, Mobility Driver 7.7 with WZC turned off. WEP security with Authentication Mode set to Auto. The Access Point is set to Open in Authentication Mode.

More detailed setting as follow:
11a Transmit Rates: 54 Mbs
11b Transmit Rates: 11 Mbs
11d Mode Switch: Enable
11g Transmit Rates: 54 Mbs
802.11 Authentication Type: Auto
802.11b Preamble: Long and Short
Antenna Diversity: Fixed-A
Auto Transmit Rate: On
Background Scan: On
Background Scan Max Deferral Time: 500
BSS Aging Period: 20
Calibration Period: 30
Clear List on Scan: Off
Country Code: United States
Extended Channel Mode: Disable
Fragmentation Threshold: 2346
Hardware Tx Retries: 4
Map Registers: 256
Network Address: Not Present
No Beacon Timeout: 500
Power Save Mode: Off
Radio On/Off: On
Roaming Rate 11A: 24000
Roaming Rate 11B: 5000
Roaming Rate 11G: 9000
Roaming Rssi 11A: 24
Roaming Rssi 11B: 24
Roaming Rssi 11G: 24
RTS Threshold: 2346
Scan Time Pre-Sleep: 300
Scan Type: Any
Scan Valid Interval: 60
Sleep Time Post-Scan: 60
Software Tx Retry Scale: 6
Transmit Power: 100%
Wi-Fi Multimedia: On

We're going to try changing the Authentication Mode to match the AP as Open and see if the problem would goes away. Please keep us posted if you found a cure.

Thanks.

CWong

[jmeyerhoffer]

We've been able to determine, through careful inspection of Cisco WCS logs and various other tools that our Authentication process is partly responsible. Because we are using EAP/TLS Authentication, we have discovered that we have a problem with our Radius Server (Certificates). Our EAP process is a 12 step process, and step #9 "Recieving access-accept from Radius server is where we're experiencing trouble.

However, this still does not explain the issues we're having with the Ubiquiti Mobility 7.7 Driver. We are still experiencing the odd behavior where once this driver is installed, the client will jump from the closest AP to the farthest. We can be standing within 10 feet of an AP point with a client, and visually confirm the client will attempt to connect to one farther away. Is this a driver anamoly or a settings issue?

Any ideas on this? We cannot deploy our client devices with the 7.7 Driver as long as it is still exhibiting this behavior.

[cwong]

I use to maintain 900MHz network at the steel mill for a few years. I experienced similar problem like yours all the time. Seem like you need to do a site survey and see how much signal coverage overlapping. Wrong antenna, too strong of signal and multi-pathing will cause the client card problem on determine the best AP.
Try decrease the signal strength of the AP as well as your Ubiquiti radio card. In door wireless is not as easy as outdoor.
I ended up removed a few of the Yagi antenna in the steel mill and changed them to wall patch or omni-directional to solve the problem. For indoor wireless structure, you want more AP rather than stronger AP.
With more AP, the signal coverage won't be affecting by the furniture layout as much. With fewer but stronger AP, the movement of big furniture will affect the coverage that was once perfectly fine.

[WHT]

jmeyerhoffer...

How many APs per floor, or better to ask - what is the distance between APs?

[jmeyerhoffer]

It's a hospital environment, so there are several AP's per floor depending on the building. In our newest building (Critical Care) we have 4 AP's per floor, the floor being divided into 4 quadrants. In most cases, there is significant overlap, as due to previous connectivity problems, the AP's have been turned up, and are blasting out signals probably hot enough to cause Brain Tumors. (joking)

But I am curious about this, because despite the overlap, the cards seem to do well using the Atheros 7.6 Driver (the one we use is hosted by Fujitsu for AR5004X) and supplicant, and do not show this tendency to hunt for the farthest signal. As soon as you change the driver however, you can actually watch the client switch to a different AP that is farther away. It does this consistently using the 7.7 driver.

Getting the AP's turned down is probably a losing battle here as the whole approval process for a change like that is horrendous, but the first thing they'd say if we asked to turn them down is, "Why do they work fine with the Atheros driver?" Is there something in the supplicant settings I am missing to adjust this behavior?

[cwong]

Did you try playing with the roaming setting? I don't know much about it but I would start from Low on romaing.

[oneofthefew]

roaming usually requires at least 20% overlap in a microcell architecture. if you do not have this amount of overlap then most applications that require roaming, like VoWLAN, will drop whilst moving between cells

have you considered virtual cell/single cell technologies from Meru or Extricom: i would look at Meru! http://www.merunetworks.com/ by using virtual/single cell technolgies you don't have to worry about roaming, as you authenticate through the AP to the controller, which provides you with continuity of session.

like WHT says you would have know how many APs, what height they are installed at and what distance they are apart - AP distance also depends on construction method ie brick, breeze block, plasterboard (drywall) etc

also it does matter if they are wall or ceiling mounted and whether they have internal/external antenna - this comment is based around the antenna mask pattern

for info - this is only a guide!:

802.11b/g internal coverage is approx 30m
802.11a internal coverage is approx 27m
802.11n internal coverage is approx 70m

hope you manage to get you problem resolved

:D

p.s. you mentioned that you have a 12 step process? usually its only 6

1) "New AP" Discovery.
2) EAP authentication initiation.
3) Re-Association with "New AP".
4) Authentication method processing.
5) Key exchange (EAPOL).
6) QoS - This is optional

[paulzinda]

I have some insight you'll find very helpful regarding this client roaming in healthcare environments.

Call me anytime - 502.500.0000.

- Paul