Showing results for 
Search instead for 
Did you mean: 

Wireless Clients get disconnected

I have a wireless client getting disconnected but I don't know what is causing the disassociation. Problem is, the client gets disconnected while the customer is working - it takes some time to reconnect, cause the WLC / client is stuck some time in doing new DHCP reassignment after reassociation. Attached the log part - question is : How to find the reason for disconnecting "

Sent Disassociate to mobile on AP e8:ba:70:61:45:80-0 (reason 1, caller apf_ms.c:5558)"

*spamApTask6: Sep 03 16:54:51.529: 68:a8:6d:15:e2:54 Cleaning up state for STA 68:a8:6d:15:e2:54 due to event for AP e8:ba:70:61:45:80(0)

*apfReceiveTask: Sep 03 16:54:51.530: 68:a8:6d:15:e2:54 apfSendDisAssocMsgDebug (apf_80211.c:2162) Changing state for mobile 68:a8:6d:15:e2:54 on AP e8:ba:70:61:45:80 from Associated to Disassociated

*apfReceiveTask: Sep 03 16:54:51.532: 68:a8:6d:15:e2:54 Sent Disassociate to mobile on AP e8:ba:70:61:45:80-0 (reason 1, caller apf_ms.c:5558)


Do you know if you are using Event Driven RRM? It's possible there is aggressive channel changes taking place on the 3502, where-by your client would be deauthenticated (then most likely roam to next best candidate/other AP you mentioned).  Do you have any inteferers detected by the 3502i AP in question?  MONITOR > CleanAir > 802.11a/n or 802.11b/g/n > Interference Devies and AirQuality Report.  Is Event Driven RRM enabled?  WIRELESS > 802.11b/g/n or 802.11a/n > DCA > "Event Driven RRM"

If this is on, I would suggest turning it off, unless you have a full CleanAir deployment.  Whether you let CleanAir force an immediate channel change due to AirQuality  (and only on the CleanAir capable AP will it change immediately, as the others will only change once an RRM/DCA interval is reached), or you suffer with interference, it could lead to a client disconnect.  The client should be able to re-associate immediately upon channel change, but may just move over to the next heard AP (a ways away) as you described.

If the debug truly only shows the entries in the original post, it would be helpful to have a wireless sniff on the APs channel along with another debug (started before the client ever associates).  Channel changes would be reported in the traplog of the WLC, so you can look at your traplog through the GUI or ">show traplog" on CLI and parse for channel changes.

Since 7.2 allows 2 clients to be debugged, you may enable debug client for AP and the Client, and then turn on RRM debug for DCA
>debug airewave-director channel

or for more extensive RRM info

>debug airewave-director all

I'm not sure how this will behave (ie, if it will only show RRM details for the AP specified in the 2nd debug client-- you would just have to try and see.)

You can also enable telnet/ssh to the AP and directly run (these "should" work)

#debug dot11 mgmt station

#debug dot11 mgmt msg

#debug dot11 mgmt state-machine

thanks for hints - that's some work. I will start monday, out-of-office for 3 days.

Event  Driven RRM is off - I know it. Clean Air is enabled. I will try to  debug AP / Client in parallel and follow some steps you described,  thanks so far to all. I get back to you next week.

You could try upgrading to 7.2.110. Why just last week Cisco TAC informed me "7.2.103 was plagued with bugs".

There's also the option of running the same software that was on the 4400's. In theory if you configure all settings the same as the 4400's and are running the same software the migration should be completely transparent.

From there you could upgrade to a stable 7.x.x...



Content for Community-Ad