OmniPeek Remote Assistant (Cisco TAC)

Arron Leonard from Cisco TAC released a great post about ORA on CSC.

OmniPeek Remote Assistant

VERSION 4 

Omnipeek Remote Assistant (ORA)

Cisco TAC can provide the Omnipeek Remote Assistant application to assist in performing wireless packet captures. The tool will capture wireless packets and encrypt them for processing by the TAC. A full version of Omnipeek Enterprise is required to decrypt and analyze the capture files.

Installation

You should receive a ZIP file from TAC – such as “ora131Cisco.zip” (the filename may change with different release versions). Open this file and Navigate to the “OmniPeek Remote Assistant” folder – run the installer “ora131.exe” and follow the installation instructions.

Supported Wireless Adapters and Drivers

Capturing Wireless Packets with ORA requires the use of supported Wireless Network Adapters along with the appropriate driver version. To view a complete list of supported adapters and drivers, please see:

http://www.wildpackets.com/support/downloads/drivers

In most cases, the Ralink USB adapters will be the easiest to install - and, because you can install multiple USB adapters on a single laptop - they are the best way to get a multichannel capture.  The following Ralink adapters have been tested by Cisco TAC:

Linksys WUSB600N (V1 and V2), Linksys AE1000,ALFA AWUS051NH

Driver Installation for Linksys USB600N with Windows XP

1. TAC can provide the OmniPeek driver for the Ralink USB adapters.  You should receive a ZIP file “RALINKUSB-1_4_0_18.ZIP”. There will be 2 folders in the archive -- “Win2kXP” for 32-bit Windows and “WinXPx64” for 64-bit Windows. Extract the contents of the appropriate folder for your Operating System to a specified location.

2. Insert the Linksys USB600N adapter.

a. If this is the first time using the adapter on the workstation, Windows  will start the New Hardware Wizard. Do not search for a driver  automatically and click Next. Skip to step 3.

b. If you have previously installed the Linksys USB600N on your  workstation, you will need to change the driver to the Omnipeek version.  Go to Start > Control Panel > Network Connections and Right Click  on the Linksys adapter and click Properties. In this example, the  interface is “Wireless Network Connection 3”.

Under the General Tab, Click the “Configure…” button, and then click on the Driver Tab > Update Driver. This will prompt the Hardware Update Wizard.

3. Select “Install from a list or specific location (Advanced)” and click Next. Select “Search for the best driver in these locations.”, include the location of your extracted driver files and click Next:

4. Windows will now search and install the Omnipeek driver. If you receive the following warning message, click “Continue Anyway”.

5.  The driver installation should complete and the adapter is now ready for capturing packets with ORA.

Running Omnipeek Remote Assistant

If the correct driver isn’t loaded, ORA may appear to work, but not provide the option to select the desired channel to monitor. The Channel cell will read ‘Ethernet’ or ‘Wireless’ and not offer the option to select a channel:

Capture Settings

Select the desired adapter(s) to perform the capture and indicate the desired channel. If you have multiple supported adapters installed you can capture on multiple channels simultaneously (but you cannot mix wired and wireless interfaces at the same time). You can select either an 802.11b/g channel or 802.11a channel in the dropdown. You can select 40 MHz 802.11n channels using the (n40l) or (n40h) options. The n40l will be the selected channel and adjacent lower channel, while n40h will be the selected channel and adjacent higher channel.

File Properties

Select the folder you would like to store the capture files in. You can then also specify the file rollover size. Each new filename will include a timestamp so data will not be overwritten.

Capture Control

If you have selected correct adapter/channel settings, you will now be able to click the Start/Stop buttons at the bottom. You will not be able to see the packets, but you will see the counters incrementing. Click Stop when finished.

Uploading the files to TAC

If the capture file(s) are too large for email, you can upload them to your TAC Service Request:

https://tools.cisco.com/ServiceRequestTool/query/

Enter your SR Number, and then click on File Upload.

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!!