Sniff Wi-Fi

I dislike Google. It may be unfashionable, it may betray my corporatism and it may be ironic (especially considering that I'm taking advantage of Google's wonderful Blogspot tools at the very moment), but it's true. I dislike their faux-openness and I dislike their bullying of old, unfashionable companies and I dislike their disingenuous approach to lobbying. That's why it's so hard for me to write this: Google is a victim. People are trashing them over their capturing of data while sniffing WiFi networks and they deserve better.   Attacking Google has become what praising Google was back in 2007: the fashionable thing to do. People dislike their position on wireless Net Neutrality, their search rankings and, yes, their WiFi sniffing habits. For me, it's been quite the reversal. I began disliking Google because of their support for Net Neutrality and the so-called "open" requirements for the 2007 wireless spectrum auctions. That put me at odds with...

One of my first posts for this blog was a discussion of how Mac OS X users might perform WiFi sniffing. Enterprise-class sniffers only run on Windows, so my earlier post is about using a combination of KisMAC and Wireshark. This brief post is about using WildPackets OmniPeek. Keith Parsons, the WiFi expert who runs WLANpros.com , informed me after my post that I should try running professional grade analyzers using a virtual machine like Parallels or VMWare Fusion. Well, here we are a mere 6 months later and I've finally taken the time to do it. And it works. And it is superb. My basic setup includes the following: MacBook Pro running Mac OS X 10.6.4 (Snow Leopard) with a 2.4 GHz processor and 4 GB of RAM Windows XP Service Pack 3 Parallels Desktop 5 WildPackets OmniPeek Enterprise 6 Linksys WUSB600N 802.11n dual-band USB adapter OmniPeek starts up and runs fine under this setup, though I did wonder if running in a virtual machine would compromise performance. I have ...

The Wi-Fi world was set aflutter today by a wireless IDS/IPS vendor sending out a press release advertising a flaw in WPA2 security that will be detailed during a pair of security conferences at the end of the month. (They're also holding a Webinar early next month that will detail the same flaw.) Much of the commentary on this WPA2 vulnerability has been focused on discrediting its real-world impact, but I am going to abstain from my initial temptation to join those critics. Instead, I'll take this time to discredit a supposed flaw in TKIP that was touted a couple of years ago, but for some reason never analyzed thoroughly. The TKIP flaw has been nicknamed Beck/Tews after the researchers that discovered it. Their whitepaper and an excellent analysis of the technical theory behind the flaw by Glenn Fleishman of the superb WiFiNetNews.com blog are both available online. A quick summary of the flaw goes something like this: TKIP relies on a sequence counter called the T...

Metageek has announced that WiSpy USB spectrum analyzers can now be used with Channelyzer Pro. This could make things interesting... Readers of this blog may know me as an anti-open source kind of guy, but I try to be fair. I've talked about popular products like AirPcap NX, Wireshark, WiSpy and Channelyzer and I've always tried to give a fair appraisal of their usefulness for enterprise-class wireless environments. The problem is that I usually just don't find them to be that useful. Of these products the one that has always been closest to enterprise-class is WiSpy DBx. It competes with the hardware for Fluke Networks' AirMagnet Spectrum XT and the Cisco Spectrum Expert at a much lower cost ($600), and in many ways it measures up. It can be used in the both the 2.4 GHz and 5 GHz frequency bands, it uses the USB form factor (which beats the PC card form factor for Cisco Spectrum Expert) and it comes with free software in Channelyzer. The big problem was that using...

Steve Jobs introduced the iPhone 4 yesterday. You may have heard about this snazzy little device and you may have also heard about the problems Mr. Jobs had in demonstrating it. Mr. Jobs blamed the problem on WiFi, and as best I can tell he was right. I whipped up a quick video to explain what likely happened. It's my first video blog post, so be gentle. Thanks to Rough & Tumble Films in Los Angeles for providing the space and Nick Robinson (@nickrob on Twitter) for helping me out with the shoot.

Last week I ran into an age-old problem: my WiFi network being blamed for the poor performance of a neighbor's network. I was pretty sure that the problem wasn't my fault, but how would I prove that? Here are some ways that you can use a WiFi sniffer to diagnose whether your new WLAN is disrupting what's already in place. Let's start with a little background on my situation. I was teaching a class*  at a training location that provides Guest WiFi (unencrypted; no web-based authentication) and optional Dedicated Classroom WiFi (TKIP-encrypted; WPA-PSK authentication). The Guest WiFi was being used by students in my class, but the Dedicated Classroom WiFi was not. Both of those networks were working poorly from the time we arrived. The Guest WiFi being down was just annoying, but the Dedicated Classroom WiFi was a red-level problem. A problem significant enough that we might...

Google recently got in some trouble for the way their wardrivers collect WiFi data for use with location services (Google Maps, for the most part). It looks like this faux pas was just a problem of improper filtering in whatever WiFi sniffer Google was using. If you want to do a little wardriving but you also want to insulate yourself from legal problems if anyone ever gets ahold of your captured frames, make sure you configure your filters properly. Let's start by talking about the differences in wardriving software. Most wardrivers use active scanning software like NetStumbler, KisMAC or Kismet. (I know, KisMAC and Kismet can also do passive scanning, but they are commonly used in active mode.) Active scanners are software applications that keep your WiFi adapter in managed mode, meaning it operates like a normal station. The only difference when you run an active scanner is that discovery information (that being information received from Beacon and Probe Response frames) is...