wifi client 802.1x Radius EAP unespected disconnection

[Ste]

Dear Community,

we've been experiencing issue recently with our WiFi network. We've noticed some unexpected disconnections affecting our clients, and despite checking the channel utilization and radio profile, everything appears to be in order.

Each time a client disconnects, we observe specific error messages related to their connection. The SSID in question uses WPA2 Enterprise authentication with a Microsoft NPS Radius server. Interestingly, at the same time that these disconnection events occur, the Radius logs show granted access.

The aps are CW9172I MR 31.1.8

Given these details, I would appreciate your insights into what might be causing these sudden client drop-offs.

Connection start time Client device Access point SSID Failure stage Failure reason

Tue Mar 24, 2026, 09:43:47	xxxx	xxxx	xxxx	Association	auth_mode='wpa2-802.1x' 11k='1' 11v='1' reassoc='1' error_code='30' radio='1' vap='0' channel='116' rssi='17'
Tue Mar 24, 2026, 09:43:46	xxxx	xxxx	xxxx	Association	auth_mode='wpa2-802.1x' 11k='1' 11v='1' ft='1' reason='invalid_pmkid' radio='1' vap='0' channel='100' rssi='50'
Tue Mar 24, 2026, 09:43:46	xxxx	xxxx	xxxx	Association	auth_mode='wpa2-802.1x' 11k='1' 11v='1' ft='1' reassoc='1' reason='invalid_mdie' radio='1' vap='0' channel='116' rssi='17'

[alemabrahao]

If you have 802.11r enabled in the SSID, some devices don't support this feature and may exhibit the behavior you're describing.

So try disabling 802.11r from the SSID.

[Ste]

the specific client support 802.11r. do you suggest to disable it global anyway?

thank you

[alemabrahao]

Yes I do.

[PhilipDAth]

Check out this guide on disconnection codes.

https://documentation.meraki.com/Wireless/Troubleshooting_and_Support/Troubleshooting/Common_Wireles...

[Ste]

Is there any way for us to determine whether 802.11r is functioning correctly on the AP side, or if the problem might actually be occurring on the client side?

[rhbirkelund]

Usually this is a client side issue. Invalid MDIE, happens when a client claims to support Fast Transition, but sends a wrong MDIE. The PMKID is generated as part of the Authentication process, based on the exchange between the AP and the Client. If a client is connected to the wireless network and onboarded, a PMKID is already generated, and is also used during roaming. If Invalid PMKID happens, it either means that the client is sending a wrong PMKID, or it is unknown to the AP. 

In any case, Fast Transition might've gone wrong, and usually this is a client issue. 

I'd look into if there's a software upgrade available for the client.

Historically, wireless clients have been having lots of issues with Fast Transition, but I'd argue that was a thing in the past. Modern wireless clients have much better support for standards-based roaming. 

That being said, avoid setting Fast Transition to Supported/Optional/Adaptive. Either enable it fully or disable it. I've seen more issues when FT is set to Adaptive, rather than it being Enabled or Disabled.

[Ste]

Thank you so much for providing such detailed information, your post was helpful and clarified many points for me. I just have one final question: what should we keep in mind before disabling 802.11r globally on the access points, rather than managing it on the client side?

Understanding any potential impacts or considerations in advance would be greatly appreciated.

Thank you

[GIdenJoe]

If you disable FT 802.11r on the SSID then every roam will be a full radius session meaning your clients will take longer to roam between AP's and the load on your NPS server could increase much if you have a high client count.

If that does not sound appealing to you, then perhaps first try to fully troubleshoot the clients if possible.

That means, check if the issue happens on specific clients (NIC model and driver version) or in case of IoT devices, the device as compared to other devices.

I would personally not like to have to disable FT just for a handful of clients.

[alemabrahao]

A roam does not necessarily trigger a full RADIUS (802.1X/EAP) authentication just because 802.11r is disabled.

If 802.11r is disabled and clients do not support OKC/PMKID, then roams may require full 802.1X/EAP reauthentication. But in most enterprise WLANs, roaming still uses cached keys, so disabling FT does not automatically cause full RADIUS load or slow roaming.

[rhbirkelund]

Did the client roam to an AP in the same mobility domain? That is, did it roam to an AP assigned to the same network?

[Ste]

Yes the APs are in the same network, same organization same mobility domain