Just another site

Archive for January 2012

Using AirMagnet to Analyze Voice Over WiFi

with 2 comments

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.

Written by sniffwifi

January 11, 2012 at 11:13 pm

Posted in Uncategorized

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

with 3 comments

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 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.)

Written by sniffwifi

January 4, 2012 at 7:02 pm

Posted in Uncategorized