Client drops - Tuning EAP timers?

[emily00001]

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:

https://supportforums.cisco.com/document/46101/eap-timers-wireless-lan-controllers

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 7.6.130.0.

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"

Local Auth Active Timeout1 (in secs)
Identity Request Timeout (in secs)
Identity request Max Retries
Dynamic WEP Key Index
Request Timeout (in secs)
Request Max Retries
Max-Login Ignore Identity Response	disable             enable
EAPOL-Key Timeout (in milliSeconds)
EAPOL-Key Max Retries
EAP-Broadcast Key Interval(in secs)

[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

http://www.cisco.com/c/en/us/td/docs/wireless/technology/wlc/82463-wlc-config-best-practice.html#pgfId-379881

[emily00001]

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.

[Scott Fella]

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. 

-Scott

[George Stefanick]

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

[emily00001]

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

[George Stefanick]

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. 

[emily00001]

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.

[Scott Fella]

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.

-Scott

[sin]

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.

[emily00001]

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.

[emily00001]

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?

[Scott Fella]

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.

-Scott

[emily00001]

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?