12-16-2005 08:18 PM - edited 07-04-2021 11:25 AM
I'm troubleshooting a problem with excessive disassociations and reassociations even on fixed, immobile wireless clients. The wireless network is lightweight with a 4402-25 controller and upgraded 1200-series APs. My client is an integrated Intel 2200BG wireless NIC with driver version 9.0.3.9, Odyssey Client and PEAP-GTC.
Output from a 'debug dot11 all' on the controller reveals this information...
Sat Dec 17 03:27:32 2005: Scheduling deletion of Mobile Station: 00:0e:35:c6:88:
9e (callerId: 1) in 10 seconds
Sat Dec 17 03:27:42 2005: Changing state for mobile 00:0e:35:c6:88:9e on AP 00:1
4:f2:62:b3:a0 from Associated to Disassociated
Sat Dec 17 03:27:42 2005: Sent Disassociate to mobile 00:0e:35:c6:88:9e on AP 00
:14:f2:62:b3:a0-0 (reason 4, caller apf_ms.c:2109)
Sat Dec 17 03:27:42 2005: Scheduling deletion of Mobile Station: 00:0e:35:c6:88:
9e (callerId: 45) in 10 seconds
Sat Dec 17 03:27:42 2005: Updated location for station 00:0e:35:c6:88:9e - old A
P 00:00:00:00:00:00-0, new AP 00:14:a8:6e:bc:c0-0
Sat Dec 17 03:27:42 2005: Association received from mobile 00:0e:35:c6:88:9e on
AP 00:14:a8:6e:bc:c0
Sat Dec 17 03:27:42 2005: Changing state for mobile 00:0e:35:c6:88:9e on AP 00:1
4:a8:6e:bc:c0 from Disassociated to Associated
Sat Dec 17 03:27:42 2005: Stopping deletion of Mobile Station: 00:0e:35:c6:88:9e
(callerId: 48)
Sat Dec 17 03:27:42 2005: Sending Assoc Response to station 00:0e:35:c6:88:9e on
BSSID 00:14:a8:6e:bc:c0 (status 0)
Sat Dec 17 03:27:42 2005: Changing state for mobile 00:0e:35:c6:88:9e on AP 00:1
4:a8:6e:bc:c0 from Associated to Associated
This type of activity occurs regularly with the client cycling through various APs on the network with varying RSSI and SNR values. Very puzzling! Any ideas what might be happening?
Thanks in advance!
07-24-2007 08:39 AM
Hello,
Were you ever able to figure out what was happening? I am having a similar issue with some ebox's using prismiq drivers on debian. This one has me stumped. Using a WLC 4404-50 and same model AP's
07-24-2007 08:57 AM
We actually did finally figure out the problem with the help of a programmer that Cisco dispatched to the site. It turns out there was a bug in that particular revision of code (3.2.x something) that incorrectly interpreted a certain message coming from Intel clients. An emergency revision of code fixed the issue. Sorry I can't be more specific relative to the exact message but I don't remember much of the detail.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide