Monitor mode captures on OSX

[mike909]

I'm trying to determine the difference between capturing 802.11 frames in the following ways on OSX (10.8.5). It's a bit esoteric, but I commonly use this method to capture frames for importing into Eye PA, but perhaps I'm missing something.

Option 1: use "airportd":
$sudo /usr/libexec/airportd en0 sniff <channel>

Option 2: use "airport" followed by tcpdump:
sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport --channel=<channel>
sudo tcpdump -I -P -i en0 -w /tmp/capture.pcap (or alternatvely eliminate the -w and watch packets real-time).

From what I can tell:
Both commands, according to the wifi icon on OSX, put the interface into 'monitor' mode.
Both commands output a pcap file that is readable in both wireshark & Eye PA.
Both commands appear to capture management, control and data frames.

The rub:
Option 1 disconnects you from the network. This is expected, when putting an interface into 'monitor' mode.

Option 2 does NOT disconnect you, provided you've set the channel to the same channel your currently connected to. This has a distinct advantage of keeping your connection up while capturing in monitor mode.

My question: Option 2 does not seem like it should work, or more specifically, it does not seem like I should be able to remain connected while also capturing frames in monitor mode. Has anyone else encountered or looked into the validity of capturing frames w/ Option 2?

My workflow for Eye PA:
capture frames in OSX, launch VM of windows 7 (parralells, virtualbox etc.), and open the .pcap file in Eye PA via guest-to-host drive sharing. That enables me to use Eye PA when I forget to bring the AirPCap card along.

EDIT: I corrected the sytanx for the "airport" way (Option 2) to include the actual path of the binary.

[Joel]

Hi Mike,

Thanks for posting this! You can also do it via the GUI if that is easier for you.

In Mavericks:

Search Spotlight (Command+Space) for "Wireless Diagnostics"
When the application opens, press Command+2 or go to Window > Utilities to open the Utilities Window
Click on the Frame Capture Tab
Rename the output .wcap file to .pcap for use with Eye P.A.

[mike909]

Yep, that would equivalent to "Option 1", as it disconnects you from network. Many might find that easier.
Personally, I just make symlinks to the CLI commands, but it's just a preference thing.

EDIT: while on the subject, you may also find the other options useful, using (Option 2).
Examples:
First I make a symlink to make life easier:
$sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport
Now you can just type "airport" instead of the full path each time.

Print information on your current connection (like RSSI, SNR, Data-rate etc) to the terminal every two seconds:
$watch airport -I

Print currently seen SSID's w/ RSSI, Channel etc to screen:
$airport -s

Same as before but piping it to a file in xml format:
$airport -s -x > ssids.xml

Dissasociate from currently connected network. This one is handy, as the only way to do this via GUI (that I know of) is to turn wireless completely off, then back on. In some situations that could be annoying (like if capturing in wireshark, since the interface goes away when totally turned off):
$sudo airport -z

Not sure why I just spelled all that out, really you can just type "airport" without any switches and see the options.
Also, most of this is possible from the GUI, using the "wireless diagnostics" method as Joel pointed out.

[Joel]

Also, most of this is possible from the GUI, using the "wireless diagnostics" method as Joel pointed out.

...but the GUI is never as fast if you know your commands well. Thanks a ton for posting this!

[mike909]

I discussed this elsewhere and am posting here as a follow up. Kind of obvious, but point being: If a radio is transmitting, there's no way for it to be receiving at the same time. Hence, even if OSX is just probing to remain associated, the chance is there to miss frames. Option 1 should be used when absolute accuracy is required.
Option 2 can still be useful for a quick capture, especially if you want to see the frames real-time. Example: wanting to quickly verify data-rates being supported/mandatory, you can see that fly by in the tcpdump stream (just leave off the -w flag).

[ua549]

More importantly, the 802.11 wireless relies on CDMA which by definition cannot be full duplex.

That said, a node cannot miss receiving a packet sent by another node because it was transmitting. After a transmission there is a quiet period before another transmission can take place from any node. That quiet period is more than adequate for a given radio to switch between xmit/recv modes.

[mike909]

ua,
What about a collision? If a node is transmitting, and a collision occurs in the air (perhaps no RTS/CTS), isn't it possible that the collision would not be present in the capture since the radio was not receiving at the time of collision?

[ua549]

That can only be an issue if there is a hidden node issue. A hidden node occurs when node A is within range of the AP and node B is within range of the AP, but nodes A & B are not within range of each other. I've never encountered a hidden node situation. They only occur in geographically wide WLANs (>50m). The RTS/CTS protocol is optional in the 802.11 set of standards. Carrier sense is the standard method used to avoid collisions. There are other avoidance methods as well. For example 802.16 (WiMAX) uses time slots (scheduling) for collision avoidance.

[mrhieuson]

ua,
What about a collision? If a node is transmitting, and a collision occurs in the air (perhaps no RTS/CTS), isn't it possible that the collision would not be present in the capture since the radio was not receiving at the time of collision?

As I think, there are designs to avoid collisions.