Clients disconnected from WLC randomly

Question

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.

Answer 1

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.