sniffwifi

Just another WordPress.com site

Archive for April 2012

Worthless Capture

leave a comment »

You’re never gonna sniff again
Faulty packets got no meaning
Though it’s easy to pretend
I know I’m not a fool


Oh, how I want to sing those lyrics. To whom, you ask? Why, to Cisco Clean Air access points. Also, AirMagnet Enterprise sensors, Aruba Air Monitors and anything else that offers me a careless whisper worthless capture.


Unlike WHAM!, distributed WLAN analysis is in. It seems that nowadays I can’t swing a dead cat without hitting someone who is proud as punch of their system of distributed sensors that does something (spectrum analysis, intrusion detection, frame capture) cool.

Distributed sniffing (meaning frame capture) or spectrum analysis does have its uses. If you need to find a rogue AP, identify a denial of service attack or get a general overview of your RF environment, systems like Cisco CleanAir, Fluke AirMagnet Enterprise and Aruba AirWave RAPIDS can all be useful. The problem is that these products are often used for more than that.

Any distributed sniffing product relies on the fundamental conceit that the capture is accurate. If a distributed capture AP/sensor sees a station transmitting 70% of its frames at a 52 Mbps rate, then the sniffing software assumed that, indeed, 70% of that station’s frames went through the air at 52 Mbps. The problem is that a distributed sensor is not at the same location as the station. Once a capture is done away from the location of a station, the capture becomes nearly worthless. Too many things about the RF environment will be different for the information to have any value.

The differences between captures near a station and far away from a station can be seen below.

First, a capture done with Fluke AirMagnet WiFi Analyzer filtered only my AP’s traffic. The capture device is placed right near my AP as a movie was streaming from an iPad that was about 35 feet away (with some obstructions in between):

The important thing to look at is the CRC Error percentage. When the CRC error percentage is low, that means that the capture is useful. Here the CRC error percentage is 0%, so this is a good capture. And that is usually the case when AP/sensors capture frames being transmitted by other APs. Both devices are typically mounted in the same general space as each other, so very few frames are missed.

The problem shows up when I look at the same AirMagnet capture filtered on my iPad. The capture device is in the same place it was before (near the AP), but the iPad is about 35 feet away (with several obstructions in between the AP and iPad):

It’s tough to read, but that screenshot shows that a whopping 28% of captured frames being transmitted by my iPad were read as CRC Errors. That is a worthless capture. It may be showing me 30% Retrys (a bad number for just about any WiFi network), but when over one quarter of my frames were corrupted on capture there is no way of knowing it that is the true percentage of collisions.

The real crime in all of this is that AP/sensor-based captures of frames and RF energy are commonly used by controllers and wireless management software to determine important parameters like AP channel and AP transmit power. And wireless intrusion detection systems use these captures to warn you about alarms. Sometimes this information is good enough to help, but often times the result is poor channel selection, AP-on-AP interference and false IDS alarms.

I realize that it is silly to recommend that people do station-located frame captures for every little WiFi problem, but I do think that many organizations ignore the huge differences in quality between AP/sensor captures and portable captures. My advice is to use distributed AP/sensor-based capture products for rogue AP response, DoS detection and location tracking, and use portable sniffing software to identify problems with the more serious wireless problems like channel selection, AP interference, mobility and collisions.

Written by sniffwifi

April 19, 2012 at 8:41 pm

Posted in Uncategorized

How to set up OmniPeek to analyze Phones on a WLAN

leave a comment »

Blogger’s stats are telling me that yesterday was the most-trafficked day in the history of this blog, and as much as I want to credit Titanic’s 100 year anniversary, I have to think it is because of my most recent blog post. That post showed how I used WildPackets OmniPeek to analyze the damage that unassociated smartphones can do to a WLAN. This follow-up is just a quick tutorial on how I set OmniPeek up to do that analysis.


In order to follow the same steps I did to analyze smartphone activity on a WiFi channel, you’ll need a licensed version of WildPackets OmniPeek (Basic, Professional or Enterprise will do) and an 802.11a/b/g/n WiFi adapter that is compatible with OmniPeek. I used OmniPeek Enterprise with a Cisco-Linksys WUSB600Nv1 adapter.

To start, insert the WiFi adapter (if necessary) and open OmniPeek. Click the New Capture button to bring up the Capture Options window. Next, click the 802.11 link on the left hand side of the screen and select the Scan radio button. (If the Scan button is grayed out, that means that OmniPeek is trying to capture with an adapter/driver combination that is unable to use monitor mode.) Then click two successive OK buttons in order to open an OmniPeek capture window that looks like this:

After you click the green Start Capture button, OmniPeek begins capturing frames, including those being sent from the smartphone you are trying to analyze.

To view the list of APs and stations near you (including the offending smartphone), click the WLAN link on the lower left hand are of the OmniPeek capture window. If you are in an area with lots of WiFi, the WLAN screen may look sloppy, so you’ll probably want to right-click on any AP or station and select Collapse all. Collapsing the information on the WLAN screen will give you something like this:

Once in the WLAN screen, click the [+] to the left of your WLAN and then click the [+] to the left of your AP. Those steps cause OmniPeek to show the list of stations that are associated to your AP, and it should look like this:

Once you are able to see a list of stations that are associated to your AP, the next step is to name your smartphone and create a filter. To name your smartphone, you will have to find the phone’s MAC address. (iPhone MAC addresses are found via Settings -> General -> About.) Once you have the phone’s MAC address, right click the smartphone’s MAc address and select Insert into name table. You will get this screen, where you can give your smartphone an OmniPeek nickname:

With the phone named, the next step is to create a filter that will allow you to see only the frames being sent or received by the smartphone. Right-click the smartphone in the WLAN screen and select Make filter. OmniPeek will default to giving you filter settings that allow you capture only the frames that are being sent or received to your smartphone:

The final step in configuring OmniPeek to capture a single smartphone’s WiFi frames is to enable the filter that you have created. To enable an OmniPeek filter, just navigate to the Filters screen on the left hand side of the screen and check the checkbox for the filter that you just created.

And that’s it. If you have followed these steps, your WildPackets OmniPeek will be capturing only what your smartphone is sending or receiving. The only other tip I can give is that you can always clear out old information and get a fresh capture by clicking the red Stop Capture button and then re-clicking the green Start Capture button. I did that at one minute intervals in order to gather the information I used for the Phones on a WLAN blog post.

Written by sniffwifi

April 15, 2012 at 4:03 am

Posted in Uncategorized

Phones On A WLAN

with 7 comments

Enough is enough! I have had it with these motherf*cking smartphones on this motherf*cking WLAN! 

Neville Flynn, played by Samuel L. Jackson in Snakes on a Plane (paraphrased) 

Oh, if only our wireless networks could be saved from smartphones by a foul-mouthed constable. Instead, we have to deal with them. I’ve done a bit of sniffing recently in an attempt to figure out how much damage a roving smartphone actually does and it led me to a radical conclusion.

At halftime of a Los Angeles Clippers game a few months ago, I had the occasion to speak with someone who works with the Staples Center WiFi network. He was unable to share too many details for security reasons, but one thing he did share were the problems Staples Center has with smartphones. 
When people attend a sporting event, thousands of WiFi-enabled smartphones are brought into a large open space. The Staples Center WiFi guy told me that the WLAN infrastructure shows that thousands of Ad-Hoc networks are created by these smartphones, mostly in the 2.4 GHz frequency band. The end result is that the 2.4 GHz band is nearly unusable to media members, vendors and employees of AEG (the company that owns and operates Staples Center). The Staples Center WiFi guy’s interpretation is a little bit off, I believe, because Cisco’s controllers and management software are known to incorrectly classify unassociated, probing client stations as Ad-Hoc networks. (And feel free to correct me in the comments area if Cisco has a way to fix the classification of unassociated probing stations.) The way that these smartphones are classified by the Cisco infrastructure is irrelevant, though. What is relevant is that these devices are causing serious damage to the Staples Center WLAN, and any other WLAN that has lots of people crowding into a big, open space.
In order to assess the damage that smartphones cause, I used WildPackets OmniPeek to capture the activity of my iPhone 4. The iPhone 4 has a 2.4 GHz 802.11b/g/n WiFi adapter. The iPhone 4’s WiFi adapter has a single radio chain (“radio chain” essentially meaning a transceiver/antenna pair) and is incapable of using 40 MHz channels or the short guard interval. In plain(er) English, the iPhone 4 is, at best, a 65 Mbps device in the crowded 2.4 GHz frequency band.
Now, a debate can be had on whether the phrase “65 Mbps device in the crowded 2.4 GHz frequency band” means inherent trouble or not. I say “no”, some people say, “yes”. (I am correct, of course.) For this blog post, let’s set that aside and just look at the impact that a typical smartphone has on the WLAN.

Here is a screenshot of an OmniPeek capture that I did for all traffic that an unassociated iPhone4 is a party to when the phone is turned on and unassociated for one minute:

There are a few important things I am seeing in that capture. The unassociated phone only caused 128 frames to be transmitted on the channel that I captured on. Compared to a typical, active client station, that is pretty good. The problem is that the traffic is large (well over 300 bytes when in the form of a Probe Response), the traffic uses a low rate (1 Mpbs, or whatever the lowest Basic Rate is) and the client station is also causing similar amounts of traffic on other channels (definitely channels 1/6/11, and probably other channels as well).
Contrast the above screenshot with an OmniPeek screenshot taken after an associated iPhone 4 was operating on the channel for one minute:
The associated smartphone caused 229 frames to be added to the channel. More frames is bad, usually. In this case, however, more frames is not so bad. The frames here are smaller (a bunch of 28 byte Null Data frames accompanied by 14 byte Acknowledgment frames) and the frames here use higher rates (the highest Basic Rate will typically be used for the Null/Ack power save sequence).
Let’s even do some rough math on this. If we assume that the physical layer overhead (PLCP header and preamble) is identical for all frames since we are looking at traffic going to or from a single device, then the MAC layer overhead is what will make the difference. When the phone is unassociated, lots of 117 byte and 369 byte frames were transmitted at 1 Mbps. That means 117 microseconds or 369 microseconds used per frame for MAC layer activity. When the phone is associated, lots of 28 byte and 14 byte frames were transmitted, usually at 24 Mbps. That means about 1 microsecond or a half of a microsecond used per frame. If we extend the math a bit, that means that each Probe Request/Response pair has the equivalent overhead of about 278 Null/Ack pairs at the MAC Layer. And even if we add 40 microseconds of overhead for the PLCP (a typical amount when 802.11n mixed mode is used), that still means that the unassociated station causes about seven times as much dead (read: unavailable for data) channel time per Probe Request/Response pair as an associated station causes for a Null/Ack pair. And that is not even accounting for the fact that the unassociated station is likely causing this overhead on at least three channels.
If the preceding paragraph reads as a bunch of uber-techie mumbo jumbo, let me simplify it: a powered on, inactive smartphone that is not connected causes at least ten times as much damage to your public WiFi network as the same phone when it is connected.
The obvious solution to the problem, then, is to treat smartphones the exact opposite way that Samuel L. Jackson’s character treats snakes on 2006’s internet darling, Snakes on a Plane. Neville Flynn (profanely) wants the snakes off his plane. You probably want smartphones on your WLAN. It may sound counter-intuitive, but it may also prevent users from telling their friends that your WiFi network is the Snakes on a Plane of wireless networks.

Written by sniffwifi

April 11, 2012 at 6:59 pm

Posted in Uncategorized