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