Wireless Sniffing in Windows 7 with Netmon 3.4

I leeched this from the CSC forum. This was posted by Aaron Leonard. Aaron goes through the steps of turning your WIN7 into a sniffer. 

With Microsoft Network Monitor (Netmon) 3.4, you can now perform some decent 802.11a/b/g (and maybe 11n) wireless sniffing in Windows 7, using your standard wireless adapter.  The file saved from Netmon can be read by latest bleeding edge (1.5.0) Wireshark, though not in OmniPeek.  Note that, even though Netmon 3.4 is supported with XP SP3, it supports wireless sniffing only if running Win7 (and presumably Vista.)

I've tested with the following adapters/drivers:

• An Intel 6300 running drivers 13.2.1.5 and 13.5.0.6.  This adapter works well with 11a/g but does not support 11n. 
• A Linksys WUSB600Nv1 with Ralink driver 3.0.10.0.  This driver says that it supports 11n (which function I didn't test).  It seemed to report all packets as having an RSSI of -50, and as being of data rate "3.5 Mbps".
• An Atheros AR9285 with driver 8.0.0.258.  Driver reports 11n support (not tested.)  RSSI values and data rates look sound.
• A Cisco CB21AG with Atheros driver 1.0.0.120 - this also reported weird data rates (1Mbps showed up as "116 Mbps" and 11 Mbps as "124     Mbps".)

Install Netmon 3.4

Download Netmon 3.4 from Microsoft.  If running Win7 64bit, get and install NM34_x64.exe.  You'll have to log off and back on again after installing.

Sniff wireless packets from a channel

Note: if using PROSet for Win7, set it to "Use Windows to Manage WiFi".  Otherwise, PROSet is apt to take control of the adapter out from under Netmon.

Launch Netmon.  Check the wireless adapter of interest, and uncheck the others.

Click the New Capture button, then the Capture Settings button.  This pops up the Capture Settings window.  Highlight the adapter of interest and click Properties which pops up the Network Interface Configuration window.

In the Network Interface Configuration window, click [Scanning Options].  This pops up the WiFi Scanning Options window.  Check Switch to Monitor Mode.  Select the Select a layer and channel button.  Select the band and channel of interest.  Click [Apply].  Important: do not click [Close and Return to Local Mode], but keep the WiFi Scanning Options window up all the time you're capturing the sniff.

Now (keeping the WiFi Scanning Options window open), go back to the Network Interface Configuration window and click [OK] to get rid of it.  [Close] the Capture Settings window.  Back in the main Network Monitor window, click Start.

This should now cause NetMon to capture all wireless frames.  Sometimes  though it will just sit there and not capture any frames.  When this  happens, try restarting NetMon, disabling/reenabling the adapter, etc.

When done, click [Stop] and use File -> Save as to save the .CAP file.

Analyze with Wireshark

Wireshark up through 1.4.x cannot grok a Netmon 2 format file.  However, latest development Wireshark (1.5.0 and above) can.  I'm using Wireshark 1.5.1.

Problems

• NetMon recently just stopped being able to see my wireless adapter - it simply was not present in the Netmon start page, even though it was up and working fine.  Rebooting did not help.  Uninstalling Netmon Parsers, then Netmon, then reinstalling NetMon 3.4, then logging off, then logging back on, did work.

802.11: Null Data Frames

I was speaking to a friend last evening on the topic of client troubleshooting. The discussion came up about roaming and roaming aggressiveness. We talked about the different aspects of client behavior and the discussion turned into an 802.11 frame discussion. More specifically the NULL frame.

The Null Data Frame is a very interesting frame. In fact, most folks overlook these frames, perhaps because they don’t know their importance. Just a few months ago I was troubleshooting a client issue and the NULL frame confirmed by idea and backed my findings as it pertained to a wireless issue I was troubleshooting

Lets look at the NULL frame and it's importance. 

The Null Data Frame is a control frame. It is only transmitted by a STA (wireless client). Access points do not transmit these frames. It carry’s no data payload. In fact, the only purpose of this frame (by standard) is to carry the power management bit in the frame controlled field. The power management bit will be either "0" zero or "1" one. 

When the STA sends a power management bit of "0" to the access point in which it is associated to, it is the STAs way of informing the access point that the STA is in an active power state (awake) and transmission of frames from access point to STA should be normal.  

When the STA sends a power management bit of "1" to the access point in which it is associated to. This is informing the access point that the STA is going offline and any frames that come into the access point for this STA should be buffered at the access point till the STA returns and sends a NULL frame of "0", active state. 

A text example of the exchange: 

STA ---NULL FRAME "0"----->  AP "Client says to the AP: Hey AP I’m online send me data"

STA ---NULL FRAME "1"----->  AP "Client says to the AP: Hey AP buffer any transmissions coming in for me. Ill be back in a bit (no pun intended)"

So why would a client go offline and what is the importance !?!?! Its very important. Lets talk through a few examples. 

There are two main reasons why a STA will go offline, or send a power man bit of "1" to an access point.

Power Save Mode: PSM allows a STA to go into "sleep or doze" mode. PSM essentially turns off the NIC radio for short burst to conserve battery power for a device. You will notice significant power conservation and longer battery life when PSM is enabled. VoIP phones, PDAs and other small battery form factor devices benefits from PSM. A word of *caution*, be aware that some applications can suffer from aggressive power save mode options. 

Active/Passive Scanning: The other reason why a STA will inform an access point to buffer its frames by sending a power man bit of "1" is when it’s ready to roam. Suppose a client has hit its roaming threshold and is seeking out another access point to associate to. In order to seek out other access points in the area it has to go off channel. By doing so, the STA tells the AP, buffer the frames man, ill be back for them in a bit!

Example:

The STA is on AP TEST, AP test is on channel 1

The client will send a NULL FRAME to the access point with the man bit of 1. The STA goes offline and floods channels 2,3,4,5,6,7,8,9,10,11 (depending on configuration of the client of course) with probe request looking for other APs.

Lets look at a packet capture:

Note frame 75 - This is my STA sending the AP a Data Null Frame. If you open the packet and drill down into the frame control you will see the power management bit is set 1.

 

Note frame 78 - This is my STA sending the AP a Data Null Frame. Note that the power bit is set to 0. Indicating to the STA is back on channel and any data that was buffered and future date should be sent to the client until its next doze state. 

Note frame 82 - STA is going back to bed!

 

What is also interesting to note is the TIME stamp. Look at the time delta between frames 75 - 78. This is the period of time the STA was off line, generally speaking.

You might ask when does the client come back online to the AP. Well that is dependent on how the STA is configured. For example, Intel has what I call the "slide bar" for PSM. The more aggressive the mode the longer the STA will be in sleep or doze mode. 

Now that you know what a NULL frame is and its purpose. If you are troubleshooting a STA issue pay attention to what the STA is telling the access point! If a client is sending NULL frames there is a reason why!

802.11 BEACON Discussions

Coming March 2009!!