Sniff Wi-Fi

A common conundrum for enterprise WLAN administrators is guest access. You often want or need to provide it, but you want to make sure the guest WiFi has a minimal effect on the internal network. One way that people try to limit guest access is by specifying low speeds, but that is a bad idea that usually causes the internal WiFi to be worse off than it should be. I was doing some work at a hotel in the Chicagoland area recently when I came upon another example of bad guest WiFi. Bad guest WiFi is quite common, but this one was avoidable. I've seen bad guest WiFi because of under-covered areas and because of over-covered areas. I've seen some guest WLANs with  over-saturation of stations and others with under-saturation of broadband. As with any WiFi design, there is a little bit of art in the science. You have to look at numbers like signal-to-noise ratio and users-per-channel but in the spaces where desired numbers collide, the owner of the WLAN has to make good choices

In life, the opposite side of intellectualism is sometimes a good place to be. Analyzing a WLAN is not one of those times. When someone tells you that a boring movie is great because it was shot well or that a nil-nil draw in football (world, not American) was thrilling because of all the close chances, the best idea is often to sit back, draw a creamy bowl of vanilla ice cream and tell that nerd that you don't need a P.H.D. to know what makes you happy. This type of anti-intellectualism is almost certainly born as a rebellion against deep analysis (perhaps making the rest of this blog post intrinsically ironic). Sometimes, though, deep analysis is needed to prevent festering problems from bubbling over at bad times. It takes no great insight to point out that there is a penalty to eschewing analysis. The man who  avoids Oscar-bait movies may miss a work of great emotional power. Disregarding scoreless football matches would have caused fans to miss the most thrilling match of th

I love free stuff. I love it even more when it works. And while I am a natural skeptic of the usefulness of free software (thus contradicting a timeless programmer's joke ), the ability to run KisMAC-ng with an AirPort Extreme interface in Monitor mode is quite nice. Not as nice as it could be if a few little tweaks were made to the software, but for a free product it remains the best WiFi sniffer for Mac OS X. Way back in January of this year (seems further back than that, which is interesting since years are supposed to feel faster as you get older, right?) I wrote about using a combination of KisMAC, Wireshark and a DWL-122 802.11b/g USB adapter to do WiFi sniffing when running Mac OS X . Six months later I wrote about sniffing with a Mac again , this time focusing on using a virtual machine. The basic gist of those updates was that running Windows on your Mac is the best way to sniff, but if you must run OS X then you can at least capture 802.11 b/g frames if you have a DWL

The Internet wireless community was set aflutter last week when Eric Butler , a freelance developer from Seattle, introduced Firesheep , a Firefox extension that is advertised as a way to perform sidejacking attacks over unencrypted wireless networks. The software is super slick and all, but what interests me is the way it handles frame capture.  For those who may have missed it, Firesheep is a Firefox extension that allows users to view web sessions that are active on the channel. It works via a wired or wireless channel, but the prospect for wireless viewing received much more press because, A) nobody uses hubs anymore, and B) wireless vulnerabilities always get much more press. The tool is slick and, as far as I can tell, a better name for it would be, "Screw Facebook". From the unscientific tests I've done, Firesheep users are able to gain limited access to other people's accounts on a number of popular sites, but the real eye opener is the ability to view an

A Twitter follower asked a while back if I could use the blog to give some tips on using WildPackets OmniPeek. Seeing as how I'm always in need of interesting stuff to write about, I figured I'd give it a shot. Here, then, is a quick look at how to analyze station performance in OmniPeek. There are a lot of metrics that can be used to analyze a station's performance. You might look at whether the station is using high or low rates. You could look at how much channel bandwidth the station is consuming. You should look at how many retransmitted frames are being sent and received by the station. All of these different ways to analyze a station's performance have one thing in common: you have to configure a filter on your sniffer that captures only your station's traffic. The first step of creating such a filter in OmniPeek is to find out what channel your station is on. Start out by finding out your station's MAC address (for my laptop, it's 00:1f:5b:cc:3b

The CWNP Program gave their CWSP (certified wireless security professional) exam a refresh earlier this year, and I finally got a chance to take the test a while back. I found it to be a good exam that requires deep knowledge of the 802.11i amendment. The CWSP certification is one of three professional level certifications from the CWNP Program. CWNP's professional level certifications require the candidate to pass the CWNA (certified wireless network administrator) exam along with a professional level exam. The three professional level exams are CWSP, CWAP (analysis) 1 and CWDP (design). Currently only the CWSP exam is available, with the other two exams scheduled to be available later this year or early next year. This is the fourth version of the CWSP exam , and in my opinion it is in line with versions two and three of the exam. If I had to give exact ratings, it would be the best of the four versions by a narrow margin over version two.  It is almost unfair to com

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 have to move the students (and several crates worth of lab equipment) to a different bu

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

It's no secret that 802.11n is a peculiar wireless technology. You've got multiple transmissions on a channel, a half dozen technologies and a few dozen data rates (at least) for the average AP to choose from. It can all make for some difficult troubleshooting, especially when looking at data rates. Here's a technique that I use to figure out which 802.11n technologies are missing (or not missing) when I'm trying to figure out why I'm getting a certain data rate. Now, the first question one might ask when analyzing data rates is, what's the point? If I'm using my laptop at my desk and I have a 117 Mbps data rate, I'm not going to move to the break room just to get a bump to 130 Mbps. That is certainly true. But from a networker's perspective, you'd like to give your users the best experience possible, and there may be reasonable changes that would lead to better performance. There are three questions that you can answer by looking at your data