Nightmare-ish wireless situation

Unanswered Question
Aug 24th, 2007

I'm having a wireless problem with one of the sites I have to support. Before anyone scolds me about a site survey ;-)

We sort of inherited this setup from the customer when we took over their network and it never really has worked correctly. I'm trying to avoid telling them to hardwire their PCs.


The site is a Manufacturing facility with a corrugated metal roof, 25 ft cielings and large power transformers. There are two access-points that serve the manufacturing floor, one on either side of the building mounted about 10ft off the ground on poles. There's another access-point that serves the lobby and conference room, for a grand total of 3 APs. All three APs are Model: AIR-AP1231G-A-K9 with (I believe, I havent actually been to the site) stock antennas. The APs are all connected to the same switch with the same VLANs (One for Guests [internet only] and one for internal clients).


As for security, the clients authenticate via Certificates that are verified with the Radius Server / Active Directory.

The issue is that clients tend to not stay associated with their AP, they roam from AP to AP. Is there any way to keep clients (Intel Wireless cards for the most part) from roaming to another AP? Is there somthing I can configure on the APs to make them stick? We've tried adjusting power on the APs as well as different antennas (Directional vs omni).

Here's a sample of what we get from the logs:

Aug 24 14:41:54.608: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0018.391a.abe4 Associated KEY_MGMT[NONE]

Aug 24 14:44:48.438: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0004.2399.b809 Associated KEY_MGMT[NONE]

Aug 24 15:07:07.773: %DOT11-6-ROAMED: Station 000f.3da9.fa87 Roamed to 0012.0019.9700

Aug 24 15:07:07.773: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 000f.3da9.fa87

Aug 24 15:08:08.767: %DOT11-4-MAXRETRIES: Packet to client 0018.391a.abe4 reached max retries, removing the client

Aug 24 15:08:08.767: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0018.391a.abe4 Reason: Previous authentication no longer valid

Aug 24 15:08:12.934: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0018.391a.abe4 Associated KEY_MGMT[NONE]


To me it looks like interference issues because I'm seeing quite a few output errors on the radios. Any Ideas how I can fix this problem? Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (2 ratings)
Loading.
chris-marshall Fri, 08/24/2007 - 07:30

Hey rtjensen4!


I'm sure someone is going to smack me for saying it... but since you mentioned 'Intel' I'm immediately wondering if the drivers on your cleint's laptops are up to date. Old Intel drivers are flaky at best.


Also, how are your APs channeled? Are they selecting the least busy channel on their own, or are you setting them manually?


-Chris

rtjensen4 Fri, 08/24/2007 - 07:33

Sorry for not including that, an oversite on my part.

The APs are manually set (as part of troubleshooting) to channels 1,6, and 11.


The Clients have had their drivers updated as well as firmware. Have also tried deleting security certificate and getting a new one. No Luck. Thanks.

zhenningx Sat, 08/25/2007 - 06:37

On the client card "Advanced" setting, I believe there is a option called "Roaming Sensitivity". If you set it to minimum, that might help.


Zhenning

andrew.brazier@... Sun, 08/26/2007 - 01:51

Zhenning is correct, there is a setting in the Itel card utility to make the client more "sticky"so it hangs on to it's chosen AP more readily.


Client roaming is almost entirely controlled by the client, there's very little you can do to the config of the APs to control how or when a client roams.

mscherting Wed, 08/29/2007 - 12:47

I've seen those same log entries on some of my 1231s. In one case it turned out to be a very hot, narrow band signal on channel 12. I moved the AP to 6.


Have you wandered around the site with a spectrun analyzer? The Wi-Spy Chanalyzer is a cost effective (cheap) analyzer that does work, but only on b/g.


You may be able to get away from the interference by upgrading the APs to a/b/g by installing A radio modules. Clients will need to support A too.

jake.kappus Thu, 08/30/2007 - 18:55

I just dealt with this same problem and environment with a customer last week. The max retries tells me that it's interference, most likely multipath.


I would lower your fragmentation and RTS thresholds to as low as you can go. I've heard you can go as low as 300, but I did 1024 just to be safe. Also, if you can, turn the power down on those AP's as far as you can while maintaining coverage levels. A good hot signal isn't always best in these environements.


The clients are sensing a lot of interference and then jumping to the next AP even though it may have a lower signal. It's signal quality and SNR ratio's that it's really looking for.


Try those things out. I did last week and so far we've been doing much better.

Actions

This Discussion

 

 

Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode