topic Well, we had some success in Wireless

Client drops - Tuning EAP timers?

emily00001 — Mon, 05 Jul 2021 09:42:13 GMT

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 Timeout¹ (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
EAPOL-Key Timeout (in milliSeconds)
EAPOL-Key Max Retries
EAP-Broadcast Key Interval(in secs)

Cisco best practise is a

Sebastian Helmer — Sat, 14 Mar 2015 07:28:17 GMT

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

Identity Request Timeout of

emily00001 — Sat, 14 Mar 2015 11:35:14 GMT

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

Scott Fella — Sat, 14 Mar 2015 17:13:31 GMT

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

I agree with Scoot. I would

George Stefanick — Sat, 14 Mar 2015 17:13:32 GMT

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

I should have mentioned that

emily00001 — Mon, 16 Mar 2015 16:12:42 GMT

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

You mention neighbours

sin — Mon, 16 Mar 2015 22:11:21 GMT

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.

If you can directly

George Stefanick — Mon, 16 Mar 2015 23:34:29 GMT

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.

I'm positive that some of the

emily00001 — Tue, 17 Mar 2015 15:10:00 GMT

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.

I don't think I have the

emily00001 — Tue, 17 Mar 2015 15:17:42 GMT

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.

Can you show us the wlan

Thomas McClintic — Sat, 21 Mar 2015 15:54:13 GMT

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.

Thomas is right... you need

Scott Fella — Sat, 21 Mar 2015 16:02:06 GMT

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

Hi, sorry about this terribly

emily00001 — Fri, 27 Mar 2015 13:00:51 GMT

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

Scott Fella — Sat, 28 Mar 2015 13:17:24 GMT

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

Some are Apple users with MBP

emily00001 — Sat, 28 Mar 2015 23:06:56 GMT

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?

There are know issues with

Scott Fella — Sat, 28 Mar 2015 23:26:50 GMT

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.

-Scott

That's good to know. I have

emily00001 — Sun, 29 Mar 2015 18:38:51 GMT

That's good to know. I have controller code 7.6.130.0 running but maybe upgrading that could be a good idea even if this isn't a known problem with this version.

Also I've heard of the OSX issues but since users don't report them after office hours when the network and neighbours networks have lighter load (we still have a considerable number of users working late), I'm not sure if that matches with the OSX issue? Maybe that's an omission on part of those reports that they are more frequent in noisy environments.

I wouldn't upgrade to v8.0.x,

Scott Fella — Sun, 29 Mar 2015 18:48:46 GMT

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.

-Scott

Well, we had some success

emily00001 — Sun, 29 Mar 2015 19:55:30 GMT

Well, we had some success with adjusting AP positions and then changing Identity Request Timeout (30 to 5) and Identity request Max Retries (2 to 12). The majority of users in polls have described themselves as very satisfied both before and after these changes with both changes resulting in in notable improvements for some of the users that weren't as satisfied.

From the users having issues I can normally write off some client devices by identifying problems with them but I still have around 10-20 % of client devices that I can't explain why they are having issues, their owners are also likely to insist on this not occurring elsewhere. Maybe that's false information...

I'm marking your answers as correct as they probably represent the most reasonable course of action but additional feedback and suggestions are always welcome.

I have had good luck with

Scott Fella — Sun, 29 Mar 2015 21:13:21 GMT

I have had good luck with timers being set at what you have and lower at 3 and 10. AP placement and defining the data rates and max/min data rates will also help with distribution of clients.

-Scott