In August 2018, we wrote a blog describing several issues we found in Apple’s CoreWLAN framework and the airport command-line utility affecting Wi-Fi scanning and monitoring in the 2018 MacBook Pro and other similar models. We also submitted the corresponding bug reports to Apple and waited for a resolution. With the release of macOS Catalina in October 2019, Apple fixed two of these issues: incorrect beacon interval and missing information elements in CoreWLAN’s Wi-Fi scan results.
Three years later, we give you Part 2, describing two different issues now affecting packet capturing in the new M1 Macs.
Capturing Wi-Fi traffic is an essential task of protocol analysis. Wi-Fi professionals use packet captures to validate and troubleshoot wireless networks, including connectivity, device compatibility, roaming, configuration problems, and more. And for years, doing Wi-Fi packet captures in the Mac has always worked reliably out of the box, and it is one of the main reasons many Wi-Fi professionals love their Macs to do their jobs.
Unfortunately, packet capturing is now broken in the new M1 Mac. Same as with older Intel Macs, the new M1 Mac comes with a Broadcom Wi-Fi chipset, but it’s the first Mac compatible with 802.11ax. We don’t know if it is because of the new chipset, the new ARM architecture, or macOS Big Sur, but something is wrong and breaks packet capturing in the M1 Mac.
We have already reported these issues to Apple, but we’d also like to share some details to help you understand how these issues affect WiFi Explorer Pro and Airtool.
1. Packet captures don’t use the correct channel
Update (11/08/2021): The latest version of macOS Big Sur appears to have fixed this issue. However, capturing on multiple channels by doing channel hopping remains broken on the M1 MacBook Pro (2020) as macOS doesn’t switch channels across bands correctly. The 14″ and 16″ M1 MacBook Pro (2021) do not appear to be affected.
To do a packet capture in Airtool, for example, Airtool first disconnects from the wireless network and then sets the channel we want to capture on. Airtool disconnects the interface and sets the channel using Apple’s CoreWLAN framework. However, selecting the channel doesn’t work reliably in the new M1 Mac, especially when choosing a channel from a different band. In many cases, the channel remains unchanged. For example, if the interface is previously set to a channel in the 2.4 GHz band, selecting a channel in the 5 GHz band will likely fail. The opposite is also true.
In Airtool, the capture will work, and Airtool will show that it’s capturing on the selected channel, but the packet capture will be done using a different channel. The same is true for Apple’s Wireless Diagnostics. When you do a Wi-Fi packet capture using Apple’s Sniffer utility, selecting a channel and starting the capture will work, but the packet capture will be done using the incorrect channel.
On the other hand, passive scanning in WiFi Explorer Pro doesn’t work as expected. WiFi Explorer Pro iterates over the list of 2.4 and 5 GHz channels to listen for beacons from nearby access points, but because it cannot correctly switch channels between bands, it will only show networks found in either the 2.4 GHz or 5 GHz band, but not both. Also, it some cases while iterating within the same band, setting the next channel will fail, and WiFi Explorer Pro will show less results than expected.
Passive scan only shows a few networks in the 5 GHz band.
2. Packet captures include many corrupt or garbage frames
Update (11/08/2021): The latest version of macOS Big Monterey appears to have fixed this issue.
When you do a packet capture, it is expected to find a fraction of malformed frames because of how Wi-Fi works. However, packet captures in the new M1 Mac show a large percentage of corrupt or garbage frames. For example, under high traffic conditions (such as a speed test), packet captures show many control and management frames with an incorrect size or data rate. Also, many of these frames are not even expected to be found in the capture, such as Association Request frames.
Packet capture made in the M1 shows corrupt and garbage frames.
Beacon frames appear to be correct, and therefore, passive scanning in WiFi Explorer Pro seems to show the right information; however, as it is, we can’t trust packet captures made on the M1.
Airtool uses the libpcap library shipped with macOS for capturing packets, but the problem occurs regardless of the application used for packet capturing. For example, Wi-Fi traffic captures made with the Sniffer utility from Apple’s Wireless Diagnostics also show many corrupt and garbage frames.
Conclusion
In this Part 2 of the “What’s going on, Apple?” series, we share details of new issues affecting Wi-Fi packet capturing in the new M1 Mac and how they affect apps such as WiFi Explorer Pro 3 and Airtool 2. We’ve also reported the issues to Apple and hope they will resolve them soon. In the meantime, if you find a new problem, please let us know.
Hi Adrian,
As for the corrupt frames, I see from the screenshot that the FCS seems correct according to Wireshark (the C in the flags row). Is that the case for all the frames you’re talking about?
What I’ve noticed is that when Apple did a refresh of the MacBook Pros around 2017/2018, something changed and the new hardware stopped reporting any frames with bad FCS (which is something that in rare cases can be useful). Hardware prior to that would report both, and then of course you’d see a lot with bad FCS if only the preamble was observed and perhaps some more data.
Did you fiddle with the “Validate FCS cehecksum if possible” in Wireshark settings for IEEE802.11? Cause if seems strange if FCS is good, but the frame is corrupt, so the quesiton is if Wireshark just goes with what the NIC driver says the FCS status is, or if it’s actually reading the FCS reported and validating it.
Hi Jonas, thank you for your comment. What I meant to explain in the blog was that captures made in the M1 Mac have a considerable percentage of bad frames. For example, in the capture I used for the blog, 40% of the frames were bad. The capture, as shown in the screenshot, lists the frames with an “unverified” checksum. Changing the preferences in Wireshark to validate the FCS shows a bad checksum for all of these bad frames, as expected. Wireshark still tries to decode them, and it is just a coincidence that many of these frames are Association Requests. Again, the main issue here is that almost half the capture is garbage. A simultaneous capture made on a different system looks normal.
My first guess for #2 would be that deaggregation was broken in the monitor, but what do I know?
Hi Adrian,
It doesn’t look like #1 is limited to the M1 Macs. I have an Intel MacBook Pro (13-inch, 2020), which is also capturing on the wrong channel. The symptoms are exactly as you describe in #1. I am running MacOS 11.2.3. Is it possible that this is actually an issue with a MacOS update?
I’m not aware of the issue affecting other Mac models, but it could be. However, the issue was fixed in the latest version of macOS Big Sur, so you may want to update your Mac and see if the issue’s resolved.
I installed updated, and it resolved the issue like you said it would. Thanks for the great tools!
My MacBook Pro M1 is running the latest Big Sur 11.5.2 and just starting showing the incorrect channel problem again. It was associated on 2.4 GHz channel 1, then I asked Airtool2 to capture on 5 GHz channel 149. I was so happy to finally catch a pesky issue during the capture, then later realized that the whole capture was of channel 1… Did Apple actually fix the problem in Big Sur?
I’ll have to check that again. As far as I know, Apple resolved the issue in one of the Big Sur updates.
I’m running Big Sur (11.6) on an M1 MacBook Pro. Today I ran into a data rate issue I hadn’t seen before. A native capture showed beacon frames at 6.5 Mbps, when the lowest basic rate on the AP was 12 Mbps. A capture at the same time on a MacBook Air (non-M1, also Big Sur 11.6) showed the same beacons correctly at 12 Mbps.
I still have the unexpected channel issue from time to time too.
Hi Adrian, thanks as always for sharing all this info!. I need to buy a macbook for doing wifi capture and for work.
Which model do you recommend? I think should not be M1 processor. am i right?
Hi Alejandro, for regular, single channel captures the M1 works fine. I know Apple’s working on fixing the other issues and I expect a solution at some point. It all depends on what type of Wi-Fi captures you need to do.
The issues with wireless captures on an M1 Mac seem to be relegated to 80MHz captures. 20 and 40 seem to work fine. Fortunately, almost all my captures are done in environments where 20, or 40MHz is in use. But, once you do it on 80MHz the frames show as malformed in Wireshark.
Also, since the data is corrupt, Wireshark can’t properly identify what the frames actually are. That’s how I initially noticed the problem when I first got my M1 last year. Half of the management frames were showing as having data rates above 54mbps, which is impossible.
I have been trying to get Apple to look at this, but the answer I get it “we don’t see the problem”. I’ve collected and sent at least 12 different captures form as many different M1 MacBooks all showing the same issue.
hi Adrian and community. I need to buy a new Mac for WiFi troubleshooting, expecting some work on 802.11ax. Should I go and buy the M1 chipset? What is the current status? thanks!!
You can also mention omnipeek doesnt work, because we can now only run windows arm on MAC which omnipeek doesnt support and there are no plans to support it (y) .
Hello Adrian
I’m a Wireless Engineer using my MAC for TSing and I love your tools. My MAC is MacBook Pro 13 2016 on macOS Big Sur, should I got to Monterrey or stay on Big Sur? I just need the Wi-Fi tools working
What’s the most steady OS in your opinion?
Thanks
Those Intel MacBook Pros work great with all the tools on Monterey, so you should be fine moving to Monterey. Cheers!
Thanks Adrian
A year and a half later, has Apple fixed these issues?
I’m on a 2021 MacBook Pro with an M1 Max, on macOS 12.6, and happy to test if needed.
Hi Marc, as indicated in the update notes in the blog, #1 was partially fixed, and #2 was supposedly fixed but it’s difficult to verify at a 100%.
Thanks for this great article. What I’m noticing in our environment (Cisco Meraki) is that the M1 has bizarre roaming behavior. Once a channel change happens, my M1 Macbook Pro (2020) roams to an Access Point extremely far away, then eventually roams back to closest. Client balancing is not enabled and auto channel management is enabled. I have both an Intel based Macbook Pro and Chromebook on the same desk and the roaming event doesn’t occur.