Chromebooks being kicked off network

  • 2
  • Question
  • Updated 2 years ago
  • (Edited)
Our schools have started their mandated online testing for the students this week and some of them have been reporting that some of their Chromebooks are getting kicked off the network.  For instance, one middle school reported that sixth grade was in the middle of testing and when the 7th graders started their testing, it appeared that the 6th grade Chromebooks got bumped off the Internet.  I have not been onsite yet to see this problem firsthand, and for the example that I just provided this was experienced yesterday (but just reported to us today) so they're going to see if the same thing happens again today.  We're on HiveManager Enterprise 6.5r1 (onsite VM in our technology office, which has a 1GB Internet connection), the access points are AP230 (OS 6.4r1e.2116) and the school has a 100mb Internet connection.  We use RADIUS authentication for our wireless network.  I'm curious if anyone else has had any issues with their Chromebooks getting bumped off when other Chromebooks get on the network.
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes

Posted 2 years ago

  • 2
Photo of Bill M

Bill M

  • 4 Posts
  • 1 Reply Like
I have experienced this needle in a haystack. Only 1 AP will be effected, and the rest of the school will maintain Internet. So I can't blame the WAN. I "get data" about the effected device, call into Areohive support, spend an hour sifting through things, only to come up empty. This can happen on MacBook Airs or on Chromebooks, and has happened repeatedly. All with the same scenario of everyone else in school unaffected, and 1 AP dropping connections, but the AP "get data" doesn't show the AP actually turning off or malfunctioning in anyway. 

So far as best as I can tell an ounce of prevention is worth a pound of cure. Unplug the AP from the switch to hard power reset it in classes youll know that will be testing. It never seems to happen on AP that have uptime less than 60 days.
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes
Thanks for the info.  I just looked at all of the APs for this one middle school (I'm currently onsite now as they had another issue this morning with Chromebooks), and all of the APs have been up for less than 30 days.  I can't even pinpoint it to one AP as I looked at two Chromebooks this morning that are about 4 classrooms apart so they would be connecting to different APs, and they just eventually started working again by themselves.  The principal did tell me that one class in the same area was using Windows laptops and they all worked fine, so the problem definitely seems to be limited to Chromebooks, although I've had another middle school where one classroom that has 3 iPad carts have issues with the iPads connecting, so I've had to restart the AP in that classroom this morning and yesterday to allow the iPads to connect successfully.
Photo of Gary Babin

Gary Babin

  • 21 Posts
  • 5 Reply Likes
We found that using "band steering" and reducing the power of the APs that are in close proximity helped with a very similar problem. The issue for Chromebooks seems to be a tendency to shift connections when they could see more than one AP. The other AP would then see it as a new connection that needed to authenticate. With those two adjustments our problem went away. 
Photo of Dan Ketchum

Dan Ketchum

  • 3 Posts
  • 3 Reply Likes
I went through this exact issue with Aerohive support a few days ago - what was the sweet spot for us was turning off every off every other 2.4 ghz radio, change the max power to 15dBm from 20 on both 2.4 & 5GHz, urge 5GHz, and change the channel width to 40 MHz from 80. YMMV based on AP proximity, density, and building type/construction. For us, the worst site was the 2 story building of newer construction. I would also suggest turning off the iPads not in use sitting in carts if they are not already. Our MDM checks in with ours on a regular schedule so they keep connected instead of going to sleep. Additionally, If those carts roll from room to room, they may want to stay connected to the last AP they associated with down the hall even if it is a weak signal.
Photo of Aaron Valente

Aaron Valente

  • 42 Posts
  • 3 Reply Likes
I agree with Dan and Gary.  I may be wrong but are you in a district which adopted the "1 AP per classroom" guidelines when developing your wireless infrastructure? Nick Lowe posted this on another discussion and it speaks volumes to the issue many schools have when it comes to dropped connections and confused devices http://www.wlanpros.com/wp-content/uploads/2014/04/Why-One-AP-Per-Classroom-Approach-is-Wrong-.v3.pd... 
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes
I appreciate all of the responses.  I've definitely learned a thing or two, and will continue to strive to learn and understand how all of this wireless stuff works between the APs, security/authentication, different wireless devices, wall types within our schools, dealing with coverage vs capacity, etc.  Maybe an AP in every classroom can be overkill, but it's a hand I've been dealt and I'm trying to make the situation better.  I've definitely had multiple situations where there have been multiple neighboring classrooms that were "sharing" an AP in the hallway and those classrooms had issues that ended up being resolved by putting a temporary AP in the classroom so that they can get through their online testing.  

I've checked our Aerohive configuration and band steering has always been enabled, so I didn't have to set that.  My Aerohive support engineer suggested upgrading the Hive OS on our AP230s from 6.5r1e to 6.5r1g, so that's on my short-term schedule.  I'm also going to adjust the power level on the APs since the majority of our classrooms have their own AP but there are still some in the hallways (those will be moved into classrooms without their own AP next school year).  I have not heard any issues with Windows laptops (Dell), so far it's just been one room at one school that has 3 iPad carts and a few schools with their Chromebooks.

Just curious, does anyone limit the number of APs that they have connected to one POE switch?  I'm just wondering if you have 20 APs connected to one POE switch, and each of those APs has (or can have) around 30 clients connected to it, so approx. 600 wireless clients, could that be considered too much going through one POE switch?  
Photo of Bill W.

Bill W.

  • 222 Posts
  • 35 Reply Likes
Limiting the number of APs per switch is going to be more of a decision based upon hardware limitation of the switch and your network design.  You need to look at the hardware specs of the switch and your APs (and any other PoE devices that will be connected to the switch) to determine the maximum number of PoE devices that it supports.  PoE switches have a power budget, so you cannot exceed that.
That being said, we have had no issues with 24 APs connected to a single switch. You have to remember that each AP is still only a 1 gigabit connection.  No matter how many wireless clients you have connected to an AP, they can't use more than the 1 gigabit connection the AP has to the switch.
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes
For those who have replied, are you using 802.1x authentication for your Chromebooks?  I've been researching what Google supports and they mention nothing about 802.1x and I found one article that says they recommend WPA2-PSK.  We're using 802.1x and we don't have any WPA2-PSK SSIDs, but I'm thinking of creating one just for our Chromebooks to see if this problem goes away.  I know it's possible to use 802.1x with the chromebooks, but if Google doesn't recommend it, then maybe that's the issue?
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes
We have only rolled out Chromebooks in a 1:1 fashion for 3rd grade, 6th grade and 9th grade this year.  Next year we add another grade and the year after everyone else (except for K-2) gets a Chromebook.  So right now for our elementary schools, it's just 3rd graders who have their own Chromebooks.  I have found out that one of our elementary schools (we actually have 3 elem. schools on Aerohive and 10 still on Meru) that has an Aerohive AP in every classroom, with channel and power still set to auto, has not been having any issues with their Chromebooks so far.  One of the Meru elem. schools that initially had a Chromebook connection issue did not have any APs in their 3rd grade classrooms (all of their APs were in the hallways), so when they reported connection issues in their 3rd grade classrooms, I put a Meru AP in each 3rd grade classroom and they worked fine for about a week and then reported the other day that their Chromebooks started having the connection issue again.

All of the Aerohive APs are still set to Auto for the channels on both 2.4Ghz and 5Ghz, but I've adjusted the power level settings in some of those schools mainly for the 6th grade classroom areas.  Today I'm going to disable the 2.4Ghz radio on every other AP in the 6th grade area in one of our middle schools to see if that helps with their situation, and tomorrow I'll be out there to run the Aerohive client monitor on the Chromebooks in one of their classes to see what Aerohive reports the client doing when it has a connection issue (hopefully the issue repeats itself tomorrow).  Meru works totally different in that all of the APs in the school can operate on the same channel because of their single channel architecture.  We've had Meru for 5 years and never started having any issues until we just started rolling out Chromebooks this year.
Photo of Arison Mercado

Arison Mercado

  • 113 Posts
  • 8 Reply Likes
Understood... well the Auto channel, and auto power is a huge red flag on why the problems are occurring and will only get a lot worse when your schools starts to rely on wireless 80% of the time. Also, I created a small example on how I configured the 2.4Ghz channels on a 1:1 deployment, and I would recommend to decreasing the dBm on the 2.4ghz as low as possible and raised the 5Ghz because you want clients to prefer the 5Ghz over 2.4 

Hopefully this helps..
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes
Thanks, I appreciate the info.  I've already lowered the 5Ghz level to 12 and the 2.4Ghz to 5 (my Aerohive support engineer said he would like there to be a difference of 7 between the two radios) for the APs that are in the classrooms for some of the schools that have been having issues, and the hallway APs I lowered to 10 and 3.  For this one school that I've been spending more time at, I disabled the 2.4Ghz on the hallway APs and every other classroom has an AP in it, but within 20 minutes after making that change and restarting those APs, one of the teachers emailed me to say that her class still has connection issues.  Channel is still set to Auto everywhere, so that may be one of my next steps.  I appreciate your assistance on this.
Photo of Arison Mercado

Arison Mercado

  • 113 Posts
  • 8 Reply Likes
Rob,

I also turned off the AP's in the hallway and teachers  immediately complained and in order to get it working without those turned on I had to start channeling the AP's within the classroom. My theory is that the reason we had WiFi issues after turning off the hallway AP's is because the clients saw it as a better connection to roam since the hallway AP's it bleeds into multiple classrooms. 
Photo of Dan Ketchum

Dan Ketchum

  • 3 Posts
  • 3 Reply Likes
It sounds like you are headed in the right direction.

Have you replicated the connectivity issues with a known good device? Our testing this time actually had multiple issues, wifi only being one of them. We also had some issues with SSL decrypt and our web filter (Lightspeed). I have also heard some chatter from other districts in our area having issues with AzMERIT testing and Chrome version 44 (48 is golden and 49 has worked for us). I also had a routing issue that was less efficient than it could have been, exasperating the wireless trouble.

"WiFi" has become the catch word to mean anything from an actual wifi problem to power outages to the device won't boot, so I've had to take a bigger view of things and work with the rest of our support staff to get me more useful information for troubleshooting.
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes
I just wanted to thank everyone who has commented on this topic.  We seem to have resolved this matter, between lowering the power levels on the 2.4Ghz and 5Ghz radios, disabling 2.4Ghz on some APs that are in close proximity to each other, as well as making some changes suggested by Aerohive, such as changing IP Multicast - Conversion to Unicast from disabled to always and lowering the channel width from 80Mhz to 20Mhz to allow for more 5Ghz channels to be utilized.  This has definitely been a learning experience and I've learned a lot from all of you.  I greatly appreciate everyone's support.
Photo of oc

oc

  • 8 Posts
  • 1 Reply Like
Did you get an explanation from Aerohive regarding the IP multicast conversion setting? I'm curious about what changing that setting to unicast actually does.
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes
No, tech support did not explain the purpose of that change.  I vaguely remember making a similar change on our old Meru access points (before we converted to Aerohive) because we had some AppleTV devices in our schools, but I don't quite understand what it does or what affect it has on the wireless network.
Photo of Bill W.

Bill W.

  • 222 Posts
  • 35 Reply Likes
Without going into a lot of detail, changing IP Multicast to Always helps to prevent the slow down of data transmissions because of a slow client and to free up airtime. This has to do with the nature of multicast. The Auto setting by default will only convert multicast to unicast if the channel utilization exceeds 60% or the membership count drops below 10. The Always setting is just that; the AP always converts multicast to unicast.
Photo of oc

oc

  • 8 Posts
  • 1 Reply Like
Okay, so here's what I found in Help:
IP Multicast: Video streaming typically makes use of multicasting as its transport. With multicasting, a data stream from a single source reaches multiple subscribers identified by their multicast group IP address. These subscribers notify their network routers and switches when they belong to a particular group and are interested in receiving data. When a router or switch receives such a notification, it then forwards any multicast stream for that group onto the network segment from which it received the notification. If there are no subscribers on a particular segment, the forwarding device stops transmitting the stream to conserve bandwidth.
On a wireless network, data transmitted by multiple stations on the same RF channel in an overlapping area must share the same physical transportation resource: the available airtime. When an access point transmits unicast traffic, it uses a rate-adaptation algorithm to determine the fastest data rate at which it can communicate with each station. When transmitting multicast traffic, the access point must choose the best data rate all the group members can support. If one group member has a slow connection, the access point must transmit at that speed to all group members. This not only slows down data transmissions to other members with stronger connections, it also uses up more airtime that otherwise would be available for use by other wireless stations in the area.
To reduce unnecessary airtime usage for multicast transmissions, an Aerohive device can convert multicast frames to unicast frames under certain conditions or at all times, and it can also drop multicast frames when there are no group members present to receive them. In addition to reducing airtime usage, another benefit of using unicast traffic is the increased reliability of video delivery. If a wireless client does not receive a unicast frame and does not reply with an ACK, the access point will retransmit it. However, multicast traffic does not support wireless frame delivery confirmation as unicast traffic does.
When an Aerohive device is enabled to convert multicast frames to unicast, it performs the conversion when the percent of channel usage exceeds a specified threshold or when the number of multicast group members drops below a specified threshold. By default, the channel utilization threshold is 60% and the membership count threshold is 10. You can change the channel utilization threshold from 1 to 100 % and the membership count threshold from 1 to 30 for the SSID.
If you want the Aerohive device to convert multicast frames to unicast when the channel utilization or membership count conditions are met, select Auto. For the device to make the conversion unconditionally, select Always. If you do not want it to use the multicast-to-unicast conversion feature but instead follow the standard 802.11 behavior for sending multicast frames, select Disable.
I'm wondering what the downsides are of choosing Auto or Always, besides not following the standard 802.11 behavior (is that a downside?).
(Edited)
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Hi,

The point of multicast/broadcast delivery in 802.11 is to allow a single transmission to be received and processed by multiple clients. The assumption was that this would always be more efficient than sending multiple copies of each packet individually to each client. This was certainly the case in the early days of 802.11, but is not quite so clear cut as transmission rates have increased with .11n and .11ac.

As multicast/broadcast traffic has to be received by all clients, it has to be transmitted at a low-enough data rate that all clients can successfully decode the frame. While the AP can be quite clever at selecting data rates, it still has to err on the side of caution, and the slowest client will always be the weak link.

For IP multicast, we have a bit more information to work on, as the AP can snoop IGMP packets and identify exactly which clients are interested in receiving a particular multicast stream.

Let's say you have a multicast video stream and only a small number of wireless clients connected to an AP that have joined that multicast group. In this case, it can use less airtime to send multiple copies of each multicast packet to each client using unicast transmission at the highest data rate each client supports than to send one multicast packet at a "safe" low data rate that all clients can receive.

Also, as unicast traffic is acknowledged by each receiver, while multicast traffic is not, you get more reliable delivery with conversion to unicast. This can be especially important if the multicast traffic consists of large UDP datagrams split across multiple fragments, as in this case a client missing a single IP fragment that is not retransmitted causes the whole UDP datagram to be lost.

For video, Aerohive's assertion that the inherent acknowledgement and retransmission mechanisms involved in unicast delivery is questionable - depending on the exact nature of the traffic loss that necessitates retransmission and the bufferring capabilities of the clients, you might get a worse overall experience due to the latency and jitter acknowledgement and retransmission causes. There's no hard and fast rule here - it depends on many factors.

Clearly, as the number of receivers increases, there comes a point where more airtime is used to send multiple copies of each packet via unicast compared with sending one copy via multicast at a lower rate. This is why the "Auto" configuration considers both channel utilisation and group membership count to try to identify when conversion might be beneficial, but in many cases, the AP cannot really determine the best course of action - hence it might be better in a particular network to always enable or always disable the function, depending on the exact nature of the traffic and other aspects of the configuration (power levels, data rates etc.) and the mix and location of clients.

Of course, multicast is not used just for video streaming. There are many applications that make use of IP multicast - conversion to unicast may be more or less useful, depending on the exact nature of the multicast traffic.

In some instances, something as apparently innocuous as Bonjour or SSDP/UPnP can result in quite a lot of multicast traffic on a network.

Remember also that for proper operation, you need to have IGMP (or a full multicast routing protocol such as PIM-SM) properly implemented on the network, so that the AP can make use of IGMP snooping.

Hope this helps.

Roberto