How do I put my wireless interface back into managed mode from monitor mode in Mac OS X without rebooting?

Question

On Mac OS X, I can turn my wireless interface in monitor mode, as explained in a 2007 OSXdaily article.

I can also use the integrated Wireless Diagnostics utility to do so. Unfortunately, none of those two options seem to offer a way to put back my interface in ‘client’ mode (the default, also called managed mode in Linux circles). The only way to do this seems to be a reboot. Is there a better option?

Solution 1

There is no way for any process leave the interface in monitor mode after exit.

While this holds true most of the time when we run (on El Capitan):

# sudo tcpdump -p -I -i enX -y IEEE802_11 

The interface may get stuck on monitor mode after tcpdump exits (where X is a wireless network card that supports monitor mode). Note that I say "may". It is not a mistake. A few times it returned to normal mode. Most of the times it did not.

Running this command afterwards fixed it (which is my answer to your question):

# sudo tcpdump  -I -i enX -p

This led us to believe that there is something wrong with tcpdump or Mac OS X and the way they interface with each other (the problem could also be on libpcap which sits in between).

We proceeded to read the source code of libpcap and found multiple precious gems on the joy of monitor mode on Mac OS X which, in turn, pointed us to the fact that selecting a particular DLT mode (using the -y flag on tcpdump) would cause Mac OS X to put the interface in monitor mode (without additional work of libpcap). Also, contrary to other systems, no special cleanup of monitor mode state seems to occur on libpcap when it runs on Mac OS X.

In our case it is imperative that we are able to get 802.11 management frames (probe requests) while maintaining base station association and connectivity.

We ended up building a program that interfaced directly with libpcap and simply requested for monitor mode pcap_set_rfmon(pcap, 1) (without selecting a DLT mode) before activating the capture on the interface. Upon exit the program simply closes the capture handle and everything returns to normal (eye of Sauron disappears) and network card is still associated with the network. Internet access is working throughout execution.

Solution 2

There is no way for any process leave the interface in monitor mode after exit. So no matter what tool you're using to get into monitor mode, simply exit/quit/kill that tool and you'll be back in normal operation.

You'll know your interface is in monitor mode if the Wi-Fi Menu Extra icon turns into the Eye of Sauron / Illuminati Eye instead of bars. If it shows bars (even all grey bars), or an exclamation point, or the "up arrow" AP-mode icon, or the "computer screen" computer-to-computer (a.k.a. "ad hoc", IBSS) icon, or the empty-wedge "Wi-Fi off" icon, or the "X" "driver not loaded" icon, then it's not in monitor mode.

I think you may be conflating monitor mode with the interface simply being disassociated (not connected to a network, bars all grey). If the interface is not associated to any network, simply select a network. Or just turn Wi-Fi off and back on again to let it auto-choose for you.

Comments

[Admin]

Why are you putting it in monitor mode? If it's to capture network traffic, you can do that with the -I flag to tcpdump/TShark and GUI options in Wireshark, and, when they're done, the interface will go back to managed mode.

[Francois G]

Tcpdump (etc) turns the interface in promiscuous mode, which requires association (contrarily to monitor mode en.wikipedia.org/wiki/Monitor_mode) Besides, I'm not interested in TCP packets.

[Admin]

Tcpdump turns the interface into monitor mode if you use the -I (capital-I) flag; I know that because I wrote the code that makes it do so (and I'm quite aware of the Wikipedia page in question, I'm one of its editors). If you're not interested in TCP packets, run tcpdump with the filter "not tcp"; the "tcp" in "tcpdump" is a historical artifact, not an indication that it can only handle TCP.

[djsmiley2kStaysInside]

There's a few easier ways than using top. You can ps aux | grep airportd and that'll show you the PID but even eaiser would be to run 'sudo killall airportd'

[Jochem Schulenklopper]

Great answer. You deserve bonus points for the "eye of Sauron" reference :-)