topic Hi Upgrade to a supported in Wireless

Clients disconnected from WLC randomly

Oscar Falcon Ortiz — Mon, 05 Jul 2021 08:55:30 GMT

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.

is it possible to upgrade WLC

Rasika Nayanajith — Wed, 12 Nov 2014 17:59:00 GMT

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 ****

Yes, it could be possible to

Oscar Falcon Ortiz — Thu, 13 Nov 2014 13:33:59 GMT

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.

Refer the 2 Bugs :Unified APs

mohanak — Thu, 13 Nov 2014 13:47:43 GMT

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.

Hi Upgrade to a supported

Rasika Nayanajith — Thu, 13 Nov 2014 18:26:11 GMT

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

Code	802.11 definition	Explanation
0	Reserved	NOT SUPPORTED
1	Unspecified reason	TBD
2	Previous authentication no longer valid	NOT SUPPORTED
3	station is leaving (or has left) IBSS or ESS	NOT SUPPORTED
4	Disassociated due to inactivity	Do not send any data after association;

HTH

Rasika