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.