Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

Clients disconnected from WLC randomly

Hi,

 

I'm doing some tests with clients to see how much time they are kept registered in the controller while they are disconnected. I've set session timeout to 0 (infinite) and user idle timeout to 12 hours. 

The problem is that sometimes the clients are disconnected from the controller before the user idle timeout expires:

apfMsDeleteByMscb Scheduling mobile for deletion with deleteReason 6, reasonCode 1

 

Other times they are expired normally by the user idle timeout (deleteReason4,reasonCode4).

 

If I am not wrong deleteReason 6 corresponds to manual deletion of the client, but there is no manual interventention when this happen, is the controller who deletes it.

Can anybody explain why this happens randomly?

 

WLC version 6.0.196

 

Thanks.

 

 

 

 

 

 

 

 

4 REPLIES
VIP Purple

is it possible to upgrade WLC

is it possible to upgrade WLC to 7.0.250.0 & check. Here is the release notes for that & you can do a direct upgrade to that code.

http://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn70mr5.html

 

HTH

Rasika

*** Pls rate all useful responses ****

Community Member

Yes, it could be possible to

Yes, it could be possible to do the upgrade, but I would like to know if there is a real reason for that deauthentication or it is a reported bug. If anybody knows that, please let me know.

 

Thanks.

VIP Purple

Hi Upgrade to a supported

Hi 

Upgrade to a supported version always recommended.

Regarding the deauth code you can refer below

https://supportforums.cisco.com/document/141136/80211-association-status-80211-deauth-reason-codes

Code802.11 definitionExplanation
0ReservedNOT SUPPORTED
1Unspecified reasonTBD
2Previous authentication no longer validNOT SUPPORTED
3station is leaving (or has left) IBSS or ESSNOT SUPPORTED
4Disassociated due to inactivityDo not send any data after association;

 

HTH

Rasika

 

Cisco Employee

Refer the 2 Bugs :Unified APs

Refer the 2 Bugs :

Unified APs removing clients on maximum retries.
CSCti91944
Description
Symptom:
 
A wireless client might be removed from the mobility database before the user idle timeout. When this happens, if "debug client MAC" is in effect, messages similar to the following are seen on the WLC:
 
*spamApTask3: clientmacaddrXYZ Received Idle-Timeout from
AP macADDR-abc slot 0 for STA XYZ Client MAC ADDR
*spamApTask3: apfMsDeleteByMscb Scheduling mobile for deletion with
deleteReason 4, reasonCode 4
 
The symptoms, as experienced by the user, depends on the behavior of the client device and on the WLAN configuration as follows:
 
- If the WLAN is configured for web-auth, the client is forced to reauthenticate through the web.
 
- If the WLAN is configured for L3 mobility and if the client performs an L3 roam at the time of the removal, the client's old IP address in the old subnet is no longer valid, and the client is forced to re-DHCP in the new subnet. Any existing TCP connections fail to work expected. If the client is a 792x wireless phone on a call, the talk path is lost for the remainder of the call.
 
- If the WLAN is configured for L2 mobility, then the client is forced to perform a full EAP authentication (if EAP is configured) and to re-DHCP (if DHCP required is configured). In most cases, this does not cause a perceptible service interruption, unless the client's IP address changes.
 
Conditions:
 
This occurs when an access point fails to transmit 250 consecutive packets to the client (if there are 64 failed retransmits per packet, which means 4 consecutive dropped packets, it triggers the deauth).
 
Examples:
 
- Client radio is temporarily disabled.
- Client has gone into hibernation/standby.
- For a voice client, if the client is in a call and is unable to receive audio packets for a fraction of a second.
 
Workaround:
 
None; however, reconfiguring the WLAN for layer 2 rather than layer 3 mobility can mitigate the effect.
 
Known Affected Releases:
(3)
7.0(98.0)
6.0(199.0)
6.0(199.4)
 
Clients hit Idle timeout after successful authentication
CSCue34763
Description
Symptom:
A wireless client, while associated/authenticated (in RUN state), will be
prematurely idle timed out by an AP. With "debug client" in effect on the
WLC, messages similar to the following are seen:
 
*spamApTask2: Jan 30 17:10:17.258: 00:11:22:33:44:55 Received Idle-Timeout from
AP 84:78:ac:00:11:22, slot 1 for STA 00:11:22:33:44:558
*spamApTask2: Jan 30 17:10:17.258: 00:11:22:33:44:55 apfMsDeleteByMscb
Scheduling mobile for deletion with deleteReason 4, reasonCode 4
 
The idle timeout event occurs while the client is not idle, and more rapidly,
after the client's last reassociation, than the configured user idle timeout
value.
 
Conditions:
 
Flexconnect (H-REAP) local switching is configured, with DHCP Required.
 
Workaround:
Clients hit Idle timeout after successful authentication
CSCue34763
Description
Symptom:
A wireless client, while associated/authenticated (in RUN state), will be
prematurely idle timed out by an AP. With "debug client" in effect on the
WLC, messages similar to the following are seen:
 
*spamApTask2: Jan 30 17:10:17.258: 00:11:22:33:44:55 Received Idle-Timeout from
AP 84:78:ac:00:11:22, slot 1 for STA 00:11:22:33:44:558
*spamApTask2: Jan 30 17:10:17.258: 00:11:22:33:44:55 apfMsDeleteByMscb
Scheduling mobile for deletion with deleteReason 4, reasonCode 4
 
The idle timeout event occurs while the client is not idle, and more rapidly,
after the client's last reassociation, than the configured user idle timeout
value.
 
Conditions:
 
Flexconnect (H-REAP) local switching is configured, with DHCP Required.
 
Workaround:
 
Disable DHCP required.
 
Disable DHCP required.
960
Views
0
Helpful
4
Replies
CreatePlease to create content