Today we are seeing multiple sites being affected with Deauthentication events. Here is an example:
I have opened up a case with Meraki support but figured I would ask here if anyone had any ideas. These are MR34 running firmware MR 25.13, the devices are 6th gen iPads running iOS 12 (usually 12.1.4 or 12.2). We have seen these events at multiple different schools today and are at a loss for the root cause.
If you have "Block clients from connecting ro rouge SSIDs by default" (under Wireless/Airmarshall) enabled, try turning it off and see if it makes any difference.
Does Air Marshall show anything else unusual like lots of "Spoofs"?
It sounds to me like you are being attacked. Alas there is not much you can do about it of you are.
You could try rebooting your APs as well in desperation.
You could also consider enabling protected management frame. If your devices support this then it will reduce the issue a lot.
@PhilipDAth No spoofs or Rogue SSIDs. Do see single and multiple packet floods occurring.
It's just strange because we are seeing this at least 4 different schools. The protected management frames information is interesting. We'll have to take a look at the Allow clients to connect setting in Air Marshall, as I know we have it set to blocked.
Rebooting does seem to "fix" the issue but I'd much rather determine why it's happening and truly fix the issue.
Do you only have Meraki AP's, or do you also have some other vendor APs in the environment advertising the same SSID(s)?
@PhilipDAth We are only using MR34s, we are testing the 26.2 release in one of our schools and the results after a day are quite promising. There was no screaming about the WiFi not working and in fact most of the people I have spoken with have noticed improved performance.
I recall reading something like this and it was due to the lease being set to 1 hr and the devices not having it renewed. They changed it to 24 hours and I believe they said that corrected the issue. I'm not fully confident on my memory of the issue, but it's something that can be checked quickly on your side.
@MMoss I believe I saw that thread as well and that was due to splash activation which we do not use.
Hearing from Meraki support they advised if it happens again to contact them via phone and do not reboot the AP so they can check real time logging.
Makes sense, hopefully they will be able to find the problem fairly quick