Chromebook connectivity issues

I came across a recent issue related to Chromebooks. A particular site with about 200 plus Windows, Apple, Android devices working perfectly fine with no issues. They also had 30 Chromebooks, which constantly had connectivity issues no matter where they were in the building. Looking through the configurations of the Wi-Fi, I noticed nothing that may have been causing an issue. 200+ of other devices were working perfectly fine. Looking at the ChromeOS they were using M74. I started looking at the connectivity and compared different clients connected to the access points. I noticed that while all the other clients were showing up connected at the lowest mandatory basic rate of 12 Mbps, these Chromebooks were shown up at 6 Mbps (while idle).

This behavior did not seem right, so I did some testing with the Chromebooks.

Probe Request from Chromebook – So this looks normal Chromebook is sending a normal Probe Request with the lowest data rate that the PHY allows it. No issues here.
Probe Response from the AP – This looks normal as well showing the lowest mandatory data rate and all the supported data rates as well as rest the capability parameters
Association Request from Chromebook – From previous blog entry on 802.11 association we know that this frame is when the client syncs its WLAN NIC with the parameters sent by the access point. However, in this case it seems client is trying to associate at 6 Mbps when it should have been at 12 Mbps, it does show 12 Mbps as part of the supported rates but comparing this frame with working devices 12 and 24 Mbps rates are in ( ) but they are not in this Association Request frame sent out by the Chromebook.
Association Response – Before the conclusion let’s take a look at the Association Response frame. This frame clearly shows that the Association response is successful and client has also received an Association ID (AID) as well. Looking at the data rate again it is clear that the rate here is 12 Mbps vs 6 Mbps, which was used by the Chromebook in Association Request.

Looking through all these frames, testing and finding out the same behavior even in 2.4 GHz band here were some of my thoughts:

  • During the Association Request phase when the WLAN NIC should be syncing with the parameters sent by the access point, data rate is not syncing. Client device is using the lowest rate allowed by the PHY instead of syncing that with the 12 Mbps required by the access point.
  • 802.11-2016 standards document 10.7 discusses Multirate support. Specifically 10.7.1 states, IEEE 802.11(TM) Wireless – Only the data transfer rates of the mandatory rate set of the attached PHY are guaranteed to be supported when a STA for which dot11OCBActivated is true transmits a Management or Data frame. A higher layer protocol entity within a STA in which dot11OCBActivated is true might negotiate a rate outside the mandatory rate set.”
  • Next 802.11-2016 standards document clause mentions, IEEE 802.11(TM) Wireless – A STA shall not transmit a frame using a rate or MCS that is not supported by the receiver STA or STAs, as reported in any Supported Rates and BSS Membership Selectors element, Extended Supported Rates and BSS Membership Selectors element, or Supported MCS Set field in Management frames transmitted by the receiver STA.”
  • Based on these findings although most of the parameters are matching in the Association Request frame however clients were clearly violating the above mentioned clauses from the 802.11-2016 standard. Which leads me to believe was part of their connectivity issue.
  • I still do not completely understand however why the Association Response was successful, technically it should not have been successful based on the standard, if anyone has any further thoughts and explanation on that I would love to discuss/hear it.

Doing some research online I did find some enterprise cases filed with specifically 953702. It seems like they did fix the issue with the client using the lowest rate supported by the PHY in M77. I tested couple of Chromebooks to M77 and M78 rested the scenario and this time I was not seeing the same issue. Association Request data rate was matching the data rate specified in the Probe Response as shown

This is an Association Request frame from Chromebook on M78. As compared to M74 it is clear that this is syncing the data rate of 12 Mbps with the parameters send by the AP in Probe Response. This also stabilized the client connectivity after updating all 30 Chromebooks to M77 or higher code.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 thought on “Chromebook connectivity issues”

WordPress SEO