Authentication Issue (EAPol Timeout) on WPA 2 PSK SSID

[Dhanushkah]

We are not use Authentication servers to authenticate wireless users.

Just use only WPA 2 encryption mode for authenticate wireless users.

But we identified there are lot of EAPol timeouts happened during the client authentication

What would be the issue for this EAPol timeouts 

Is this issue occurring from end user device or Access Point side ?

How Can we minimize this eapol timeout issue?

Guys Help me to rectify this issue

AI-generated summary

From your community moderators: We're experimenting with using AI to summarize some of our longer threads. The summary has been reviewed by humans for accuracy.

Problem

The original poster reported experiencing numerous EAPol timeout issues during client authentication on their WPA 2 PSK SSID network that doesn't use authentication servers, asking whether the issue originates from end-user devices or access points and how to minimize these timeouts.

Summary

Community discussions reveal several solutions, with enabling fast roaming 802.11r being the primary solution that successfully resolved the EAPol timeout issue for at least one user. Other users experiencing the same issue expressed initial skepticism about how 802.11r could solve PSK-related issues but were willing to try the solution. Additional suggested troubleshooting approaches included: checking for RF interference, verifying client device compatibility, examining network congestion, reviewing power settings on client devices, and ensuring proper SSID configuration. The problem appears to be related to the wireless authentication handshake process timing out during the four-way handshake between clients and access points, and while there was no explicit confirmation from the original poster about which solution worked, the 802.11r fast roaming feature was highlighted as the most effective fix for addressing these authentication timeouts.

[ww]

Would first verify if your clients running latest  wifi drivers

[Dhanushkah]

Thank you ww for your reply....!

• This issue affects not only a few specific users.
• This issue randomly affects every user on each day and there are also devices with 802.11ax supported wireless adapters.
• If this can be avoided by updating the drivers, do we have to update the drivers of all the wireless devices?

If there is any specific configuration to rectify this issue from meraki dashboard end?

[WB]

If it's only affecting the same users each day I would be advising them to download the latest drivers from their Wi-Fi NIC manufacturers website e.g. Intel's website NOT updating via Windows update

[DarrenOC]

Hi @Dhanushkah , what version of MR firmware are your APs on?

You mention that this is happening across all users/devices albeit sporadically throughout the day? Are all devices the same model and build?

Yes you should look to upgrade drivers across the board.

[Dhanushkah]

• MR 36 - Current version: MR 28.6.1
• MR 52 - Current version: MR 28.6.1

This is an environment where legacy devices and latest devices are common.

Most of the laptops are HP and there are few other products.

External wireless adapters are also used for desktop PCs and connected to the wireless network.

However, this EAPoL timeout will affect every device.

[DimuthuS]

Enable 802.11r. It will fix the issue

[Dhanushkah]

Thanks @DimuthuS 

We already enable 802.11r for fast roaming. But it has not worked. Even though 802.11r is enabled for SSID, this eapol timeout continues.

[DimuthuS]

802.11r enabled with WPA1 and WPA2 ? or WPA2 only ?

What you see from the AP logs for the same time "Unknown Error" ?

[Dhanushkah]

Thanks @DimuthuS 

• 802.11r enabled with WAP2 only 

This is the two types of AP logs we identified  when users experience disconnection in the meraki dashboard

• auth_mode='wpa2-psk' vlan_id='16' reason='eapol_timeout' radio='1' vap='3' channel='56' rssi='20'
• auth_mode='wpa2-psk' vlan_id='13' reason='eapol_timeout' roam_ap='E4:55:A8:09:DD:36' radio='0' vap='0' channel='1' rssi='7'

[PhilipDAth]

My guess - it's probably as simple as they aren't very close to the WiFi network.  Perhaps they are walking out of the office, into the office, etc.

Perhaps they drive to the office and park outside.  Their devices can just barely see the WiFi, and get constant timeouts till they walk inside.

[Dhanushkah]

Thanks @PhilipDAth 

In  your case, timeout is a very normal thing,

• but the problem here is that the wireless connection of users who are in the same place without moving also timeout.

• To explain it in another way, in this environment, a user roams from one AP to another AP even when the user is in the same place without physically moving.

• After analyzing the user's timeline, we could see that even when the user is in the same place, he connects to several nearby APs within a few seconds, and this eapol timeout occurs when the user continuously jumping nearby APs

[BigForrest]

Hi,

I have a same problem with @Dhanushkah that random users on random days, our users can't connect WiFi even the AP is next to week they still can't connect. When I check the logs, it show error "reason='eapol_timeout", and user can't connect again. The workaround is we have to forget the network then re-authenticate again then it works but that happens only for few days then it happens again. Our NPS does show the user is authenticate and reply back. Any ideas? 

[AlexanderN]

Hi @Dhanushkah have you tried reviewing our new Wireless overview page (Wireless > Monitor > Overview) to drill down on specific problematic clients and find the root cause?

[AlexanderN]

Also, I just wanted to confirm if you are using just WPA2-PSK auth or something else like iPSK w/o RADIUS?

[SilviaS]

Hello. I do have the same issue. Did you find any solution to this?

[Henrik_]

Could the issues in this thread be related to Re: Radius Authentication Issues - The Meraki Community

[SilviaS]

We did disable 802.11w a few days ago but the errors still there.

I also tried disable band steering yesterday and will troubleshoot again next week.

Thanks for the reply.

[TBHPTL]

• Flush and forget any stored  profiles entries.  THESE ARE EASILY CORRUPTED
• Update your client wireless drivers

As a SIMPLE test you can change your PSK make sure that it is at least 8 characters in length and test... 

For the record just because a client doesn't move, that doesn't mean they will not roam. Clients, and clients alone, decide to which wireless AP they will connect.

[UFOUNDLX]

Similar issue here: 

EAPoL timeout issues to Radius Server. sometimes just a really long "Time to Connect" 

affects users/computers randomly,

issue happening at multiple sites

both sites: are using MR52 APs

both sites are using Firmware MR 29.5.1

[SilviaS]

Hello.

We disabled client balancing in the radio configuration and users are no more complaining after that. Maybe this also helps for you?

BR

[amabt]

was this ever solved?

[SilviaS]

We solved the problems by disabling client balancing. Please try that.

[UFOUNDLX]

unfortunately, Management doesn't want us to disable that feature. looking at Radius Servers, we found 1 server that was not showing any connection attempts in logs, and removed that from the list of Radius Servers in Meraki.  we are waiting on further confirmation from staff, hoping that was the problem.

[Kiwi_James]

I would STRONGLY recommend that you update your client drivers, as well as update Windows to latest build level as there are fixes for these timeouts. ANY wireless issue should trigger you to check that the latest drivers are installed!!!

In addition, there are also issue with latest Windows builds and 11r. If you see an "invalid MIC" issue then disable 11r for that SSID. My understanding (I may be wrong) is Microsoft are working on a fix but it'll be a while.

[LabyAK]

Thanks you all for the comments/responses as I too have similar issue with eapol_timeout/invalid MIC.

I too had tried enabling 802.11r ,but didn't fixed. 

Thanks anyway and keep rocking and rolling. This forums help to learn/resolve issues as Meraki TAC is mostly late for actions. 

[iterssroom]

Ok got it. Thank for your help.

redactle

[KevinWaller]

I was able to resolve this on my network by enabling fast roaming 802.11r

[DavidValverde]

I selected adaptive mode in 802.11r and I didn't get any more similar logs.