@Christian_R, the behaviour of the drivers differs between Windows and iOS because the operating system requirements differ - while iOS requires that monitoring would be possible while the adaptor is associated to an SSID, Windows require that monitor mode disassociates the adaptor.

2 Answers

Is there any way to use internet during capture monitor mode without using Wireshark?

If you're using tcpdump, run it with the -I (capital-I) flag.

If you're using dumpcap, run it with the -I (capital-I) flag.

If you're using TShark, run it with the -I (capital-I) flag.

All of those do the same thing that Wireshark does if you enable monitor mode when capturing.

And, if you're doing capturing yourself, with a program using libpcap, you need to open the capture device using pcap_create() and pcap_activate(), rather than using pcap_open_live(), and call pcap_set_rfmon() on the pcap_t, with the second argument being 1, between calling pcap_create() and pcap_activate().

I am not aware of any capabilities to create additional interfaces like we can in Linux with the iw command where we can add a monitor interface along with the normal managed interface.

On my Macbook, I disagree with @Christian_R's comments that this is not possible. I can be in monitor mode and continue to communicate on my local network at the same time, as the original question states as well.

Some workarounds include using CLI tools like dumpcap and tcpudmp. Try something like:

dumpcap -i en0 -I <capture options="">

If you don't want to save the frames collected, set some small ring buffer and then just throw away the files. This really isn't any different than running Wireshark, just maybe less obtrusive. Tcpdump could just print to the console so you could have a tab in a terminal and not even save any files. However, printing to the console can be slow so depending on traffic load, may not be the best choice.

Even with all of this, I am not sure how useful this is. The monitor mode channel obviously has to be the same channel as the managed mode connection so that the client stays connected to the local network. Maybe that's OK if there is only one channel to capture. Also, frames ToDS (i.e. from the Mac in monitor mode to the AP) don't seem to get picked up in monitor mode, so it is difficult to analyze the full conversion from the Mac itself. There may be other limitations as well but since it really isn't best practice to operate in this way, I avoid it, so do not know all the possible shortcomings.

tcpdump works fine - be sure to use the -I (capital i) option to put interface in monitor mode. I see 802.11 frames passed without problem. Dumpcap will not show them; but tshark will. Use same option set.

I want capture 802.11 frames without any print or saving with using internet(cuz I don't need to it).

As with anything, you may have to compromise. Move to Linux then you can get closer to your requirements. Dumpcap won't print them; tcpdump won't save them.

Capturing all packets in WiFi is not compatible with your solution - as described, being connected to the network, some will not show. Therefore, you are not capturing all on your wifi, so not sure why missing ToDS frames is OK. Frames you inject would be ToDS, so would think that if one was to study frame injection, we would want to see ...(more)