Just another site

Archive for January 2010

Sniffing WiFi and the iPad

with 2 comments

How could I not? With every technology writer (and some non-tech writers) from here to Marrakesh covering Apple’s latest miracle how could I not post something about how the iPad may affect those of us who sniff WiFi for a living? Well, here’s a few things about WiFi analysis and the iPad to consider given what we know about yesterday’s introduction and the current capabilities of the iPodTouch/iPhone.

All commentary about the iPad and WiFi sniffing should be prefaced by noting how ambivalent veterans of WiFi surveying and analysis must be about this thing. On the one hand, it’s exactly what we’ve always wanted. It’s thin, it’s light, it has a touch screen, its batter lasts forever and it has horsepower. That’s basically what we’ve always wanted out of previous generations of tablet computers that have always come up short in one or more of those areas. The problem is that it runs the iPhone OS instead of a real (read: multitasking) OS. Why, Apple? Why? Why must you taunt us by delivering the form factor we’ve prayed for and attaching it to an OS that is incapable of professional sniffing? (I’ll stop now before I start to sound too much like Salieri.)

Limitations or not, there are some interesting things about the iPad pertaining to WiFi sniffing. Here’s a short list:

Live Site Surveys

The Holy Grail of professional WiFi tablet use. Tablets are tailor made for live site survey applications like Fluke Networks’ AirMagnet Survey and Ekahau Site Survey. The combination of a relatively large screen, a flat form factor and a touch screen is what makes walk-n-click heat mapping surveys so well-suited for devices like the iPad. In some of my surveying work we’ve used a tablet, though not always. The tablet we had was quite heavy so it was a chore to carry it around for long periods of time. There were also times where you just wouldn’t need a tablet, such as when you just wanted to establish a normal WiFi association as part of final testing.

For live site surveys to be an option with the iPad, an application like the aforementioned ones from Ekahau and AirMagnet would have to be released for the iPhone OS. There is nothing close to those applications presently, but with the iPad presenting such an attractive form factor it’s possible that we’ll see some movement there. I realize that there aren’t too many iPhone apps that cost $2,000 or more (the typical range for a professional live site survey tool), but if the iPad gains some enterprise market share we could see something happen.

Protocol Analysis

At this point, we don’t even have professional-grade WiFi protocol analysis on OS X. AirMagnet WiFi Analyzer, WildPackets OmniPeek and even Wireshark with CACE Pilot and Airpcap (which will be reviewed soon, I promise) all are Windows-only. So what could possibly make me even dream that a good protocol analyzer for the iPad will show up? In a word, iWork. Apple is creating scaled-down versions of their productivity suite for the iPad, which indicated to me that they think that some people will want to use the iPad in places besides their living room couch. If some enterprising WiFi analyzer vendor finds that the transition to the iPad is relatively pain-free, it is possible that we might get something really useful for sniffing.

I do want to make clear that I don’t expect a high-quality WiFi protocol analyzer to be available for the iPad in the near future. Today the best we’ve got for the iPhone OS is probably WiFiFoFum, and that’s really just a basic stumbling tool. I’d sure like to be able to grab an iPad when trying to solve complex WiFi performance and connection problems, but the reality is that I’ll probably be stuck trudging around with my notebook.

Discovery Tools

Discovery tools, which are better known as stumblers, are applications that scan the air without putting the WiFi adapter into monitor mode (if you don’t know monitor mode, that’s another topic that’s on my list of things to cover for this blog). These tools are kind of nice if you want to confirm that your access point is in the air, but they really aren’t appropriate for most professional sniffing tasks. Still, they may fit the iPad quite well. At this point the iPad seems to be more of a fun device than a hardcore admin tool, so maybe stumblers fit.

As mentioned above, WiFiFoFum is probably the best stumbler running on the iPhone OS. I would wager, however, that the release of the iPad will prompt some developers of OS X-based sniffers to modify their products for use on the new device. My favorite OS X-based stumbler is probably iStumbler (though admittedly, I rarely use it).

Realistic Expectations

All of this sniffing stuff with the iPad is fun to speculate on, but what you probably want to know is what you can realistically expect. I expect that we’ll get a few more discovery tools and that at least one of them will equal the quality level of iStumbler. I expect that we won’t see a professional-grade protocol analyzer, but I do expect to see a version of Wireshark. I don’t expect to see a professional-grade site survey application either (as nice as that would be), because I am expecting a Broadcom chipset to be used for the WiFi interface and Broadcome does not allow their adapters to use monitor mode.

So there you have it. That’s what I expect from WiFi sniffing on the iPad and that’s what I’d like to see.

I’d also like to leave one more note that I’ve been lax in doing updates but I’m planning on getting back to my once a week schedule. My next planned update is that long-promised review of Wireshark with CACE Pilot and Airpcap, so check back in a week for that.

Written by sniffwifi

January 29, 2010 at 1:08 am

Posted in Uncategorized

Heeere’s MiFi… Sniffed!

leave a comment »

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.

Written by sniffwifi

January 8, 2010 at 5:44 am

Posted in Uncategorized