Heeere's MiFi... Sniffed!

A while back I wrote about how much I liked the Verizon MiFi 2200 mobile hotspot (made by Novatel). I also wrote that, due to the fact that my girlfriend liked it even more than I did, I would have to wait to sniff the MiFi to see how it uses WiFi. Well, I finally got a chance to sniff the MiFi, and it turned out to be a pretty ordinary access point with the exception of one little oddity that shows up in its Beacons.


In my initial writeup of the MiFi I covered basic operation, the connection experience and a few GUI configuration options. What I didn't cover was the sniffing.

When I did finally sit down to sniff the MiFi I got a little bit lazy. I could've booted my notebook into Windows XP and ran WildPackets OmniPeek like a good boy, but instead I decided to stay in Mac OS X 10.6 (Snow Leopard) and run KisMAC 0.3. For those that may have missed my earlier writeup on using KisMAC, the complete setup is as follows:

-OS: Mac OS X 10.6
-Sniffer: KisMAC 0.3
-Protocol Analyzer: Wireshark
-WiFi Adapter: D-Link DWL-G122 802.11b/g USB adapter

To begin I plugged in the DWL-G122 and started up KisMAC. I began by doing a scan on all channels with a pcap dump for all captured frames. Normally I prefer to begin my sniffing on a single channel so I don't miss anything but I'd forgotten what channel I'd configured the MiFi for, so I just figured I'd use find out what it is on KisMAC. It turned out I was using channel 11 (2.462 GHz center frequency) so I set KisMAC to capture only on that channel.

Once KisMAC was up and capturing I opened up Wireshark. I then pointed Wireshark to the pcap dump that was being created by KisMAC and I opened that up to make sure that frames were being correctly captured.

It was at this point that I noticed the lone oddity of the MiFi 2200. For some reason, the Beacon frames being transmitted by the MiFi contained the CF Parameter Set information element. Now, admittedly this is someone that almost nobody cares about, but to me it was interesting.

For those that are unfamiliar with what CF means in WiFi, it stands for "Contention-Free". You see, since WiFi channels get shared between all APs and stations that transmit in a given area, there must be some mechanism to ensure that only one device transmits at any given time. The way that WiFi devices handle this is by contending for access to the channel whenever they have a frame that needs to be transmitted (this is sometimes called "arbitration"). Contention-Free means that stations do not contend. If they have a frame to transmit, they wait until they are notified by the access point (technically called the "point coordinator" when CF is used) that it is their turn to transmit.

The theory behind CF is that the wireless channel will be more efficient if devices don't have to contend. The AP just acts as a central controlling device to optimize the efficiency of the channel. It's kind of like the well-proven theory that Cuba will crush the United States in economic growth because the government controls everything to make things more efficient. (OK, that was a cheap shot. And now I've probably got the Cuban minister of Technology reporting me as a counter-revolutionary.)

The CF Parameter Set being in the Beacons was interesting to me for two reasons. First of all, you never see it. Even high-end enterprise companies like Cisco don't allow for CF to be used, so the MiFi is one of the last places I'd have expected it. The other weird thing was that CF is still disabled. The Capability Information fixed field has a flag that indicates whether CF is being used by the AP and that flag was set to 0.

I'm guessing what happened here is that some developer who put together the MiFi software just took some code from an AP template and then forgot to get rid of the CF Parameter Set. Other than a few extra bytes of overhead ten times per second in every Beacon this really isn't a big deal, but it is interesting for folks who are curious about the more esoteric parts of WiFi.

After checking out the Beacons I finally turned on my notebook's WiFi radio and I waited for it to associate. Then I refreshed the Wireshark capture so that I'd have the frames that were transmitted during association. I then used the laborious Wireshark search function to seek out the association response frames so that I could complete my sniffing.

Once I located the frames sent during association (Beacons, Probe Requests, Probe Responses, Authentications, Association Request, Association Response and EAPoL Keys) I checked to see if there was anything worth noting. To be honest, there really wasn't. I guess it is notable that the MiFi defaults to WPA-PSK w/TKIP rather than WPA2-PSK w/AES-CCMP (especially since WPA2 has been required in all WiFi devices since 2006), but realistically the difference between the two is inconsequential for the type of use you're likely to see with a MiFi.

With the MiFi now having been sniffed, I do have some other things on the agenda coming up. I mentioned in a previous update that I would sniff the new WiFi-based sports betting network at the Venetian or Palazzo in Las Vegas, but unfortunately I wasn't able to get my notebook over there on this short trip. That means that I have two more things to look at: a full look at AirMagnet WiFi Analyzer using the Ubiquiti SR71-USB adapter and an overview of the CACE Airpcap NX adapter with Wireshark and Pilot. I'm going to try to stick to a weekly schedule this year so those should be finished over the next fortnight.

Comments

Popular posts from this blog

Five Facts About 6 GHz Wi-Fi

Chips, Glorious Wi-Fi 6E Chips!

Go To Sleep, Go To Sleep, Go To Sleep Little iPhone