cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1254
Views
0
Helpful
9
Replies

Client unexpectedly stoped to join AP

slyfox
Beginner
Beginner

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

 

9 Replies 9

slyfox
Beginner
Beginner

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
VIP Community Legend VIP Community Legend
VIP Community Legend

Is the controller running on 8.10.X.X?

Hello @Leo Laohoo  software version 8.10.130.0

WLC 3504

affected AP AIR-CAP3702I-E-K9

Leo Laohoo
VIP Community Legend VIP Community Legend
VIP Community Legend

@slyfox wrote:

Hello @Leo Laohoo  software version 8.10.130.0


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

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

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? 

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.

-Scott
*** Please rate helpful posts ***

marce1000
VIP Mentor VIP Mentor
VIP Mentor

 

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

                   Using your debug file gives :

 

Select a client MAC Address and connection to see logs.
Connection 1 of 2
  •  
  •  
  • 1
  • 2
  •  
  •  


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


-- ' A nun once asked a penguin ' do you think the earth is flat ? ; the penguin replied :
Madam, it all depends , in Riemann geometries the earth can be perfectly flat! The nun thanked him , he tripped and fell forward : the poor animal had forgotten that he might be living in a Riemann geometry too!

saravlak
Beginner
Beginner

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers