I have come across a recent issue related to Chromebooks. At a particular site with about 200 plus Windows, Apple, Android devices working perfectly fine with no issues. They also had 30 Chromebooks which were constantly having connectivity issues no matter where they were in the building. Looking through the configurations of the Wi-Fi I did not notice anything that may have been causing an issue. Moreover, 200+ other devices were working perfectly fine. Looking a the ChromeOS they were using M74. I started looking at the connectivity and started to compare different clients connected to the access points and noticed that while all the other clients were showing up connected at the lowest mandatory basic rate of 12 Mbps these Chromebooks were showing up at 6 Mbps (while idle).
This behavior did not seem right so I decided to do some testing with the Chromebooks.
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 10.7.5.7 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 Chromium.org 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