Badger-Fi

Tag: Chromebook

  • Distant Beacons – Part 3 – Calming the Seas

    Note – Lighthouse image was used with permission from Ranveig Marie Photography.  Check out her stuff here:  Instagram, Facebook, and Flickr.

    This is part three of a multi-part post describing the tuning of Single Channel Architecture/Virtual Cell and taming ChromeOS roaming behaviors.  Part one can be found here.  Part two can be found here.

    We are very densely populated with access points to accommodate at least 50-60 devices per classroom at any given time.  Because of this AP density it is necessary to make adjustments to the network on occasion.

    As indicated in part two, pcaps determined that we were decoding beacon frames with valid FCS into the high -80s dBm, all with the same BSSID (Virtual Cell).  Even though there were several different devices consuming wifi in the area, Chromebooks were hyper sensitive to the fluctuating SNR and were the only device type continuously performing four way handshakes due to a triggered roam (SNR <=18).

    Since we are so densely populated with access points (to meet requirements), the only way to tune away the issue was to increase the minimum base transmit rate even further (from 24 Mbps).

    24 Mbps Base Transmit Rate – 5 GHz Radio

    TX power is already reduced to a level that provides proper overlap between classrooms to satisfy requirements.  Increasing the minimum base transmit rate to 36 Mbps was done first but did not yield the results that I wanted to see.  I then increased the minimum base transmit rate to 48 Mbps (also leaving the supported rates of 24 and 36 Mbps) and ran another pcap.

    48 Mbps Base Transmit Rate – 5 GHz Radio

    This time I was receiving most beacons with valid FCS in the mid -70s dBm.  Further testing with the Chromebooks showed the results I wanted to see.

    Unnecessary (triggered) roams were dramatically reduced and performance was much better.  Beacon overhead was decreased by 50% which is indicative of moving from 24 to 48 Mbps minimum base rate.

     

     

     

     

     

    We ended up testing this configuration change at a couple of our high schools of similar layout, design, and requirements with very good results.

  • Distant Beacons – Part 2 – A Single Port in the Storm

    Note – Lighthouse image was used with permission from Ranveig Marie Photography.  Check out her stuff here:  Instagram, Facebook, and Flickr.

    This is part two of a multi-part post describing the tuning of Single Channel Architecture/Virtual Cell and taming ChromeOS roaming behaviors.  Part one can be found here.

    It is no secret at this point that I maintain a very large Single Channel Architecture/Virtual Cell wireless network.  From time to time there are certain nuances that force our hand into making adjustments to the wireless network, which  really is no different than any other network, SCA or MCA.  Since we do primarily use a single channel throughout our instructional spaces, a single, identical, BSSID is seen by all clients within a Virtual Cell.  Recently I was troubleshooting network performance issues on Chromebooks and found that they were constantly performing four way handshakes, several times per minute.  Other devices in the area, including my Mac, did not experience the same problem.  I decided to pull some pcaps to see what I could find.  I ran Wireshark for a period of time then filtered out beacons (wlan.fc.type_subtype == 0x0008) and sorted them by lowest to highest RSSI.  What I found next started to pull things together from several other recent troubleshooting sessions.  I found that my beacons, all from the same BSSID, had valid  FCS and were being received with RSSI into the high -80s (dBm).  This only left room for an SNR in the single digits.

    Because the SNR was so low on these distant beacons, unnecessary roams were being triggered on the Chromebooks even though there was ample signal available from much closer access points.  From one second to another, a device could hear several beacons with the same BSSID, some with very poor SNR and others with very favorable SNR.  For the last couple of years we have found a sweet spot with TX power and minimum supported rates which has worked nicely with the vast majority of the 80,000 devices we see at peak on a daily basis.  Until the recent influx of Chromebooks (tens of thousands) in the past school year there has been no reason to make any adjustments.

    RX-SOP?

    Stay tuned for an upcoming post on changes that were made to the infrastructure to make these sensitive devices behave better.

  • Distant Beacons – Part 1 – One Size Sail For Every Ship?

    Note – Lighthouse image was used with permission from Ranveig Marie Photography.  Check out her stuff here:  Instagram, Facebook, and Flickr.

    This post will serve as part one of a multipart post concerning recent happenings involving client settings, client behavior, what was done to tune a network, and the results thereafter.

    Chromebooks have been around for several years now and love them or hate them, they are here to stay.  Chromebooks began as a low cost consumer device but have since crept their way into the enterprise, as well as established a strong foothold in the K12 vertical.  What originally seemed like a cheap compute option, is now available in many different hardware options, many times offering “better than decent” performance for an affordable price.  Don’t be fooled though, there are plenty of Chromebook devices out there that sport less than desirable performance but rep a very attractive price tag.  This initial post explains my desire to get a better understanding of Chromebooks and their behavior on my beloved wireless network.

    We currently have tens of thousands of Chromebooks in our Google Domain that are owned and managed by our school district.  We recently reached over 80,000 concurrent wireless devices on our network and ChromeOS serves as a sizable percent of that number,  steadily creeping towards surpassing iOS.  Most of the time everything works great but when there are issues reported, you can bet there is a very good chance the device in question is a Chromebook.  Known issues in the past have been cleared up by Google in relatively short order.  Other times, issues linger on and off, coming and going like the ebb and flow of an ocean tide.  In the recent past our district standardized on a specific manufacturer and model of Chromebook that would be purchased and supported by our department staff.  Many people were brought together to make sure the device met and exceeded our expectation for an exceptional user experience.  Keep in mind there are several thousand other Chromebook devices still on our network which are either legacy holdover or BYOD devices.  Ironically, despite the vast differences, many of the Chromebooks exhibit similar behaviors.  This post will go on to explain my thoughts as to why this may be.

    To get a better understanding of Chromebook behavior on wireless networks, I decided to collect data on my own.  This was done to see if I could correlate behaviors with known issues.  I decided to create a simple form on my blog that asked for a few pieces of information easily obtained from a Chromebook with a few commands.  The following information is what I was interested in:

    • Chromebook Full Model Name
    • ChromeOS Version
    • WLAN Adapter Model
    • Roam Threshold
    • Country

    Overall, I was fairly underwhelmed with the response but I did get a handful of responses (thanks to those who contributed).  Out of the responses I did receive there was one very interesting thing that stood out.  The roaming threshold was EXACTLY the same no matter the manufacturer, ChromeOS version (recent or several years old), or WLAN hardware!

    Why would 18 (roaming threshold (SNR)) be the threshold that was selected for ALL variations of Chromebooks?  What this means is that if the Chromebook’s Signal to Noise Ratio (the difference between RSSI and noise floor) drops below 18, a roam event could occur because the device deems the signal to be less than optimal.  Those of us who have been in the game for awhile know that the inconsistencies in end-point wireless hardware is the consistency.  Wireless network hardware is not calibrated by the manufacturer.  Wireless network hardware behavior will vary depending on manufacturer, device capabilities, DRIVER VERSION, etc.  In fact, two wireless network adapters made by the same manufacturer using the exact same driver, placed in the exact same model device, will behave differently!  Why would the very intelligent people at Google think that the same, non-adjustable, roaming threshold was best with so many different variables in play?  There may be a good explanation, but so far I have been unable to find it.  Other types of devices (ie. Windows) offer the ability to tune roaming behaviors within advanced driver settings.  To date, ChromeOS does not allow adjustment to these types of settings.

    As mentioned earlier, Chromebooks aren’t going anywhere.  They are good devices and fit the K12 environment well due to many factors.  As Chromebooks push further out of the consumer realm and into being an enterprise player, Google may need to adjust their one size fits all wireless settings model.  The massive difference between home use and enterprise use should drive this change unless there is a good reason not to (I’d love to know, Google!).

    Future posts will explain more discoveries and how I was able to tame these K12 beasts, with the understanding that bending a network for a single device type is often dangerous.  I like to live dangerously…