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