The Beta 28.3 and 28.4 firmware has fully solved this issue for us. Chromebooks no longer hop between access points. The deauth packets were captured coming from the access points, so it is certainly a firmware bug or an overly aggressive tune for client roaming. Additionally our older Windows machines that would be deauthed and reconnect to the same access point over and over do not experience this issue any longer. At this time I can say the beta 28.4 firmware is rock solid in our environment with no issues for the last month.  ... View more

We were suggested by Meraki support to try beta firmware 28.3. So far we have pushed it to 20 ap's on campus and it appears to have fixed the issue. The G4 Chromebooks stick to their classroom AP consistently now. We would prefer to not be running beta firmware in the production environment but it seems to be working fine so far. I was able to capture the deauth packets and they were initiated by the AP, suggesting that the clients are not choosing to hop AP's on their own.  ... View more

My organization is seeing the same issue in August 2021. Currently running the exact same models of devices on the Meraki template classroom profile. Fairly dense environment, but the issue occurs even if I'm sitting with the device in an empty classroom. Rebooting the AP's appears to fix it for a several days then it begins again. Some classrooms encourage the devices to hop AP's more aggressively than others, some don't seem affected at all. I'm seeing HP Chromebook 11 g4's disassociate and associate with AP's within range regardless of if its SNR is 20-30 db worse. The AP's are in the exact same locations as the previous Cisco system which did not exhibit this behavior.   If there's any solutions beyond switching Chromebooks to 2.4ghz I would love to hear it. Thank you! ... View more