sniffwifi

Just another WordPress.com site

Archive for November 2011

Tell Me Why’s, Tell Me Sweet Little Why’s

with 2 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.


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

Written by sniffwifi

November 22, 2011 at 5:12 am

Posted in Uncategorized

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

with 5 comments

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.

Written by sniffwifi

November 7, 2011 at 10:40 pm

Posted in Uncategorized