I’ve also spent some time investigating this. While monitor mode works, setting the channel using CoreWLAN’s [CWInterface setWLANChannel:error:] API does not behave as expected. As a result, capturing isn’t reliable for third-party apps on Macs with the Apple N1 Wi-Fi chip or the MacBook Neo.
I've identified and submitted two issues:
FB22295165: [CWInterface setWLANChannel:error:] does not work on a disassociated interface, even though the documentation indicates it should, and it behaves correctly on older Macs.
FB22295685: Once in monitor mode, [CWInterface setWLANChannel:error:] reports a successful channel change and the interface reflects the requested channel, but capturing continues on a different channel (usually the channel the interface was operating on previously to being placed in monitor mode).
There also appears to be a race condition between entering monitor mode and macOS attempting to rejoin a network shortly after calling [CWInterface disassociate]. While I can’t confirm this definitively, there are cases where the interface seems to revert to an associated state after being placed in monitor mode.
I hope this can be addressed in a future macOS update, as the ability to capture Wi-Fi traffic and use apps that rely on it is one of the reasons many WLAN and IT professionals choose Macs.
Topic:
App & System Services
SubTopic:
Core OS
Tags: