One of the many reasons I enjoy developing for Mac is that during all these years, I've encountered very few bugs in macOS. In other words, from a system and development perspective, things just worked. For many years, macOS was amazingly stable and if something didn't work, it was most likely a bug in the code, not the system's fault.
However, in the past couple of months, the number of oddities affecting the Wi-Fi information provided by macOS and the CoreWLAN framework, especially in the latest MacBook Pro (MBP) 2018 is concerning, to say the least. We have read many stories about how Apple's hardware and software quality is declining. Whether that's true or not goes beyond the scope of this blog, nevertheless, the question remains: What's going on, Apple?
In this blog post I'd like to share what I know about these oddities, but before I go into detail, let me clarify a few things. First, all of these issues were encountered in macOS High Sierra 10.13, and some of them appear to be a problem only in the MBP 2018. I'm not disclosing any issues found only in macOS Mojave 10.14 because it's still in beta (and of course Apple's NDA). Also, reports come from different users and therefore different Macs. Second, I'd normally file a bug report with Apple, but since I don't own a MacBook Pro 2018, it's difficult for me to gather all the required information, respond to Apple's engineers' questions and follow-up with the reports in general. Once I figure out a way to get my hands on a MBP 2018, I'll file the bug reports. In the meantime, I think it's important to document these findings and inform others so that they don't get caught by surprise when they encounter these issues in the wild.
Airport CLI shows incorrect MCS index
The MCS (Modulation and Coding Scheme) index plays a crucial role in assessing the health of modern Wi-Fi network connections, as it correlates with the link quality. Higher MCS indexes correspond to higher data rates. In 802.11n networks, the MCS index goes from 0 to 31, while in 802.11ac networks, the MCS index goes from 0 to 9 for each number of spatial streams. See mcsindex.com for a complete list.
In macOS, there are two ways to determine the current MCS index of the Wi-Fi connection: you can Option + click Apple's Wi-Fi menu extra icon and find the MCS index displayed as part of the Wi-Fi connection details, or you can use the airport command-line utility. Using the airport command-line utility works great for apps or scripts that need a programmatic way to retrieve this value, which is exactly how WiFi Signal monitors the MCS index.
Unfortunately, in the MBP 2018, the airport command is reporting 0 for the MCS index of some network connections, not in alignment with the reported transmit rate. In the example below, if we take a look at the current transmit rate and PHY mode, the MCS index should definitively be a value other than 0. In fact, Apple's Wi-Fi menu extra shows the correct MCS index, which confirms that something's wrong with the airport command.
As a result, WiFi Signal also shows 0 for the MCS index since it relies on the information provided by the airport command-line utility.
Incorrect beacon interval in CoreWLAN's Wi-Fi scan results
In macOS, the CoreWLAN framework offers developers an API to perform active Wi-Fi scanning (for more information about Wi-Fi scan modes, see Understanding the Scan Modes in WiFi Explorer Pro). The network's beacon interval --the time interval between beacon frame transmissions-- is included in the scan results from CoreWLAN. By default, the beacon interval is set to 100 time units (TUs). A time unit is equal to 1024 microseconds, therefore 100 TUs = 102,400 µs = 102.4 ms.
For some reason, however, CoreWLAN in the MBP 2018 is returning an incorrect beacon interval. For networks configured with the default beacon interval, the value returned by CoreWLAN is 20 TUs or 20.5 ms.
Comparing scan results from WiFi Explorer Pro running on both the MBP 2015 and the MBP 2018, we can see that, for the same networks, different beacon intervals are being reported. When using passive mode, which doesn't make use of the CoreWLAN framework, the beacon interval is always 102.4 ms in both systems, as expected.
It is unknown what value is returned when scanning on the MBP 2018 if the networks are configured with a different beacon interval as this scenario has not been tested (who'd change the beacon interval anyway?).
Missing information elements in CoreWLAN's Wi-Fi scan results
Similarly to the issue I just described, CoreWLAN in the MBP 2018 is returning fewer information elements for certain networks. The same comparison test (MBP 2015 vs. MBP 2018) shows that for the same network, the scan results in the MacBook Pro 2018 are missing a number of information elements. And again, using passive mode in WiFi Explorer Pro shows no difference between the MBP 2015 and the MBP 2018.
This problem is particularly strange in the sense that CoreWLAN simply gives developers a reference to the beacon frame payload, which is essentially a byte array that represents the collection of information elements, so I don't understand why some information elements would be present and others would not. Perhaps this one is in fact a problem in WiFi Explorer, but giving that the macOS and app versions are the same (only the hardware changes), I'm not sure.
Incorrect noise values for the current connection
This issue was not reported on the MBP 2018, but it's as odd as the other ones. The noise value reported for the current connection in Apple's Wi-Fi menu extra is, for lack of a better word, incorrect. Under normal circumstances, the noise value is usually below -90 dBm, however, in this example, Apple's Wi-Fi menu extra shows 24 dBm, same as WiFi Signal, which uses the CoreWLAN framework to retrieve the noise measurement.
This noise value was so crazy that it made the user reporting the issue believe WiFi Signal was inverting the values for noise and SNR.
If you have experienced any of these problems or find a different one please let me know. I'll be updating these blog if new issues are found or existing ones get fixed.