Showing results for 
Search instead for 
Did you mean: 

Client drops - Tuning EAP timers?


I have had some clients complaining (laptop users) about being dropped from the WiFi and this appears to correlate with the events in the WLC log for DOT1X-4-MAX_EAPOL_KEY_RETRANS for those clients.

Drops are more frequent when the network and neighbours networks are under load during the day.

What would your advice be on tuning this? I based my settings off a guide found here:

The way I interpret this is that the settings present a bit of a tradeoff between the risk of being dropped and the time it takes to get back in if you are dropped.

We have a WLC 2500 with 2700 APs running

Below are the current settings that we have set:


Edit: Table did not paste correctly

Local Auth Active Timeout1 (in secs) "300"

Identity Request Timeout (in secs) "5"

Identity request Max Retries "12"

Dynamic WEP Key Index "0"

Request Timeout (in secs) "30"

Request Max Retries "2"

Max-Login Ignore Identity Response "enable"

APOL-Key Timeout (in milliSeconds) "1000"

EAPOL-Key Max Retries "2"

EAP-Broadcast Key Interval(in secs) "3600"


2 Accepted Solutions

Accepted Solutions

There are know issues with Apple on controller code v7.6.100.0-v7.6.120.0.  There are current stability issue with Yosemite and iOS code.  You can find more info on Apple forms regarding that. 


*** Please rate helpful posts ***

View solution in original post

I wouldn't upgrade to v8.0.x, but that's me. Look at optimizing your wireless to be honest and know of what client devices have issues, because there is only so much you can do to help with stability. The fix would be by the manufacture of the NIC drivers. 


*** Please rate helpful posts ***

View solution in original post

19 Replies 19

Sebastian Helmer

Cisco best practise is a Identity Request Timeout of 30 sec

I would try that first..I also configure a retry of 5 than 2..try it step by step

Identity Request Timeout of 30 seconds is default and we also experienced the drop problem when running that. We also had retry of 2 the default then.

Since laptops are what I'm getting most reports of dropping I would assume that the drop is not due to slow response and that timeout shouldn't be a factor in such a situation and I would assume that it happens as a consequence of interference? We're in a pretty crowded and central spot.

I don't think it's your timers. You can look at the stats on the WLC for the radius and if you see low milliseconds and not a lot of retries, then it's not that. Understanding what is really happening is the key. Going to the area where the complaints are and seeing it for yourself eliminates users providing you with bad info. Can it be interference from other wireless, sure it can, but you need to make sure that's the issue and not your WLAN configuration. 


*** Please rate helpful posts ***

I agree with Scoot. I would also try and reproduce the problem and capture the client debug at the same time. 

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin

I should have mentioned that this is on WPA2 also.

What I'm told is that the drops may occur 2-3 times per day by some users. Other's don't have this issue or aren't bothered enough by it to notice. There is no definite correlation between equipment or area although proximity to APs does influence this (drops are more likely with increased distance) but we still have users without such drops at the same location as users experiencing them. Drops only seem to occur during busy office hours and not outside of them despite this being a 24/7 access office with a considerable amount of people staying late.

I could probably attempt a cli client debug capture and see if something else shows up although the problem is not very frequent so it will be a long day.

Another question would be what is withing the tolerances of how WiFi should perform in this situation. Is it reasonable for this to happen in a WiFi congested spot.

Entries for an affected client in wlc-syslog set to debug (not the cli debug tool) may look like this during a day for the mac aa:bb:cc:aa:bb:cc:


Cisco_ac: 3c:44: *dot1xMsgTask: Mar 13 11:57:34.645: #DOT1X-4-MAX_EAPOL_KEY_RETRANS: 1x_ptsm.c:508 Max EAPOL-key M1 retransmissions exceeded for client aa:bb:cc:aa:bb:cc
Cisco_ac: 3c:44: *dot1xMsgTask: Mar 13 11:57:41.045: #DOT1X-4-MAX_EAPOL_KEY_RETRANS: 1x_ptsm.c:508 Max EAPOL-key M1 retransmissions exceeded for client aa:bb:cc:aa:bb:cc
Cisco_ac: 3c:44: *dot1xMsgTask: Mar 13 11:57:47.045: #DOT1X-4-MAX_EAPOL_KEY_RETRANS: 1x_ptsm.c:508 Max EAPOL-key M1 retransmissions exceeded for client aa:bb:cc:aa:bb:cc
Cisco_ac: 3c:44: *dot1xMsgTask: Mar 13 11:58:25.265: #DOT1X-4-MAX_EAPOL_KEY_RETRANS: 1x_ptsm.c:508 Max EAPOL-key M1 retransmissions exceeded for client aa:bb:cc:aa:bb:cc
Cisco_ac: 3c:44: *dot1xMsgTask: Mar 13 11:58:32.065: #DOT1X-4-MAX_EAPOL_KEY_RETRANS: 1x_ptsm.c:508 Max EAPOL-key M1 retransmissions exceeded for client aa:bb:cc:aa:bb:cc
Cisco_ac: 3c:44: *dot1xMsgTask: Mar 13 11:58:38.065: #DOT1X-4-MAX_EAPOL_KEY_RETRANS: 1x_ptsm.c:508 Max EAPOL-key M1 retransmissions exceeded for client aa:bb:cc:aa:bb:cc


If you can directly correspond this event with a drop then maybe you are looking at the right thing. But I would be very careful just pulling things from the log that may look like a problem and isn't. At this point what we know is there are drops. Thats it .. What is causing the drop could be anything. Driver is most likely the issue is other users aren't reporting problems. 



"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin

I'm positive that some of the drops match with the log entry as I have asked users about the time of the drop. Can't know if this is accounts for all drops but it seems to be a part of them at least. I'll try to nudge the values a bit and see where it lands I guess.

Thomas is right... you need to post your wlan config at least to help us verify is your settings are correct.  Looking at the logs you posted, make sure your wlan isn't setup with both wpa and wpa2.  You should only use either wpa/tkip or wpa2/aes and not both or a mix of both.  You should also look at your client drivers and try to delete the wireless profile and create it again to see if that helps.

This is just a start.


*** Please rate helpful posts ***


You mention neighbours networks. It could very well be a 2.4GHz congestion issue.

If you laptop and your network coverage supports 5GHz connection I would recommend to do at test where you disable 2.4GHz on the SSID. 

I have done this succesfull on many similar cases. Disabling 2.4GHz on the client site can prove very difficult do manage. But it would also help.



I don't think I have the luxury of disabling 2.4 GHz as we still have to maintain legacy support. Devices like the iPhone 4S is lacking 5 GHz support.

But I should try investigating if this has to do with users ending up on 2.4 GHz. This might happen with automatic channel changes for instance.

Thomas McClintic

Can you show us the wlan configuration? Mostly looking at the client band select and load balancing. Also, what are your rrm dca timers set to?

They key here will be to try and capture frames of a client during an event, that will provide much needed information to troubleshooting.

Hi, sorry about this terribly late reply. There is currently no load balancing and the DCA timer is set to 600 seconds. I'm attaching a text document with the wlan config.

DCA is set to automatic and to Avoid Foreign AP interference, Avoid non-802.11a noise, Avoid Persistent Non-WiFi Interference.
DCA Channel Sensitivity: Medium
EDDCA is also enabled at medium setting.
Further I should mention that I now know that not all client drops correlate with log entries for DOT1X-4-MAX_EAPOL_KEY_RETRANS. Some do, the ones that don't have no entries associated with the event as far as I can tell in neither asa-log nor wlc log (both on debug setting).
I'm not sure if I can realistically capture frames on a client for this. Would it be a Wireshark type capture? From what I know some of the frames relating to the WiFi communication are kept in the hardware and can't be passed on to the OS unless specialised equipment is used?

What clients specifically are complaining.... if you have any Intel 62xx or Intel AC 72xx, be aware that there are know issues.  The Intel 62xx require v15 firmware and the AC 72xx has still know issues in which Intel states to use the latest firmware v17.  That doesn't seem to fix issues with client dropping and disabling WMM, seems to be a good workaround to keep them stable.


*** Please rate helpful posts ***

Some are Apple users with MBP Retina or MBA going back 1 to 3 revisions of those models. So Broacom adapters I guess belong to those affected. Not sure if any Intel ones but I would have to look into that more. Would there be any point in disabling WMM still?

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