Has anyone seen this particular error before with users attempting to authenticate to an AP that is using Meraki Cloud Authentication? Some of our BYOD clients fail to authenticate and the history of a particular client will show "Failed connection to SSID during authentication. Reason: reserved" I cannot find any info on this particular error or what it even is referring to.
We are running MR46 and MR46E. Just upgraded from MR 27.5.1 → MR 27.6 and the issues persist.
Are they Windows devices? If so, try updating the WiFi NIC driver. Often you have to download these from the manufacturers site to get the latest version rather than using the update tool that comes with the machine.
Thanks for the quick reply. Unfortunately these are mostly iPhone and Android devices as they are on a BYOD network using Meraki Cloud Auth. I just can't quite grasp what "Reason: Reserved" means. I have other networks using a traditional RADIUS auth. (Microsoft NPS) and PSK and don't see this error on those networks.
@SdotB This is a long shot but try disabling private MAC on an iOS device and see if that helps.
Not sure if Android have a similar virtual MAC setting.
Thanks. I'll give that a shot. Android does have a similar feature as well called "MAC randomization" that was introduced in Android 10.
@SdotB I would also open a support case, this tpye of error has been seen be a few other community memebrs over the last few weeks.
@SdotB While I may not be able to diagnose what is wrong, hopefully this could help you grasp the "Reason:Reserved"! 😉
Reason codes are based on IEEE 802.11-2012 standard and for the wireless LAN management frame parameters. So, when there is a deauth and that deauth meets specific IEEE specifications, that reason code will be reported. However, when that deauth doesn't match, nor meet any of the IEEE defined specifications, the reason will be: "Reserved". (Which admittedly can be a LOT of reasons!)
So, if you were to run a packet capture from the dashboard on the AP and dig into the frames, you'd be able to find the Deauthentication and management frames report that same reason.
My recommendation would be to run a monitor mode capture and then submit that to Meraki Support. A monitor mode capture will be able to hear all the things in the air and not be limited to just want the AP hears. This could help illustrate and/or isolate where to focus your attention.
Instructions for setting up a monitor mode packet capture can be found here: https://documentation.meraki.com/MR/Monitoring_and_Reporting/Capturing_Wireless_Traffic_from_a_Clien...
Hope that helps!
What wpa encryption mode is in use?
Have seen apple devices struggle when wpa1 and wpa2 is selected.
Packet captures should hopefully show some more details of why the client is failing.
I had a end user disable "private MAC" on his iPhone and his connectivity issues have subsided as the system doesn't see him as a new user every day. Still seeing the "reason reserved" in the logs however.