https://www.intuitibits.com/2021/02/05/whats-going-on-apple-part-2/ Skip to content Intuitibits Logo Intuitibits Logo Search for: [ ] [] * Home * Products + Airtool 2 + Transfer + WiFi Explorer + WiFi Explorer Pro 3 + WiFi Signal * Blog * FAQ * Contact * Search for: [ ] [] * Home * Products + Airtool 2 + Transfer + WiFi Explorer + WiFi Explorer Pro 3 + WiFi Signal * Blog * FAQ * Contact * * Home * Products + Airtool 2 + Transfer + WiFi Explorer + WiFi Explorer Pro 3 + WiFi Signal * Blog * FAQ * Contact Search for: [ ] [] Previous Next What's going on, Apple? - Part 2 By Adrian Granados|2021-02-19T12:48:04-05:00February 5th, 2021| Airtool, WiFi Explorer Pro, WiFi Explorer Pro 3| 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 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_wifi_explorer_pro] Passive scan only shows a few networks in the 5 GHz band. 2. Packet captures include many corrupt or garbage frames 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. [m1_malformed_capture] 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. Share this blog post! FacebookTwitterRedditLinkedInEmail About the Author: Adrian Granados [3b52e5935] Adrian is the CTO and Lead Developer at Intuitibits LLC. He started developing wireless tools for iOS and Mac in 2009. He's interested in programming, UI/UX design, wireless networks and enjoys cooking, soccer, and LEGO building with his kids. 3 Comments 1. [ab29ff] Jonas Mellander February 9, 2021 at 8:50 am - Reply 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. + [3b52e5] Adrian Granados February 9, 2021 at 1:45 pm - Reply 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. 2. [0a4d47] Derrick April 30, 2021 at 3:52 pm - Reply My first guess for #2 would be that deaggregation was broken in the monitor, but what do I know? Leave A Comment Cancel reply [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment[ ] [ ] [ ] [ ] [ ]Save my name, email, and website in this browser for the next time I comment. [Post Comment] Search for: [ ] [] Recent Posts * Capturing Wi-Fi packets on your Mac using external adapters * Capturing packet traces from your iOS device * Using a Raspberry Pi 4 as a remote sensor for WiFi Explorer Pro and Airtool * What's going on, Apple? - Part 2 * Multi-channel captures in Airtool 2 Tags active adapter analysis annotations beacon capture channel dfs dynamic frequency iOS iPhone M1 macOS monitoring passive python radar remote roaming RSSI scanning sdr security sensor tftp troubleshooting usb wireshark wlanpi Tweets by intuitibits Archives * March 2021 (2) * February 2021 (3) * December 2020 (1) * November 2020 (1) * September 2019 (1) * June 2019 (1) * August 2018 (1) * April 2018 (1) * January 2018 (1) * November 2017 (2) * September 2017 (1) * August 2017 (2) * July 2016 (1) * June 2016 (1) * May 2016 (1) * March 2016 (1) * May 2015 (1) * April 2015 (1) * January 2014 (1) * February 2013 (1) Follow Us (c) 2021 Intuitibits LLC. All rights reserved. Apple, the Apple logo, iPad, iPhone, iPod, iPod touch, Mac, iMac, MacBook, MacBook Pro, MacBook Air, and macOS are trademarks of Apple Inc., registered in the U.S. and other countries. MetaGeek and Wi-Spy are registered trademarks of MetaGeek, LLC. RF Explorer is a registered trademark in EU and other countries. Ubertooth One and HackRF One are registered trademarks of Great Scott Gadgets. RapidConnect is a registered trademark of MMB Networks. Other product and company names mentioned herein may be trademarks of their respective companies. [svg] We believe in the low threshold, high ceiling principle, creating intuitive and reliable applications that are simple enough to get you started yet powerful enough to take you as far as you need to go. COMPANY Blog Contact PRODUCTS Airtool 2 Transfer WiFi Explorer WiFi Explorer Pro 3 WiFi Signal LEGAL Terms and Conditions Privacy Policy Cookie Policy Copyright (c) 2021 Intuitibits LLC. All rights reserved. Intuitibits uses cookies to personalize your experience on our website. By continuing to use this site, you agree to our cookie policy. Click here to learn more. OK Go to Top