Client unexpectedly stoped to join AP

[slyfox]

Dear Community, 

please help to find out what could be a reason for an issue we have. One of the clients today morning unexpectedly failed to join the wireless network. Up to this point, the client has been connected to this network for over a year every day. All other clients work seamlessly. There were no client-side or network configuration updates.

Was done client debug on WLC side by doing debug client 84:C5:A6:3F:97:06

result of debugging attached

[slyfox]

After additional analysis of all clients who were in the zone of reliable coverage of a  signal from AP, we came to the conclusion that they jumped to another access point of the same SSID, thereby continuing normal work. Everyone who tried to connect to the ssid at the problem access point fell into an error. The specified access point was rebooted and the connection problem was gone. 
But what could be the reason for this behavior of the access point?

[Leo Laohoo]

Is the controller running on 8.10.X.X?

[slyfox]

Hello @Leo Laohoo  software version 8.10.130.0

WLC 3504

affected AP AIR-CAP3702I-E-K9

[Leo Laohoo]

---

@slyfox wrote:

Hello @Leo Laohoo  software version 8.10.130.0

---

Reboot the affected AP and try again.  It could be CSCvw30043.

[slyfox]

The bug description says about the WLAN-based session timeout and we have it disabled at all. 

[slyfox]

I have found another community thread similar to mine https://community.cisco.com/t5/wireless/wireless-disconnections-on-mac-clients/td-p/3710145

You advise disabling FT is it still relevant? 

[Scott Fella]

Well, it seem like the ap maybe was just hung or in a failed state.  Sometimes these things happen, who knows why unless you spend time to debug and collect logs.  Hate to say it, sometimes a reboot is the fix to many things, I sure have done that workaround many times.  At least now you know and maybe if you detect something, your quick fix is to just bounce the ap.  You can also take a baseline and see how many clients are connected per day on each band.  This can help when you run reports or decide to make sure that you have clients connected.  I have used Prime to capture this for me but any NMS tool can possible provide you with that information.

[marce1000]

 Ref : https://cway.cisco.com/wireless-debug-analyzer/

                   Using your debug file gives :

Select a client MAC Address and connection to see logs.

Download CSV

Connection 1 of 2

•  
•  
• 1
• 2
•  
•  

---

Show Time

Show Task

Show Translated

Show Original

Show Prior First Connection

Show All

---

TimeTaskTranslated

May 24 12:47:05.861	*apfMsConnTask_1	Client made new Association to AP/BSSID BSSID 00:c1:64:b4:f8:a8 AP Production
May 24 12:47:05.862	*apfMsConnTask_1	The WLC/AP has found from client association request Information Element that claims PMKID Caching support
May 24 12:47:05.862	*apfMsConnTask_1	Client is entering the 802.1x or PSK Authentication state
May 24 12:47:05.862	*apfMsConnTask_1	Client has successfully cleared AP association phase
May 24 12:47:05.862	*apfMsConnTask_1	Client is entering PSK Dot1x or WEP authentication phase
May 24 12:47:05.862	*apfMsConnTask_1	WLC/AP is sending an Association Response to the client with status code 0 = Successful association
May 24 12:47:05.866	*Dot1x_NW_MsgTask_6	4-Way PTK Handshake, Sending M1
May 24 12:47:05.866	*spamApTask1	Client delete code: AP idle timeout, AP triggered client deauth That can be due to possible reasons: Wired guest client has expired (no traffic)/ Default event for AP side triggered client delete. Normal scenarios would be idle timeout, AP radio issues, channel changes, etc.
May 24 12:47:05.866	*spamApTask1	Client expiration timer code set for 1 seconds. The reason: Dissasociation or deauthentication received from client, this is valid on 802.11w scenario. Also, generic termination clause, reason would be provided by pervious log message
May 24 12:47:06.698	*apfReceiveTask	Client session has timed out
May 24 12:47:06.698	*apfReceiveTask	Client session has timed out

[saravlak]

Are one client or all client impacted to the AP in question before AP reboot.

It appears 4-way handshake is broken. it could be AP or client related until proven.

if its one time issue I'll move on, otherwise when issue reproduced involve cisco TAC to isolate the issue rather speculative.

Otherwise, upgrade to the latest 8.10.X.X.

another option start to take over the air packet capture to understand the issue.