03-20-2014 02:29 PM - edited 07-05-2021 12:29 AM
We are experiencing an issue with clients getting disconnected/time out from a wlan doing CWA. The clients are iphones. A debug client shows the error(Unknown Policy Timeout). This particular WLAN is used for provisioning with ISE. ISE shows the user authenticated the entuire time. At first, we though it was the user idle timeout setting on the WLAN advanced tab, but after increasing that clients still get disconnected. The disconnect occurs around 2 minutes. Sometimes longer around 10 minutes. Cisco seems to think we are hitting a bug introduced in 7.3.112 and will not be fixed until 8.0. Below are the bug details and the debug output. Has anyone seen this? Any possible work-arounds? Thanks.
(Cisco Controller) >debug *apfMsConnTask_7: Mar 20 17:19:02.573: Association request from the P2P Client Process P2P Ie and Upadte CB
*apfMsConnTask_7: Mar 20 17:19:02.765: Association request from the P2P Client Process P2P Ie and Upadte CB
*apfReceiveTask: Mar 20 17:20:40.442: 18:af:61:bb:55:2f 10.200.21.0 RUN (20) Unknown Policy timeout
*apfReceiveTask: Mar 20 17:20:40.442: 18:af:61:bb:55:2f 10.200.21.0 RUN (20) Pem timed out, Try to delete client in 10 secs.
*apfReceiveTask: Mar 20 17:20:40.443: 18:af:61:bb:55:2f Scheduling deletion of Mobile Station: (callerId: 12) in 10 seconds
*osapiBsnTimer: Mar 20 17:20:50.443: 18:af:61:bb:55:2f apfMsExpireCallback (apf_ms.c:615) Expiring Mobile!
*apfReceiveTask: Mar 20 17:20:50.443: 18:af:61:bb:55:2f apfMsExpireMobileStation (apf_ms.c:5835) Changing state for mobile 18:af:61:bb:55:2f on AP 54:78:1a:2f:84:50 from Associated to Disassociated
*apfReceiveTask: Mar 20 17:20:50.443: 18:af:61:bb:55:2f Scheduling deletion of Mobile Station: (callerId: 45) in 10 seconds
*osapiBsnTimer: Mar 20 17:21:00.442: 18:af:61:bb:55:2f apfMsExpireCallback (apf_ms.c:615) Expiring Mobile!
*apfReceiveTask: Mar 20 17:21:00.443: 18:af:61:bb:55:2f Sent Deauthenticate to mobile on BSSID 54:78:1a:2f:84:50 slot 1(caller apf_ms.c:5929)
*apfReceiveTask: Mar 20 17:21:00.443: 18:af:61:bb:55:2f Setting active key cache index 8 ---> 8
*apfReceiveTask: Mar 20 17:21:00.443: 18:af:61:bb:55:2f Deleting the PMK cache when de-authenticating the client.
*apfReceiveTask: Mar 20 17:21:00.443: 18:af:61:bb:55:2f Global PMK Cache deletion failed.
*apfReceiveTask: Mar 20 17:21:00.443: 18:af:61:bb:55:2f apfMsAssoStateDec
*apfReceiveTask: Mar 20 17:21:00.443: 18:af:61:bb:55:2f apfMsExpireMobileStation (apf_ms.c:5967) Changing state for mobile 18:af:61:bb:55:2f on AP 54:78:1a:2f:84:50 from Disassociated to Idle
https://tools.cisco.com/
Symptom:Wireless devices are randomly disconnected every 5-10 minutes with unknown policy timeout message in debug client
Conditions:Clients using Central Web Authentication (CWA).
Workaround:none
More Info:
12-20-2019 03:27 AM
I use the version
Software Version 8.3.150.0
Field Recovery Image Version 6.0.182.0
the problem only occurs with one of the APs,
We switched to another AP, with the same settings, and the problem remained. the SSID is the same as in others.
I believe then that the iPad may have requested the disconnection due, unable to download file from the server.
12-20-2019 06:28 AM
Hi,
So the software is newer, but the FUS image is older based on the field recovery image output. You might consider upgrading it.(that is not related with the issue though)
Try logging in the AP and check the logs there. Check if there isn't any containment going on for this AP.
Probably a bad RF situation and the device is dropping when the AP is changing channels. See if you set it to only one static channel if the drops will continue. (note that this might lower the wireless quality, but for testing purposes is okay.)
Is this happening for all iPads or devices that connect to this AP?
What is the AP model?
12-20-2019 07:18 AM
Is this happening for all iPads or devices that connect to this AP?
all devices connect to this AP have the same problem. (disconection)
What is the AP model?
Cisco Aironet 2600 Series (IEEE 802.11n) Access Point
observation.:
I have a policy based routing, so that all traffic coming from this AP, go out the secondary link.
12-21-2019 08:22 AM
Hi,
Happy weekend :D
Disconnections are not affected by the PBR I guess.
One reason might be the AP dropping from the WLC or just being contained. If you have other APs around this one, just disable it and let the users run.
Other than that, as I told you, login in the AP and check the logging for containment logs.
Note that this is only an assumption.
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