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.
Filtering Scan Results in WiFi Explorer April 8, 2018
One of the things I didn't spend too much time with at the beginning of the development of WiFi Explorer was filtering. As the tool matured, it was more than evident that some filtering capabilities were needed. Nevertheless, I didn't want to make anything overly complex. Filtering had to be quick and easy to use, and more importantly, the syntax used to create filters needed to be "natural." With these goals in mind, I've been working over the years on different ways to filter scan results in WiFi Explorer and WiFi Explorer Pro.
In WiFi Explorer, filters let you focus on a specific set of results to facilitate monitoring, troubleshooting or analysis. You can quickly filter scan results by network name (SSID), BSSID, channel, signal strength (RSSI), annotations, mode, vendor, device name, band, country code, security or encryption type.
Below you can find a cheat sheet with the most common display filters:
To filter scan results by:
Network name (SSID), annotations, vendor or device name: type the text in the Filter field. If you need to filter using an exact match, use quotation marks for the keywords, e.g. "ABC School".
BSSID: type either :XX or XX: where XX is an octect of the BSSID you are searching for. You can also extend the text with more octets (e.g. XX:XX, XX:XX:XX) to search for more specific BSSIDs.
Signal strength (RSSI): type a comparison operator (<, >, <= or >=) and the signal strength level in the Filter field. For example, to display only the networks that have a signal strength greater or equal than -65 dBm, type >=-65. If you want to use percentage as units when filtering, type >=50%.
Channel number: type the channel number in the Filter field.
Band: type the band (e.g. 2.4 GHz, 2.4ghz, 24ghz, 5GHz) in the Filter field.
Mode: type the letter or letters that identify the mode: a, b, g, n, or ac. You can also prefix the letter(s) with 802.11, 80211 or just 11. For example, type 11g to display only networks that support 802.11b, or ac to display only networks that support 802.11ac.
Security or encryption type: enter the acronym for the security or encryption type in the Filter field. For example, type WPA2 to display only networks that are configured with WPA2.
Filtering using multiple fields
You can filter on multiple fields by separating the keywords using "," (OR) or "&" (AND). For example, if you want to filter networks so that only 2.4 GHz networks with a name (SSID) starting with School are shown, simply enter 24ghz & School in the Filter field. If you want to display only networks on channels 1, 6, or 11, type 1, 6, 11 in the Filter field.
Negating a filter
You can negate a filter by simply prefixing it with "!". For example, to list all networks that do not have the word School in their names, simply enter !School.
You can use pre-defined filter controls to quickly display 2.4 or 5 GHz networks, as well as secure or open networks only.
In WiFi Explorer Pro, you can also create custom filters by clicking the '+' button in the Quick Filter bar or by going to WiFi Explorer Pro > Preferences > Filters. Custom filters are automatically added to the Quick Filter bar and can be selected the same way you select pre-defined filters.
Automatic filter controls
Additional filters are automatically generated based on the scan results. These filters can be chosen from the left side panel by selecting one of the items under each of the following categories: Network Name, Mode, Channel Width, Security, Access Point and Vendor. You can show or hide the side panel by clicking the left icon in the Show/Hide option of the WiFi Explorer Pro toolbar.
Filtering by signal strength using keyboard shortcuts
Another way to filter scan results is by using keyboard shortcuts to filter networks by signal strength. By using a combination of the Option key and one of the keys representing the numbers from 0 to 9, or the keys below (Q, W, E, ..., I, O, P), you can set a desired signal strength threshold in 5 dB increments. If you set a filter using one of these shortcuts, you can clear it by pressing the Escape key.
For example, to display only the networks with signal strength equal or greater than -70 dBm, press Option-7. Similarly, to display only the networks with signal strength equal or greater than -75 dBm, press Option-U (the letter U is located below and between 7 and 8 in the keyboard, therefore it gives you the mid value between -70 and -80 dBm). The same applies if using percentage (%) as units for signal strength: 1 for 10%, Q for 15%, 2 for 20%, etc.
When you filter by signal strength using these keyboard shortcuts, a legend appears at the bottom of the window indicating the signal strength level being used to filter the scan results.
Keeping a simple, "natural" syntax is great for quick and easy filtering, however, it has some drawbacks. For example, not every piece of information can be used for filtering. Also, there are cases where filters will not give you the expected results, not because the implementation is wrong, but because a simpler filter might not be as effective as one that is more elaborated (for example, filtering using the letter 'a' will give you all 802.11a networks, but not the networks containing an 'a' in their name). Nevertheless, I believe the filtering capabilities in WiFi Explorer offer great flexibility and are good enough for your every day use. There is of course room for improvement, and better filters will be added as the need arise.