Anyone out there noticed any issues with HP G4 Chromebooks and MR46 APs?
We have newer Lenovos and New HP Chromebooks that do not exhibit constant connection drops.
Chromebook disconnects and reconnects to same AP every few seconds.
Sometimes connects to adjacent AP with half the SNR.
Info about devices:
Chromebook G4 running CRos 85. Same issue observed with CRos 84.
Wifi adapter is 7260AC
1 AP per classroom.
each AP set to auto channel and power.
Power setting 2-6
5GHz only SSID
Firmware 27.4 and 27.5
Will downgrade entire network tonight to 26.8.1 to see if that makes a difference.
Hi @Skinner I have seen Chromebook deployments, for example in many K12 environments, and on rare occasions I have seen some oddities with connection drops like this. Please do open a case with Meraki Support for investigation. Your plan to try dropping back to GA firmware 26.8.1 is fine if you want to do that first, that will be a good data point if the issue persists across both MR26/27.
In some cases, I've had deployments that had all other devices working perfectly (windows laptops and iPads for example) but ended up with specific model Chromebooks and/or with lower-end wifi adapters that exhibited such issues which somehow went away with the next CRos update. Sounds like you've been through one OS update already. And I'm not pointing fingers at CRos, just stating what I've seen on a few occasions. Do you have any other makes/models of Chromebooks, even a personal one, you can take on site and try to reproduce with that one also?
The best next step (perhaps after firmware) would be to get that case open, and capture this issue while it's actively happening, while collecting a monitor-mode packet capture. Do you have a Macbook? If so it'll be a simpler process. You won't be able to just run Wireshark on the wireless interface of a laptop for example, you'll need to run a "monitor mode" pcap and get that to Support so the Eng team can decode the exact sequence of events/frames leading up to the drop. If it's a random thing, and can be tough to reproduce, you can also set up a "rolling" packet capture, and perhaps give yourself a 5 to 10-minute window to go stop the capture when the issue occurs. Support can assist with the setup.
I started a case on this issue last Friday.
Due to COVID it is not as easy collecting the data on site. I would have to setup a remote capture using wlanpi and then collect the data remotely.
Besides HP G4, I received a report of an old Acer Chromebook exhibiting the same issue. Wireless adapter is 802.11ng based.
Got it, understood it's extra difficult to catch this in action, on site at the moment. Not sure if Support started down that path, but I can see monitor-mode pcaps being really helpful to dig into what's going on. Good luck and keep us posted on the case and outcome.
Yes! I have been seeing this issue as well. I have MR32s in classrooms with a mix of makes and models of chromebooks throughout our district. I never see the issue on our Dell chromebooks or windows laptops...only on the new Lenovo 100e's that we just put out. When you look at the AP in dashboard and its failed connections you see a lot of "bad password" connection fails. This can't be correct either because it's the same pw for all chrome devices coming from the Google Admin Console. Also, it's the same password for the windows devices. I did downgrade to 26.8.1 and the next day I still saw the issue.
Yes, I have been in front of these devices and watched the wifi connect/disconnect repeatedly about every 20-30 seconds. I have some of both of the gen1 and gen2 100e's.
@BrothersTM Gen1 and Gen2 have different adapters and that makes it even more interesting.
How dense is your deployment?
How many APs on management VLAN?
How many Chromebooks at affected location?
Is this problem evident at more than one location?
Next time it happens, could you inspect log files under chrome://device-logs. I am wondering if the authentication error appears there as well. I plan to see if the issue continues with 26.8.1. If that is the case I may have to push out an open SSID.
A slight update, I disabled band steering and this seems to have alleviated the repeated association/disassociations for the Lenovo 100e and 300e models. Not sure it is a fix, but at least they are connected steadily.
So far this is what I have observed
The issue persists across 26.8.1 and 27.x
It is 802.11ac related because
1. Affected devices work fine with 2.4GHz only SSID, and that is a workaround until there is a better solution in place.
2. 5GHz 802.11n works as well, although not possible to configure on a Chromebook.
3. Setting MIMO SMPD to no SMPD corrects the problem on a Windows device. In this case it was a Dell 5470 with an Intel 8260 card.
Was this ever resolved? We have the exact same issue with HP Chromebook G4s. 100s of them.
Our G3s, G5s, and G8s do not have this issue on the same network. We have resorted to a 2.4Ghz only SSID for now.
That is what we resorted to, but it wasn't pretty.
Do you have an open case with Meraki regarding this? Is it a known issue at least?
Thanks for responding.
@Chris22 It is far from pretty but it works until there is a better remedy in place. Distribution of Chromebooks allowed me to connect affected devices to 2.4GHz while other devices connect to 5GHz only SSID. Metrics look good and there are 0 complaints since I made that change several weeks ago.
I do have a case open and it should be a known issue as support referenced several devices with Intel adapters.
Several months later, anything from Meraki yet?
I have done some testing on weekends and can't replicate the issue with low network activity. Basically, I can only reproduce this problem in a dense device environment. With classrooms full, these Chromebooks are basically unusable on 5Ghz AC. 2.4 GHz is still our solution for now, but I feel the Chromebooks will be EOL before this bug is figured out.
Check the log for 27.6 and see if it makes a difference in your environment. It did not work for mine.
Although the problem seems to be more prevalent in dense and busy deployments, I did experience it in buildings with less than 10 Access Points.
Chromebooks are in high demand right now. Phasing out these affected models will be difficult for at least another school year.
We are currently having major issues with this right now. Both gen 1 and 2. Kid's coming in left and right and we have all 46's in classrooms.
I know of two options.
Move the affected Chromebooks to 2.4GHz SSID. First try to lower the power level for 2.4GHz to a minimum. If that does not work, disable 2.4GHz for some APs. You'd have to do some surveying to figure out which ones to disable.
Also, open a support ticket and ask for a temporary workaround to disable MU-MIMO.
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!
Just wanted to chip in to say I'm in an Education envrionment as well running traditional Cisco Aironet APs (AC Wave 2). We have at least 1 site that has been having the same type of Chromebook drop off issues for months now, it seems to have kicked off since the start of 2021
Rebooting the APs also resolves it for a short-period here as well but other devices (e.g. Windows laptops, Apple iPads) are working fine on the same APs. We do have band-steering on one SSID but we have a 5 GHz only SSID and the same issue occurs on this as well, load balancing is not enabled on either SSID.
Have OS bugs/driver versions, etc.. at the device level been exhausted?
@zgrounds Initiate a support request with Meraki and have them disable MU-MIMO, is another option. Do so for one part of a building or a single site. It is always possible that problems may be unrelated. Fortunately we were able to replace HP G4s with new models and have not had this issue repeat.
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.
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.