Using AirMagnet to Analyze Voice Over WiFi

Mice in beer bottles, cold hands and supporting VoIP applications. These are a few of a wireless admin's least favorite things. And while this blog is the wrong place to look for solutions to two of those problems, here are some things to look for when evaluating software that lets you talk.

Voice over WiFi is a topic that yours truly has written about before, but never in any real detail on this blog. Part of the reason is that the previously linked whitepaper was something less than a performance for the ages, and part of the reason is that VoFi is still a ways away from being a pervasive technology.

Over the last few weeks the need to use VoFi software has arisen, and now is as good a time as any to describe how WiFi analysis software can be used to sniff out (pun not intended. Seriously. That word that is also in the name of this blog WAS TOTALLY ACCIDENTAL AND WITHOUT ANY INTENT AT SELF-PROMOTION AT ALL.) which VoIP application is best.

The two applications I sometimes use to make VoFi calls are Skype and Truphone. In the case of Truphone, "sometimes" means "often" and in the case of Skype, "sometimes" means "only when absolutely forced to by Skype loyalists who have yet to realize that the software stinks". Skype and Truphone both allow the user to make calls to the public phone network for a small fee and both run on a variety of mobile operating systems (including the only one the author really cares about, iOS). The big difference is that Truphone's calls usually sound great, and Skype's calls usually sound like you might expect this phone to sound. 

When deploying VoFi across an enterprise, applications like Skype and Truphone are less commonly used. The more likely scenario is that VoFi phones and/or SIP-based applications will be used. Still, the testing methodology is the same. It is best to get on a call, sniff the WiFi frames and see which application handles unlicensed frequencies the best.

I decided to switch things up for this post and use Fluke AirMagnet WiFi Analyzer. The same basic activities can be done with WildPackets OmniPeek, but this time I decided to go for AirMagnet's simpler navigation.

I began by using my iPhone 4 to make a Skype call on a Linksys 802.11g wireless router that is using TKIP encryption. Once in AirMagnet I navigated to the Infrastructure screen and selected Tx Total/% Total in the statistical analysis area that shows up here in the lower right hand corner of the screen:

I immediately found trouble. Look at that f'n Retry percentage. 34%!?! What the blue heck. Compare that with the same look at a Truphone call:

Same client station. Same wireless router. Same channel. One-sixth the Retrys. Just 6%, to be exact. After seeing this it ceased to be a mystery to me why Truphone's call quality has always been so much better on my iPhone.

But, why? What the heck is Truphone doing that Skype isn't? Let's let the eagle-eyed sniffers figure this one out.

First, here are two frames that were captured during the Skype call.

Skype from the wireless router (MAC address ending in 11:65):

Skype from the iPhone (MAC address ending in F5:C1):

Now, let's take a look at Truphone. Just like with Skype, the first screenshot will be of a frame sent by the wireless router and the second screenshot will be of a frame sent by the iPhone:

So, what's different here?

The first difference is that with Truphone, the wireless router is giving the Truphone call Video priority. If you look at the QoS Control field of the frames, you'll see that Best Effort is being used for Skype, while Video is being used for Truphone. The reason for the difference is a mystery to yours truly, but obviously Truphone is doing something with their end-to-end software that allows the wireless router that was used for this test to prioritize Truphone traffic ahead of ordinary traffic.

The bigger difference is in the traffic coming from the iPhone. The QoS Data frames looks the same, but check out what precedes the QoS Data frame when the iPhone transmits a Truphone frame. It's Request-to-Send/Clear-to-Send (RTS/CTS). The Truphone app is apparently lowering the iPhone's RTS Threshold for Truphone traffic only and using RTS/CTS to keep the channel clear. The RTS and CTS frames are pure overhead, but they are small (20 bytes and 14 bytes, respectively). And whatever overhead they add is compensated for in spades by the great effect those frames have in reducing the percentage of Retrys.

The same basic testing can be done with SIP applications (or any other media applications, for that matter). A quick look at the frames being sent and received by smartphones and other mobile devices can reveal a lot about which software is good and which software is Skype-like.

How Do I Know (If It Really Links Me)?

The darned computer (or phone, or tablet) won't connect. We've all been there, and we've all wondered what the heck the problem is. Here's a quick way (using an OS X 10.7 [Lion] Macbook Air with Wireshark) to start yourself on the road to figuring out why.


Last week I put out a call for blog topic suggestions and my man Keith Parsons made the fine suggestion of going through some tips for troubleshooting using Mac OS X. I think that is a good idea, so here is a little bit on troubleshooting connection problems on my (and the unemployed screenwriter industry's) favorite operating system.

If you understand 802.11 protocols, then troubleshooting connection problems can be done at an extremely low level. When your (or the people you support's) WiFi connection seems to be unavailable for no reason, you can look at the frames being sent to see if things are going the way they're supposed to.

When working with a Mac, I use Wi-Fi Diagnostics (an OS X Lion-only application) and Wireshark. Professional tools like WildPackets OmniPeek and Fluke AirMagnet WiFi Analyzer are unavailable for Mac OS X and, in fact, the same stuff that I'm doing here can be done even quicker with the expensive stuff on a Windows computer.

First step in checking out your connection is to start a capture. The aforementioned Keith Parsons of WLANPros.com covered that little OS X Lion tool quite well, so I'm going to skip that part and just remind you to make sure you're capturing all frames on the same channel as the AP that you're having trouble connecting to.

The next step is to connect your device that is having problems. This could be a problem. When a capture of all frames is done, the device disconnection. That means that if my Macbook Air is having problems connection (a too-common occurrence), then I can't run Wi-Fi Diagnostics from my Macbook Air. A perfect example is that to create this blog post I had to use my phone to connect in order to prepare for this blog post.

Once you've captured while attempting to connect, you want to look for the frames that are likely to be seen during a connection. I like looking for the Authentication frames. Association Request and Association Response frames could work, too. The problem with Association frames is that when stations move from AP to AP, Reassociation is used instead of Association. To keep things consistent, I like Authentication frames because those are used for both initial connections and roaming.

To view Authentication frames in Wireshark, just use the wlan.fc.type_subtype == 0x0b filter, like so:

See the two little frames below the highlighted frame in the picture above? Those are the frames that were exchanged between my phone and the wireless router while my phone was connecting.

To get a more full look at the connection, I take note of the frame numbers (in this case, 1861 and 1863) and manually scroll to the sequence of frames that were sent when the connection was made. A WPA Personal (PSK) connection will look something like this:

Frames 1865 and 1867 in my capture are Association frames. Those frames are of little use when troubleshooting connection problems, but the Association Request is useful for finding out what specs your station actually supports (security, QoS, 802.11n rates, etc.). 

Frames 1871, 1873, 1875 and 1877 are the WPA four-way handshake. The Mac OS X Wi-Fi Diagnostics tool essentially redacts these frames to prevent hackers from using Wi-Fi Diagnositcs as a preshared key (PSK) cracking tool, but you can tell that those are EAPoL Key frames by the 1-2-2-1 pattern of frame sizes. 

The key in troubleshooting WPA or WPA2 Personal is knowing that if the passphrase is mismatched between your client station and your wireless router, the four way handshake will fail after the second step. That means that with WPA Personal you'll see a 1-2-1-2 pattern of frame sizes in EAPoL Key frames as the client station keeps trying to complete the four-way handshake and the wireless router keeps rejecting it. 

A WPA/WPA2 Enterprise (802.1X/EAP) authentication can be found in the same manner, but troubleshooting that can get a little bit more complex because there are so many things that can go wrong with the EAP exchange. (And in a little bit of shameless self-promotion, I will point out that when I teach Global Knowledge WiFi classes I cover what to look for in an EAP exchange when trying to figure out which part of 802.1X/EAP is malfunctioning.)

One Card to Rule Them All

FINALLY!


If you do a lot of sniffing, there is a chance that you have a bag full of USB adapters whose contents look like this:

• Riverbed AirPcap NX
• Metageek WiSpy DBx
• D-Link DWA-160
• Cisco-Linksys WUSB600Nv1
• D-Link DWL-122
• D-Link DWL-G122
• Ubiquiti SR71-USB (w/ two HG2401RD-MMCX 2.4 GHz antennas)

I do, and it stinks. AirPcap is for Wireshark, WiSpy is for Chanalyzer, the DWA-160 and SR71-USB are for AirMagnet software, the DWL adapters are for Kismac and the Cisco-Linksys is for OmniPeek. It is a bit frustrating, especially if I need to switch between applications.

Well, today I am a happy(er) man. 

The screen in that shot is WildPackets OmniPeek, running like a champ. And do you see that little thing on the right, there?

That is the D-Link DWA-160, working with OmniPeek like a champ.

It is a little thing, I guess, but I am very happy to be able to use the DWA-160 adapter with WildPackets OmniPeek. This means that Fluke Networks' AirMagnet WiFi Analyzer & AirMagnet Survey, WildPackets OmniPeek and the Linux version of Wireshark all can do 802.11n monitor mode for 802.11n traffic (with up to two streams) with just one adapter. And it is cheap! I bought mine for $75 a couple of years ago.

A full fledged WiFi sniffing hardware kit will still require more than just a DWA-160, but it has definitely become a good place to start.

Tell Me Why's, Tell Me Sweet Little Why's

The darned computer (or phone, or tablet) won't connect. We've all been there, and we've all wondered what the heck the problem is. Here's a quick way (using an OS X 10.7 [Lion] Macbook Air with Wireshark) to start yourself on the road to figuring out why.


I'm on a connection kick as of late, so let's follow up the last post on this blog by going into a little more detail about WiFi connections.

If you understand 802.11 protocols, then things can be taken a little deeper. When your (or the people you support's) WiFi connection seems to be unavailable for no reason, you can look at the frames being sent to see if things are going the way they're supposed to.

Now, I was in a little bit of a lazy mood today, so I decided to use the OS X Lion application called Wi-Fi Diagnostics and Wireshark rather than a professional tool like WildPackets OmniPeek or Fluke AirMagnet WiFi Analyzer. This same stuff can be done (and, in fact, can be done even easier) with the expensive stuff as well.

First step in checking out your connection is to start a capture. Keith Parsons of WLANPros.com covered that little OS X Lion tool quite well, so I'm going to skip that part and just remind you to make sure you're capturing all frames on the same channel as the AP that you're having trouble connecting to.

The next step is to connect your device that is having problems. This could be a problem, because if the problem device is your MacBook Air that is being used to run Wi-Fi Diagnostics (as it seems mine often is), then capturing will prevent you from attempting to connect. For example, I had to use my phone to connect in order to prepare for this blog post.

Once you've captured while attempting to connect, you want to look for the frames that are likely to be seen during a connection. I like looking for the Authentication frames. Association Request and Association Response frames could work, too, but the problem is that when stations move from AP to AP, Reassociation is used instead of Association. To keep things consistent, I like Authentication frames because those are used for both initial connections and roaming.

To view Authentication frames in Wireshark, just use the "wlan.fc.type_subtype == 0x0b" filter, like so:

See the two little frames below the highlighted frame in the picture above? Those are the frames that were exchanged between my phone and the wireless router while my phone was connecting.

To get a more full look at the connection, I take note of the frame numbers (in this case, 1861 and 1863) and clear the filter. That gives me this:

At this point we can see the entire connection process. At the top of the frames I see the Authentication that I filtered on previously. After that, I see the interesting stuff. In this case it is an Association Request/Response pair (frames 1865 and 1867 in the picture above) and the WPA2 four-way handshake (frames 1871, 1873, 1875 and 1877). It is a little bit tough to tell that my four-way handshake was captured because those frames get chopped by Wi-Fi Diagnostics in order to prevent Apple's software from being used as a hacker tool. Trust me, though, those "Packet size limited during capture" frames are the EAPoL Key frames that comprise the four-way handshake.

My connection worked just fine, but if yours looks different than this, something may be wrong. If you are missing an Authentication Request/Response pair, that could mean that the AP and your client station aren't communicating correctly and you're in need of a reboot (or at least a WiFi radio off/on toggle). If you only get two steps of the WPA2 four-way handshake, that means that you typed the wrong WPA2 Personal passphrase. You can even tell why 802.1X/EAP fails if you're using that, but you'll have to sit one of my Global Knowledge CWNA training sessions if you want me to tell you what to look for. :)

What the #@*! is wrong with this WiFi? (and what can I do about it?)

We've all encountered bad WiFi networks in the past. Is there anything (besides cursing the admins) that can be done about it?


There is a fantastic phrase going around nowadays that is used to describe all manner of first-world problems: white whine. Complaints about the quality of guest WiFi certainly would fit into that unfortunate category, but I'm going to join the white whiners anyway (while throwing in a few helpful sniffing tips so that I feel better about myself).

UFC 137 happened on October 29, 2011 at the Mandalay Events center in fabulous Las Vegas, NV, and I was there covering the show for the Wrestling Observer. As is the case at almost all sporting events nowadays, WiFi-based Internet access was provided to the media in order to enable live blogging, tweeting and general reporting on the event. As is also the case at many sporting events nowadays, the WiFi stunk. In fact, it sucked. (And I don't use that term loosely. My mother would be angered at my potty mouth.)

The WiFi sucked not just because it was bad (that would qualify it only in the "stink" category), but because a Cisco-Linksys wireless AP (likely a wireless router) was being used for infrastructure. A Linksys. A #@*!ing Linksys. (Talk radio has taught me to repeat things at least three times in order to waste time allow important points to sink in and bamboozle educate your flunkies audience).

Sure, there were about a hundred users in a tight space and there were a handful of MiFi hotspots gumming up channel 11. But Aruba's infrastructure fixed a woebegone Vivato network at the MGM Grand Garden arena. Why is an arena owned by the same group using the same WiFi equipment you'd put in the guest house if your sketchy uncle came to crash for a few months?

But I digress... You all probably didn't come here to read about my white whine. You probably are here to read how I'd recommend checking to see if there is anything you can do when you run into crappy (see Mom, I'm getting better) WiFi.

Step 1: Know what you're up against


Avoid being lazy, folks. If you're reading this blog, you probably know WiFi. Even if you know WiFi, the temptation is just to try re-connecting or doing the ol' Repair (XP)/Diagnose (Vista/7) in order to release and renew your IP address. That does work every once in a while, but if you have the knowledge to get to the bottom of the problem, why not use it?

If you use Windows, fire up inSSIDer. If you use Mac OS X 10.7 (Lion), fire up KisMAC. Look at a list of APs in your area. A handful? That means you're got a shot. Dozens? You may be up you-know-what creek without a paddle. 

Step 2: Make that capture


Getting a list of APs tells you whether the WiFi is hopeless. But unless you're in a really bad area, the WiFi most likely is not hopeless, and you may be able to get connected. Before you try to adjust things, however, it helps to know what you're up against.

Wireshark is a great consumer-grade tool for checking to see if you're trying to connect to consumer-grade WiFi. There are versions for Linux, Mac OS X and Windows, and in the former two versions you can usually set your internal WiFi adapter to Monitor mode. If you're a Windows user, then you may be stuck (unless you feel like spending $698 USD on a USB adapter).

(At this point I should mention that I think differently when it comes to captures. If I am using Mac OS X 10.7 [Lion], then I will use Wi-Fi Diagnostics for my capture. I still look at the frames that were captured in Wireshark, but Wi-Fi Diagnostics makes the capturing process simpler.)

Once I have a capture from my channel, I look for anything unusual. In my specific case, I saw no data:

That ain't good. When a hundred journos are all trying to access the Internet and the AP's traffic shows nary an ordinary data frame, it means that you need a new AP (or, more immediately, an AP reset).

Of course, in most cases your guest WiFi won't be subject to the whims of a mediocre wireless router. So you might see lots of CRC errors (often meaning the AP is too far from your client station), lots of Retrys (often meaning that you could use RTS/CTS to help with a hidden node problem) or just a lot of traffic (often meaning that the channel is #@*!ed).

Step 3: Client stuff


Which brings us to our third and final step: tweaking your client software.

This is where Windows users may get their revenge. You poor folks can't do a capture if granny's blue hair depended on it, but you sure can change a setting. Head over to your device properties (Status -> Properties -> Configure -> Advanced is the path) and see what you can change. Band Preference is one that may help get you off the morass of 2.4 GHz and on to a 5 GHz channel. A lower RTS Threshold may solve the hidden node problem. Making your Roaming Tendency more conservative could get your client station to stop making frequent reassociations.

In the end, it may just be that none of this matters. If a Cisco-Linksys wireless router is used or if antenna panels are mounted a hundred feet (that's 33 meters for my international brothers and sisters) away, you may have no recourse but to ask for a new desk/room/ethernet cable. There are, however, some occasions where you can do something about bad WiFi.

And a one, and a four, and a eight, and a 'leven...

Channel choices can be a tricky thing, especially in the 2.4 GHz frequency band. I saw a network recently that had an unconventional channel design, but the network seemed to work pretty well.


Channel selection has long been a peculiar topic for 2.4 GHz WiFi networks. Per-channel frequency allocations in the band are 5 MHz wide (enough for a cordless phone or PowerPoint clicker, for example), but transmissions are much wider. The exact amount of bandwidth taken up by WiFi devices varies depending on the standards supported (802.11 b, g or n), the radio's transmission power and possibly other mysterious factors as well. (Just try running a spectrum analyzer around gear that supports transmit beamforming (TxBF) and you'll see what I mean.)

A seasoned rule of thumb has been to keep APs running on channels 1, 6 and 11 in an environment that supports ubiquitous coverage. The theory is that, at typical transmission/antenna configurations, WiFi devices will transmit over bandwidths that range up to about 22 MHz wide. Using the aforementioned channels gives one 25 MHz of space between channels (five channels at 5 MHz per channel), thereby limiting the likelihood of interference.

The counter to the 1-6-11 design is that a lot of channel space is being wasted. If WiFi devices operate O.K. with only a 20 MHz between APs (or even 18 or 15 MHz), then spacing the channels so far apart could be a waste.

Recently I worked in an office with a WiFi installation that was designed to avoid that type of waste. Channels 1, 4, 8 and 11 were used instead of 1, 6 and 11. I was unable to talk to the person who installed the wireless network, but I did get a chance to investigate a few things.

The first thing I looked at was the purely qualitative reaction of the people who use the network. Their reaction was one of unanimous approval. Now, that approval could have been due to the endpoint stations being used (just about all notebooks, iPads and smartphones) or due to the infrastructure vendor (Aruba, who I credit for turning the MGM Grand Garden Arena's WiFi from the unusable mess it once was into one of the best sports arena WiFi networks I've seen) or due to the fact that it was a building that was far enough away from neighboring buildings that outside interference was a non-issue. Still, +1 for 1/4/8/11.

I also did a little semi-scientific stress test. I checked my channel (8, for the record), used WildPackets OmniPeek to see what other channels had strong signals in the room (only 4, though 1 and 11 could have been strong enough for a low rate connection) and then started watching NBA highlights on YouTube. The video played just fine, but I did notice something disconcerting. The Retry percentage on channel 8 jumped immediately. The number fluctuated, of course, but generally hovered somewhere between 8 and 12 percent.

Now, 8-12% Retrys can be just fine, but for this environment I'd say that is too high. I was on a notebook (easy), sitting still (easy), associated to an AP mounted in a hallway (hard) below the ceiling (could be easy or hard) in an isolated building (easy) and running a streaming web application (a little hard). All told, the environment leaned a bit towards an easier installation than a hard one.

It is always tough to get a feel for whether something could be improved without chatting with the wireless network administrator, but based on my quick sniff of the channel, it appeared to me that I probably would have gotten better results if APs were placed on channels 1, 6 and 11. (Though if they were, who knows if the VAR could have managed to sell an AP every 45 feet or so.)

I am curious to hear feedback from readers, too. If you have a WiFi network that has either channel design (or something altogether different than 1/6/11 or 1/4/8/11), drop me a line or post a comment. If you have the time to do a quick check of your Retry percentages, all the better. My guess is that 1/6/11 is going to give better results because of the 1/4 and 8/11 overlap, but I have been wrong before (as anyone who attended the 2006 CWNA train-the-trainer class and heard me repeatedly pronounce that 802.11n would never be widely adopted can attest).

Time To Talk Chanalyzer

The Metageek spectrum analyzer package (WiSpy hardware with Chanalyzer software) has long been a favorite of thrifty sniffers. It has long deserved some praise from this blog, and with Chanalyzer 4 melting steel like a CM Punk promo, now is a good time to give it.

For many years spectum analysis was overlooked or even ignored by WiFi professionals, and for good reason. If you were managing a wireless network back in the days of 802.11b (or even the early days of 802.11g), there was a paucity of good, affordable spectrum analysis tools. You could buy a hardware analyzer (I first used something similar to this beast), but those things were usually expensive and designed as general purpose analyzers rather than WiFi-specific analyzers.

Spectrum analysis changed for the better in 2005, when Cognio released the Spectrum Expert analyzer. Their PC Card/software combo immediately became a favorite of WiFi folk and remains one today (though the product is now the Cisco Spectrum Expert after a 2007 acquisition). The problem with Spectrum Expert is that it is expensive ($2,874 at Sears) and it requires a computer with a PC card slot. Some smart folks saw those problems and formed Metageek, which introduced WiSpy to the market as a USB-based spectrum analyzer that is sold at a fraction of the price.

Metageek's signature spectrum analysis package is a WiSpy DBx USB adapter with Chanalyzer software (retail price: $599). It's a great product that does lack some of the short-cuttery that Spectrum Expert offers, but overall makes for a useful product.

The WiSpy/Chanalyzer combo has been reviewed elsewhere, so I'll pass on going through a full overview. Instead I want to just talk about some cool new stuff that's been added and some tips that have proven useful in my experience.

When Chanalyzer starts up, it looks like this:

Much of what can be seen is self-explanatory, I think. The top portion of the screen shows the current RF environment, the middle portion shows a temporal view of the amount of activity at each frequency and the bottom portion has a number of additional tabs that show information like nearby APs (which I have selected in the screenshot), recordings of possible interference sources or signatures of certain known RF-transmitting devices.

I generally use the WiSpy/Chanalyzer combo as sort of a last resort. I prefer to use WildPackets OmniPeek or AirMagnet WiFi Analyzer to sniff 802.11 frames if I'm trying to solve a performance problem, but if I can't figure out why there are high numbers of Retrys (indicating a network problem) or CRC Errors (indicating a problem at the location of my sniffer), I'll look to WiSpy/Chanalyzer to try to figure out why.

• Spectrogram (waterfall): If there is a temporary interference source, like medical imaging equipment or a poorly shielded microwave oven, the temporal view in the middle of the screen should show it.
• Max: Great for finding interference sources. You just have to make sure you turn off your notebook's WiFi radio before using the Max view, otherwise you're probably going to just be looking at your own RF transmissions.
• Density: Sort of the ordinary, every day way to look at interference. The Density view shows a more prominent pattern as the amount of RF transmissions at a given frequency are seen. (This one can be deceptive, especially with 802.11n. Those 802.11n Beacon frames are so large that sometimes you'll see what looks like a very dense outline coming from an AP that barely has any data going through it. That's why I like to look at a sniffer first.)

There is one more interesting view in WiSpy/Chanalyzer, and that is the Current view. The theory behind the Current view is that it shows a transmission pattern, thereby allowing a user to identify which type of device is causing the problem. Here's a screenshot of some kind of interference showing up at the office I'm owrking at today in my Current view:

Pretty cool, no? I can see the little spikes going across various frequencies and I can compare that transmission pattern to the Signatures that are packaged with the Chanalyzer installation. (In fact, I can even add signatures by clicking and dragging across a spread of frequencies.) From that spiked pattern, it sure looks like someone is using Bluetooth (or a microwave oven, or a lighting system, or something else...) in this office. The problem is, I can't tell for certain.

In a crowded office space like the building I'm in near La Brea & Santa Monica ($1.66 for splash-less Clorox at the Target down the block today; get it while you can) it's darned near impossible to distinguish between different interference sources. It is quite valuable to have a spectrum analyzer with built-in signatures for common interference sources so that I would receive a little warning if a known interferer in nearby. That is not to say that WiSpy/Chanalyzer should be avoided, because for the $600 price it simply is the best WiFi spectrum analyzer available. It's just that if you have the budget for a $3,000 analyzer, you're probably going to find that the device identification capabilities of Spectrum Expert (or possibly AirMagnet Spectrum XT, which I have yet to use) are worth the added price.

So there you have it. WiSpy/Chanalyzer is a great tool for finding interference sources (Max), identifying temporary transmitters (Spectrogram) and viewing general RF activity (Density). You can try to use it to identify specifc interfering device types in your vicinity as well (Current), but it may take some practice before that functionality is very useful.