Testing Mobility with OmniPeek: Isolating the Station's Traffic

WildPackets OmniPeek has long been my favorite WiFi sniffing software, but lately this blog has been short on posts about it.  That needs to change.  So today I start a multi-part series (number of parts to be determined) on how I use OmniPeek to help me plan for and troubleshoot mobile devices.

Mobility (defined here as seamless roaming between WiFi access points [APs]) is a longstanding enterprise WLAN issue that has kind of taken a back seat to supporting personal devices (a.k.a. BYOD).  For many enterprises, mobility remains important.  Car dealerships with push-to-talk handsets, warehouses with barcode/RFID scanners and retail locations with point-of-sale terminals are all examples of locations that require user devices to move around a large area without dropping connections, losing speed or experiencing choppy service.

The solution to supporting mobility is to make sure that APs have adequate overlapping coverage without interfering.  It sounds simple, and it is.  But it's not easy.  We're trying to serve two opposing masters.  On one hand we want APs close together to provide adequate coverage overlap.  On the other hand we want APs further apart to avoid interference.

Before getting into a detailed discussion about sniffing AP coverage, we first have to consider client station behavior.  Why?  Because stations control connections.  The WLAN infrastructure does not tell a station when and where to connect.  The station chooses.  (This makes a ton of sense when you think about it, but it ticks off network admins to no end).  Since the station chooses, our first task is going to be to isolate the relevant station in OmniPeek.  I'm going to use my iPad as a guinea pig because those things are known to be bad with mobility.

I start by inserting my OmniPeek capture adapter and booting my MacBook Air (late 2010/non-AirPlay streaming edition) into Windows 7.  In this case I chose to use a Cisco-Linksys WUSB600N 802.11a/b/g/n 2x2:2 USB adapter, but I usually like to use the D-Link DWA-160 USB (same 802.11n specs) adapter.

Once the adapter is inserted, I launch WildPackets OmniPeek (in my case version 6.6.0) and begin a monitor mode capture that scans across all 2.4 GHz and 5 GHz channels.  I kind of skipped over how to get monitor mode and the channel scanning thing going, but I think the OmniPeek user guide lays those tasks out clearly.

With an capture window open, I click the green Start Capture button to begin capturing.  I then click the WLAN link on the left menu bar in order to see which channel my iPad is on.

The picture turned out fuzzier than I'd hoped, but it does show that there are two APs using my SSID of "2788", one on channel 1 and the other on channel 11. 

Now, another thing that somewhat fuzzy screenshot shows is that there is a device named "iPad" associated to the AP that is operating on channel 1.  WildPackets OmniPeek does not have the ability to detect that my client station is an iPad.  I had to give my iPad a name in OmniPeek.  If you have yet to give your device a name in OmniPeek, you can do so by right-clicking the station (which will be identified by OUI/MAC address by default) and clicking Insert into name table.  Just make sure you choose a name that you'll remember and be able to quickly reference.

Once I know what channel my iPad is using, I need to set OmniPeek to capture on only that channel.  To make OmniPeek capture on a specific channel, I just right-click the little area at the bottom of the screen where it shows what channel I'm currently capturing on.  After the right-click a menu will pop up that will allow me to choose which single channel I'd like to capture on.  Just make sure you choose a "bg" channel instead of an "n40" channel if the AP your station is association to is using a 20 MHz wide channel.

After my capture is going on the correct channel, I then need to create a pre-capture filter so that I can capture only traffic that is relevant to my iPad's mobility.  

(This, by the way, is a major area where the CWNP Program and I differ on the topic of WiFi sniffing.  The CWNP Wireless LAN Analysis course [which is designed to prepare students for the CWAP certification] has material indicating that pre-capture filters should rarely be used.  This is poppycock of the highest order.  I use pre-capture filters all the time and they are absolutely essential to performing some of the most useful tasks a WiFi sniffer is capable of.)

To create a filter for my iPad's mobility traffic, I just right-click on iPad (or whatever name you gave your client station) and select Make filter.  From there, you will have the option to choose whether you want to capture traffic going to your iPad, traffic coming from your iPad, or traffic in both directions.  You don't want all of the traffic because that is not specific enough.  So...

Pop quiz: When creating a filter for use in planning for iPad mobility, do you want a capture filter that captures the traffic going to your iPad or from your iPad?

What do you think?

To or from the iPad?

To?

Or from?

Hmm...

Enough stalling.  You want a filter capturing what's going TO your iPad.  Like so:

Notice how there's the little backwards arrow in the middle with "Address 2 to 1" underneath?  That's telling me that I'm capturing traffic that had a destination MAC address that matches my iPad's.

If you're wondering why you want a filter that captures traffic going to your iPad, you'll have to check out the next part of this series.  Next time we're going to activate our newly created traffic-to-iPad filter and really test the iPad's mobility behavior.