Strange network issue?

[jasoncrcsd]

I'm looking for an outside perspective on an issue we've been having and wondering if there is something I'm missing in troubleshooting this. We have a student whose over the past year reported their chromebook disconnecting from the wifi almost always around noon. We've had techs be onsite in class and cannot observe the student doing anything to cause this. They have tried having the user use a different device and it still seems to happen. They don't seem to have any extensions or apps loaded that the others don't have. Their device has been powerwashed etc. We cannot figure out ehat is causing this. others in the same room experience no issues.

[ddelboccio]

The wi-fi disconnect issue follows the user from device to device?

When the disconnect issue happens, can the student re-join the wi-fi right there on the spot?

Do you "push out" your wi-fi credentials to Chromebook via the admin control panel?

[jasoncrcsd]

Yes I'm told its happened for this user on more then 1 device. They say usually a reboot will get it to reconnect. Yes we push out the same Wifi Policy to all devices vie the Network section of the admin console.

[ddelboccio]

Can you (have you) tried pulling up the student in the Google admin console, clicking on the security tab, scrolling down to sign-in cookies and clicking reset?

It might be a long shot, but this has worked for a few strange issues......

[jasoncrcsd]

I haven't, didn't think that would be related but worth a shot

[kaned]

If I were in this situation, I would be running a packet capture or using my network/Wifi system to see the reason for the client disconnect.  Albeit, My background is a networking...  This could be a roaming/load balancing issue that failed to connect to the new AP.  The disconnect reason may help you in your troubleshooting.  The odds of if being the same kid are low, but if he's in the corner of a class, etc, etc.  

Was the replacement the same model device, same wifi card model?  Try another model (temporarily), maybe this is a bug within chrome, you could always roll back to another version.

Unless you are doing 802.1x authentication or other RADIUS, I have yet to see a Google profile cause problems from a networking perspective (not saying it can't or won't happen though).

You may want to consider running some of the network diagnostics on the Chromebook or using some Chromebook tools like:  chrome://net-export/

[panderson]

As mentioned, packet capture may help, but if somehow the student (or app) is turning or disabling the wifi, it will most likely just show that it disconnected or lost connection to the device.

How often does this happen?  Every day, or sporadically?  Is the user doing the same thing (same webpage/app)?  Is the user always in the same room, area, or different areas?  One thing that might be interesting to try is to log the student into two Chromebooks, one that they use, and just let the other one sit idle (or play video or looping slideshow) and see if it only happens on the device that the student is actively using.

[MattDPenn]

So I've gotten similar reports on my campuses and never have really been able to nail them down. Though usually its not specific times of day. Did have an issue where a couple specific students were having blank pages specifically on student curriculum websites that allegedly cropped up more in certain classrooms than others that "mysteriously" fixed itself. Suspect the students realized they were getting more scrutiny over time or the last powerwash finally nailed a corrupt file.

Anyway something that I have (I think) noticed that I'm not sure is specific to our Ruckus wifi is if a chromebook loses connection to wifi to many times it'll ask for the password again. Could be going to sleep from idle, students sleeping their chromebooks instead of shut down, the actual random disconnects mid-use. It could be tangentially be related to if a chromebook is on for to long without a proper shutdown and over time it could be doing something to the wifi. That was my train of thought for the aforementioned "white page" error but didn't really get the chance to ensure the students in question were properly rebooting in a given time frame before the issue finally "fixed itself".

Another thought I have is I feel like I've gotten less reports of actual "random disconnects" after we turned off 2.4ghz for our Student and Staff wifi. It could be a matter of the chromebook tries to switch to/from 2.4 or 5 and just doesn't complete. I couldn't ever find evidence of a failed transition but I also don't have a lot of networking experience nor equipment/software to do a deep dive.

[kaned]

We have 100% seen issues with both Client load balancing and band steering  (Band load balancing) algorithms in the past.

What I have found is that when a AP is overwhelmed, the AP encourages devices to switch by increasing latency to specific devices.  One the other end, if an AP has identified itself to have too many clients, it may intentionally not respond to new connections in an attempt to encourage the device to look elsewhere.

In either situation,  this promotes a environment that pushes clients to roam to other accesspoints that may not accept the roam request.  Which could cause a problem.

If the area is congested and AP's are shedding clients, this could very well be the situation.  But without knowing why the client attempted to roam, and if the request to join the new ap was successful, it's all a shot in the dark. 

It could entirely be a chromebook firmware issue.  It could entirely be a Wireless network design issue.  Could also be a student induced problem (though not sure how).  More investigation is really needed.

The fact that the device requires a reboot to reconnect makes me concerned this is more of a device issue.

Even if it is a device issue, the packet capture and/or log of the AP's would help in identifying and reporting the issue to Google.

[MattDPenn]

Could it be a matter of a reboot is needed because the wifi service gets locked up by the unsuccessful attempt to roam? aka garbage data effectively clogging the chute? Least that's the way I would imagine it with my current knowledge but that also assumes that it isn't attempting a "new" connection when it loses connection for whatever reason and "only" uses what it had previously.

[kaned]

Absolutely...  but that would be a Google Chromebook bug for not properly handling that situation.

Until the CB bug is reported and fixed, the only alternative would be to address this from a network perspective.  

Again, this assumes that this is even the problem.  It could be something entirely different.  Without looking into network logs and chromebook logs, its just grasping straws.

[Bill_Gibson]

Could this be DFS channels dropping out related to some aircraft related schedule?
https://documentation.meraki.com/MR/Radio_Settings/Dynamic_Frequency_Selection_(DFS)

[kaned]

If you were using DFS channels, you would see on the meraki dashboard that the channel for that AP was changed and the reason as to why (DFS, channel congestion, etc).

In this situation I would expect to see more people complaining, but I've also been surprised that 1/30 actually is complaining...

We avoid DFS whenever possible, but in some situations it's hard to do so.

[panderson]

Has anyone else reported the same thing? Does the ability to connect to WiFi actually disappear?  If it only happens with that one user, maybe try creating a new account and have them test that (you can always move the data to the new account and delete the old one). My guess would be that if it only happens for one user on multiple devices and those devices work fine for other users, it is something that the user is doing, either intentionally or unintentionally, or there is something going on with the user's account. 

[BarbSeib]

Could the user profile become corrupt? Could some content on their drive cause things to become corrupt?  (We have a similar situation). 

[kaned]

Totally possible.  You could provide the kids with a whole new username and see if the problem persists.