Default

Sniff WiFi
Pgina 1 de 49
Sniff WiFi
Est viendo una fuente cuyo contenido se actualiza con frecuencia. Las fuentes se agregan a la lista de fuentes comunes cada vez que se suscribe a ellas. La informacin actualizada en la fuente se descarga automticamente en el equipo y se podr consultar en Internet Explorer y en otros programas. Obtener ms informacin acerca de fuentes. Suscribirse a esta fuente
What's New In the WiFi for iPhone 5

mircoles, 19 de septiembre de 2012, 22:20:00 | noreply@blogger.com (Ben Miller)
Yay, a new iPhone! So sayeth me, my relatives (one of whom will receive my old iPhone), California (who will receive 8.75% in sales tax on the FULL UNLOCKED PRICE of the phone because California has a ludicrous sales tax law that taxes the pre-discount price of mobile phones) and anyone else who has been waiting for the iPhone to finally support 5 GHz WiFi. But wait, there's more. The iPad has long supported 5 GHz 802.11n WiFi, but the iPhone 5 does the iPad one better. How? Read on, amigos. Though Apple's most popular iOS device, the iPhone, has eschewed 5 GHz WiFi until iPhone 5, iOS-based access to 5 GHz channels (numbered 36 through 165) has been available in every iPad model. The iPad has always been 802.11n, which is good. But the WiFi adapter in the iPad has always supported the bare minimum 802.11n, which is bad. (Specifically, 65 Mbps Data Rate bad.) This meant that an iPad is going to take about three times as much channel time as a MacBook Pro (which has a top data rate of 450 Mbps) to send or receive a single full sized packet. To achieve a data rate of 65 Mbps, the iPad supports the following technologies:
z z z z z
20 MHz channel bandwidth 64-QAM modulation 52 data carrying OFDM subchannels 5/6 convolutional coding 800 nanosecond guard interval (same as 802.11a/g)
In supporting the 450 Mbps data rate, the MacBook Pro supports the following additional 802.11n technologies.
z z z
40 MHz channel bandwidth (typically only in the 5 GHz band) 400 nanosecond "short" guard interval 3 stream spatial multiplexing
Along comes iPhone 5. It is better than the iPad, but still a ways below the MacBook Pro. The iPhone 5 uses the 40 MHz channel bandwidth and the 400 nanosecond guard interval, but not 3 stream multiplexing. That means a top data rate of 150 Mbps.
http://www.sniffwifi.com//feeds/posts/default
08/11/2012
Sniff WiFi
Pgina 2 de 49
Why would the iPhone 5 not use 3 stream spatial multiplexing? Because spatial multiplexing of any kind involves using multiple input/multiple output (MIMO) technology. MIMO drains battery life (because it involves multiple transceivers being used instead of one), it can lead to heat issues (same reason) and it is hard to do on a small, slick-looking device (because each antenna that is attached to a transceiver has to be at least a half wavelength from each other antenna). The bump in maximum data rate to 150 Mbps means that an iPhone 5 at top speed will be sucking up a little bit less than twice the channel time that a MacBook Pro would be if both are sending or receiving full sized packets. Still less than ideal, but a whole heck of a lot better than what we used to have.
Testing Mobility with OmniPeek: Isolating the Station's Traffic

jueves, 09 de agosto de 2012, 2:51:32 | noreply@blogger.com (Ben Miller)
WildPackets OmniPeek has long been my favorite WiFi sniffing software, but lately this blog has been short on posts about it. That needs to change. So today I start a multi-part series (number of parts to be determined) on how I use OmniPeek to help me plan for and troubleshoot mobile devices. Mobility (defined here as seamless roaming between WiFi access points [APs]) is a longstanding enterprise WLAN issue that has kind of taken a back seat to supporting personal devices (a.k.a. BYOD). For many enterprises, mobility remains important. Car dealerships with push-to-talk handsets, warehouses with barcode/RFID scanners and retail locations with point-of-sale terminals are all examples of locations that require user devices to move around a large area without dropping connections, losing speed or experiencing choppy service. The solution to supporting mobility is to make sure that APs have adequate overlapping coverage without interfering. It sounds simple, and it is. But it's not easy. We're trying to serve two opposing masters. On one hand we want APs close together to provide adequate coverage overlap. On the other hand we want APs further apart to avoid interference. Before getting into a detailed discussion about sniffing AP coverage, we first have to consider client station behavior. Why? Because stations control connections. The WLAN infrastructure does not tell a station when and where to connect. The station chooses. (This makes a ton of sense when you think about it, but it ticks off network admins to no end). Since the station chooses, our first task is going to be to isolate the relevant station in OmniPeek. I'm going to use my iPad as a guinea pig because those things are known to be bad with mobility. I start by inserting my OmniPeek capture adapter and booting my MacBook Air (late 2010/non-AirPlay streaming edition) into Windows 7. In this case I chose to use a Cisco-Linksys WUSB600N 802.11a/b/g/n 2 x2:2 USB adapter, but I usually like to use the D-Link DWA-160 USB (same 802.11n specs) adapter. Once the adapter is inserted, I launch WildPackets OmniPeek (in my case version 6.6.0) and begin a monitor mode capture that scans across all 2.4 GHz and 5 GHz channels. I kind of skipped over how to get monitor mode and the channel scanning thing going, but I think the OmniPeek user guide lays those tasks out clearly. With an capture window open, I click the green Start Capture button to begin capturing. I then click the
08/11/2012
Sniff WiFi
Pgina 3 de 49
WLAN link on the left menu bar in order to see which channel my iPad is on.
The picture turned out fuzzier than I'd hoped, but it does show that there are two APs using my SSID of "2788", one on channel 1 and the other on channel 11. Now, another thing that somewhat fuzzy screenshot shows is that there is a device named "iPad" associated to the AP that is operating on channel 1. WildPackets OmniPeek does not have the ability to detect that my client station is an iPad. I had to give my iPad a name in OmniPeek. If you have yet to give your device a name in OmniPeek, you can do so by right-clicking the station (which will be identified by OUI/MAC address by default) and clicking Insert into name table. Just make sure you choose a name that you'll remember and be able to quickly reference. Once I know what channel my iPad is using, I need to set OmniPeek to capture on only that channel. To make OmniPeek capture on a specific channel, I just right-click the little area at the bottom of the screen where it shows what channel I'm currently capturing on. After the right-click a menu will pop up that will allow me to choose which single channel I'd like to capture on. Just make sure you choose a "bg" channel instead of an "n40" channel if the AP your station is association to is using a 20 MHz wide channel. After my capture is going on the correct channel, I then need to create a pre-capture filter so that I can capture only traffic that is relevant to my iPad's mobility. (This, by the way, is a major area where the CWNP Program and I differ on the topic of WiFi sniffing. The CWNP Wireless LAN Analysis course [which is designed to prepare students for the CWAP certification] has material indicating that pre-capture filters should rarely be used. This is poppycock of the highest order. I use pre-capture filters all the time and they are absolutely essential to performing some of the most useful tasks a WiFi sniffer is capable of.) To create a filter for my iPad's mobility traffic, I just right-click on iPad(or whatever name you gave your client station) and select Make filter. From there, you will have the option to choose whether you want to capture traffic going to your iPad, traffic coming from your iPad, or traffic in both directions. You don't want all of the traffic because that is not specific enough. So... Pop quiz: When creating a filter for use in planning for iPad mobility, do you want a capture filter that captures the traffic going to your iPad or from your iPad? What do you think?
08/11/2012
Sniff WiFi
Pgina 4 de 49
To or from the iPad? To? Or from? Hmm... Enough stalling. You want a filter capturing what's going TO your iPad. Like so:
Notice how there's the little backwards arrow in the middle with "Address 2 to 1" underneath? That's telling me that I'm capturing traffic that had a destination MAC address that matches my iPad's. If you're wondering why you want a filter that captures traffic going to your iPad, you'll have to check out the next part of this series. Next time we're going to activate our newly created traffic-to-iPad filter and really test the iPad's mobility behavior.
Mighty iPhone Power Ranges

jueves, 28 de junio de 2012, 3:07:29 | noreply@blogger.com (Ben Miller)
Oh, those darned iPhones. Can't live with 'em, can't keep your job without 'em.
The vagaries of iPhones and other station devices are the most difficult part of managing a WiFi network, but there are some things that can be done on the infrastructure to try to make your stations work better. One of those things is lowering your AP transmit power to a level that more closely matches your client station's transmit power.
08/11/2012
Sniff WiFi
Pgina 5 de 49
My main man G.T. Hill (of Ruckus Wireless) recently wrote a blog post discussing why this post is bullshit. Now I'm going to tell you why his blog post is bullshit. (sorry, G.T.)
G.T.'s primary point is that is is borderline mentally handicapped (politically correct term) to turn your AP's power down. His theory is that even if your client stations transmit at low power levels, having a high AP power level at least allows the from-AP data rates to stay as high as possible. (G.T. goes on to add that most traffic is downstream, thus making it all the more important to maintain high from-AP data rates.I have found this to beincorrect, so double-sorry, G.T.) I wanted to check out an example using my iPhone (which, from what I gather, transmits at 10 dBm) connecting to an AP in a small office (which probably transmits at 17 dBm or 18 dBm). I ran a Skype test call so that I would make sure that both the AP and the iPhone would transmit plenty of frames. Just as G.T. hypothesized, the higher transmit power of the AP allows the AP to transmit at a high rate. The small office AP was acting as an 802.11g AP (even though it's probably an 802.11n AP configured to use TKIP encryption) and, sure enough, the small office AP used the highest possible rate (54 Mbps) for just about every transmitted frame:
Also as G.T. hypothesized, the rate for frames transmitted by the small office AP would likely have been lower if the AP's power level were reduced to match the iPhone's power level. We can deduce that from the fact that the iPhone was routinely transmitting frames at a lower rate (48 Mbps) than the AP:
As expected, G.T. is correct about the rates. If your primary goal is to have the highest possible rate for all
08/11/2012
Sniff WiFi
Pgina 6 de 49
frame transmissions on your WiFi network, chances are that setting your AP and station transmit power levels to the highest possible value will help you achieve that goal. The problem with this whole discussion about rates is that having high rates really should not be your primary goal. High rates are attractive because it's fun to see a big number when you mouse over your system tray (or, for us Mac OS X users, when he hold the Alt key and click on the WiFi icon in the top menu bar), but for most enterprise WLANs high rates fall somewhere around fifth on the list of things to look for when evaluating whether the WLAN sucks or not. My criteria for not sucking: 1. 2. 3. 4. 5. Drops/re-authentications are rare (meaning that every captive portal sucks) Roaming works for mobile devices Discovery trafficis minimal Retrys are low (indicating that whenever the wireless gets busy, it'll still probably work) Rates are high
(Please notice that throughput/goodput, packet sizes and single station usage are absent from this list. One could write an entire blog post about how much time is wasted analyzing those numbers.) High percentages of Retrys are more damaging than low rates (in most cases) because Retrys waste channel time. There is a finite amount of time available for data to get across each channel. When a Retry happens, the time for the failed frame was wasted because all stations and APs must stay quiet during each frame transmission. Low rates for data frames also waste time, but for most enterprises the budget is there to install plenty of APs so that a decent signal can be had anywhere. Now take a look at the Retry numbers for the communication between my 10 dBm iPhone and the 17/18 dBm office AP (while also taking a look at how much extra time it takes to do menial tasks when you go cheap and use Wireshark instead of WildPackets OmniPeek or Fluke AirMagnet WiFi Analyzer): Frames sent by the AP to the iPhone: 1650
08/11/2012
Sniff WiFi
Pgina 7 de 49
Retry frames sent by the AP to the iPhone: 155 (9.4%)
Frames sent by the iPhone to the AP: 1973
Retry frames sent by the iPhone to the AP: 329 (16.7%)
08/11/2012
Sniff WiFi
Pgina 8 de 49
Both 9.4% and 16.7% Retrys are bad numbers (though this was for a small office, where bad numbers are expected because of neighboring WiFi networks), but 16.7% is a helluva lot worse. About 1.77 times worse. And why is it worse? Most likely because the AP transmit power is set too high. The iPhone has no idea what the AP transmit power level is, so when the iPhone receives a frame at a good signal strength, the iPhone assumes that a high rate can be used when the iPhone transmits. The iPhone doesn't realize that its transmitted frames go out about 7 or 8 dB lower than the AP's frames. The end result is the iPhone using rates that are too high (and if I were able to show you the entire capture of the iPhone's transmitted frames, you would see many failed attempts at 54 Mbps), causing lots of Retrys on the channel and thus, SLOWING THE ENTIRE CHANNEL DOWN. (I cannot make the point strongly enough that RETRYS SLOW THE ENTIRE CHANNEL DOWN. A massive Retry percentage like 16.7% makes my iPhone slower, every other device on my iPhone's network slower, every other device on any other network the AP is offering slower and every other device on any network that any AP on my channel slower. Retrys are a bad, people. And the only way to get an accurate gauge of Retrys is by sniffing WiFi. It's why I cared enough about sniffing to start a free, advertising-bereft blog.) The bottom line here is that even though my friend G.T. has phenomenal taste in fast food, a lovely wife/kids/family and a solid history of only spending money on things that will help his career or increase in value (sorry, G.T., I couldn't resist), I believe he is wrong here. I have found that designing a WiFi network with AP power levels lower to match station power levels works best, and my experience gathering statistics from real-world WiFi sniffing supports that.
Here's One Eye P.A. That Won't Give You Bowel Cancer
mircoles, 30 de mayo de 2012, 0:01:15 | noreply@blogger.com (Ben Miller)
You say you like WiFi Sniffing? And having fun? And not succumbing to a painful demise due to liver sclerosis? Well, then there's only one product pronounced eye-pee-ay for you: Metageek's new visual protocol analyzer, Eye P.A.
08/11/2012
Sniff WiFi
Pgina 9 de 49
Amid all of our divisions over race, gender, religion and whether the Champions Bowl is going to be better than the Rose Bowl, we can agree one one thing: products named after alcohol are great. So you can imagine my excitement when I was made aware that Metageek -- hero to Windows users, villain to Mac usersand tease to iPad users -- had introduced a WiFi sniffer. Metageek is known 'round these parts ("round these parts" being, "in my opinion" ) as being a proprietor of low cost, attractive WLAN analysis tools. InSSIDer is the best active site surveying utility I've seen for Windows. The WiSpy/Chanalyzer combination is my spectrum analyzer of choice. (And I'll just choose to ignore the iPad tease that has been going to dang near a year now.) Eye P.A. is Metageek's entry into protocol analysis, and if nothing else it is quite unique. Eye P.A. is different from most sniffers in that it doesn't sniff. Eye P.A. relies on saved capture files procured by other sniffers. Currently, the capture must be in the .pcap format and the capture must include an 802.11 Radiotap header. If you are a Linux or Mac user, a monitor mode capture from Wireshark will get you what you need. If you are a Windows user, you're going to need to spend at least seven hundred bucks on a Riverbed AirPcap NX USB adapter (or less than $700 on a cheaper AirPcap USB adapter, but then you'll miss 802.11n traffic). Once a capture in the .pcap format (including 802.11 Radiotap) header is made, Eye P.A. will be able to open the file. Here is a screenshot showing what Eye P.A. looked like when I opened a capture that was taken from a hotel I was staying at a short while back:
The information is a little bit tricky to understand at first. There are three sets of circles; one for bytes, one for packets (actually, frames) and one for time. Each circle is actually a series of circles organized as follows:
z z z z
Inner circle: BSSIDs ( wireless MAC addresses of APs) Second circle: stations Third circle: frame types (management, control or data) Outer circle: frame subtypes
08/11/2012
Sniff WiFi
Pgina 10 de 49
Each full circle represents 100% of what is in the capture. So, for example, in the screenshot above if my AP transmitted or received half of the bytes in my .pcap capture file, then my AP's BSSID would take up half of the innermost circle. The idea of this design is to give WiFi folks a general idea of what's taking up channel space. That way if, for example, you are offering guest WiFi and you're wondering if it is bogging down your employee WiFi, you can do a quick .pcap capture, open the capture in Eye P.A. and quickly see the size of the partial circle that is labeled with the guest WiFi's BSSID. Trent Cutler from Metageek (who deserves many thanks for giving me information on how Eye P.A.'s time calculations are done), also pointed out that Eye P.A. can be as good at quickly finding out whether there is a hidden node present as normal IPA is at giving you brain damage. On a channel without hidden nodes, the number of acknowledgment frames and data frames captured should be approximately equal, as seen in the Packets circles of this Eye P.A. view of my Macbook Air's traffic:
The bright orange area of the outer circle in the Packets view above are the acknowledgment frames for my laptop. The purple area of the outer circle in the Packets view are the data frames. Those two parts of the circle are about equal in size, indicating that my laptop is not a hidden node from the location where I captured. (That makes perfect sense, of course. I captured traffic using an AirPcap NX adapter that was attached to my laptop, so there is no way that my laptop's internal WiFI adapter would have been far enough away to be a hidden node.) Eye P.A. does have usefulness in identifying hidden nodes and getting a general idea of what's taking up your channel space, but the big question is whether it is worth the $499 retail price. I think the software would be worth it for a lot of people who have to manage WiFi networks, but who feel overwhelmed by the amount of statistical information given by the average protocol analyzer. I especially like the Time circles, which use a method of calculation that factors in the amount of time taken up by the PLCP header. I could see someone who has a problem area just taking a Macbook to the problem area, doing a .pcap capture using Wireshark or Wi-Fi Diagnostics and then doing a few quick clicks or mouseovers to get a general idea of what could be the problem (over-deployment of APs, low rates to/from a station, hidden nodes, etc.). Then once Eye P.A. points someone in the right direction, a real-time WiFi sniffer like AirMagnet WiFi Analyzer or WildPackets OmniPeek could be used to pinpoint the problem and test
08/11/2012
Sniff WiFi
Pgina 11 de 49
whether an attempted solution works. The bottom line is that Eye P.A. is a fine compliment to a WLAN professional's suite of analysis software. I can definitely say that consistent use of Eye P.A. strikes me as a very good way to gather basic information about your wireless channel usage in the same way that a consistent consumption of a normal IPA strikes me as a very good way to get throat cancer.
Worthless Capture
sbado, 21 de abril de 2012, 22:41:10 | noreply@blogger.com (Ben Miller)
You're never gonna sniff again Faulty packets got no meaning Though it's easy to pretend I know I'm not a fool
Oh, how I want to sing those lyrics. To whom, you ask? Why, to Cisco Clean Air access points. Also, AirMagnet Enterprise sensors, Aruba Air Monitors and anything else that offers me a careless whisper worthless capture.
Unlike WHAM!, distributed WLAN analysis is in. It seems that nowadays I can't swing a dead cat without hitting someone who is proud as punch of their system of distributed sensors that does something (spectrum analysis, intrusion detection, frame capture) cool. Distributed sniffing (meaning frame capture) or spectrum analysis does have its uses. If you need to find a rogue AP, identify a denial of service attack or get a general overview of your RF environment, systems like Cisco CleanAir, Fluke AirMagnet Enterprise and Aruba AirWave RAPIDS can all be useful. The problem is that these products are often used for more than that. Any distributed sniffing product relies on the fundamental conceit that the capture is accurate. If a distributed capture AP/sensor sees a station transmitting 70% of its frames at a 52 Mbps rate, then the sniffing software assumed that, indeed, 70% of that station's frames went through the air at 52 Mbps. The problem is that a distributed sensor is not at the same location as the station. Once a capture is done away from the location of a station, the capture becomes nearly worthless. Too many things about the RF environment will be different for the information to have any value. The differences between captures near a station and far away from a station can be seen below. First, a capture done with Fluke AirMagnet WiFi Analyzer filtered only my AP's traffic. The capture device is placed right near my AP as a movie was streaming from an iPad that was about 35 feet away (with some obstructions in between):
08/11/2012
Sniff WiFi
Pgina 12 de 49
The important thing to look at is the CRC Error percentage. When the CRC error percentage is low, that means that the capture is useful. Here the CRC error percentage is 0%, so this is a good capture. And that is usually the case when AP/sensors capture frames being transmitted by other APs. Both devices are typically mounted in the same general space as each other, so very few frames are missed. The problem shows up when I look at the same AirMagnet capture filtered on my iPad. The capture device is in the same place it was before (near the AP), but the iPad is about 35 feet away (with several obstructions in between the AP and iPad):
It's tough to read, but that screenshot shows that a whopping 28% of captured frames being transmitted by my iPad were read as CRC Errors. That is a worthless capture. It may be showing me 30% Retrys (a bad
08/11/2012
Sniff WiFi
Pgina 13 de 49
number for just about any WiFi network), but when over one quarter of my frames were corrupted on capture there is no way of knowing it that is the true percentage of collisions. The real crime in all of this is that AP/sensor-based captures of frames and RF energy are commonly used by controllers and wireless management software to determine important parameters like AP channel and AP transmit power. And wireless intrusion detection systems use these captures to warn you about alarms. Sometimes this information is good enough to help, but often times the result is poor channel selection, AP-on-AP interference and false IDS alarms. I realize that it is silly to recommend that people do station-located frame captures for every little WiFi problem, but I do think that many organizations ignore the huge differences in quality between AP/sensor captures and portable captures. My advice is to use distributed AP/sensor-based capture products for rogue AP response, DoS detection and location tracking, and use portable sniffing software to identify problems with the more serious wireless problems like channel selection, AP interference, mobility and collisions.
How to set up OmniPeek to analyze Phones on a WLAN

domingo, 15 de abril de 2012, 6:03:19 | noreply@blogger.com (Ben Miller)
Blogger's stats are telling me that yesterday was the most-trafficked day in the history of this blog, and as much as I want to credit Titanic's 100 year anniversary, I have to think it is because of my most recent blog post. That post showed how I used WildPackets OmniPeek to analyze the damage that unassociated smartphones can do to a WLAN. This follow-up is just a quick tutorial on how I set OmniPeek up to do that analysis.
In order to follow the same steps I did to analyze smartphone activity on a WiFi channel, you'll need a licensed version of WildPackets OmniPeek (Basic, Professional or Enterprise will do) and an 802.11a/b/g/n WiFi adapter that is compatible with OmniPeek. I used OmniPeek Enterprise with a Cisco-Linksys WUSB600 Nv1 adapter. To start, insert the WiFi adapter (if necessary) and open OmniPeek. Click theNew Capturebutton to bring up the Capture Options window. Next, click the 802.11link on the left hand side of the screen and select the Scanradio button. (If the Scan button is grayed out, that means that OmniPeek is trying to capture with an adapter/driver combination that is unable to use monitor mode.) Then click two successive OKbuttons in order to open an OmniPeek capture window that looks like this:
08/11/2012
Sniff WiFi
Pgina 14 de 49
After you click the greenStart Capture button, OmniPeek begins capturing frames, including those being sent from the smartphone you are trying to analyze. To view the list of APs and stations near you (including the offending smartphone), click the WLAN link on the lower left hand are of the OmniPeek capture window. If you are in an area with lots of WiFi, the WLAN screen may look sloppy, so you'll probably want to right-click on any AP or stationand select Collapse all. Collapsing the information on the WLAN screen will give you something like this:
Once in the WLAN screen, click the [+]to the left of your WLAN and then click the [+]to the left of your AP. Those steps cause OmniPeek to show the list of stations that are associated to your AP, and it should look like this:
08/11/2012
Sniff WiFi
Pgina 15 de 49
Once you are able to see a list of stations that are associated to your AP, the next step is to name your smartphone and create a filter. To name your smartphone, you will have to find the phone's MAC address. (iPhone MAC addresses are found via Settings -> General -> About.) Once you have the phone's MAC address, right click the smartphone's MAc address and select Insert into name table. You will get this screen, where you can give your smartphone an OmniPeek nickname:
With the phone named, the next step is to create a filter that will allow you to see only the frames being sent or received by the smartphone. Right-click the smartphonein the WLAN screen and select Make filter. OmniPeek will default to giving you filter settings that allow you capture only the frames that are being sent or received to your smartphone:
08/11/2012
Sniff WiFi
Pgina 16 de 49
The final step in configuring OmniPeek to capture a single smartphone's WiFi frames is to enable the filter that you have created. To enable an OmniPeek filter, just navigate to the Filtersscreen on the left hand side of the screen and check the checkbox for the filter that you just created.
And that's it. If you have followed these steps, your WildPackets OmniPeek will be capturing only what your smartphone is sending or receiving. The only other tip I can give is that you can always clear out old information and get a fresh capture by clicking the redStop Capture button and then re-clicking the green Start Capture button. I did that at one minute intervals in order to gather the information I used for the Phones on a WLAN blog post.
08/11/2012
Sniff WiFi
Pgina 17 de 49
Phones On A WLAN
jueves, 12 de abril de 2012, 19:03:00 | noreply@blogger.com (Ben Miller)
Enough is enough! I have had it with these motherf*cking smartphones on this motherf*cking WLAN!
-Neville Flynn, played by Samuel L. Jackson in Snakes on a Plane (paraphrased) Oh, if only our wireless networks could be saved from smartphones by a foul-mouthed constable. Instead, we have to deal with them. I've done a bit of sniffing recently in an attempt to figure out how much damage a roving smartphone actually does and it led me to a radical conclusion. At halftime of a Los Angeles Clippers game a few months ago, I had the occasion to speak with someone who works withthe Staples Center WiFi network. He was unable to share too many details for security reasons, but one thing he did share were the problems Staples Center has with smartphones. When people attend a sporting event, thousands of WiFi-enabled smartphones are brought into a large open space. The Staples Center WiFi guy told me that the WLAN infrastructure shows that thousands of Ad-Hoc networks are created by these smartphones, mostly in the 2.4 GHz frequency band. The end result is that the 2.4 GHz band is nearly unusable to media members, vendors and employees of AEG (the company that owns and operates Staples Center). The Staples Center WiFi guy's interpretation is a little bit off, I believe, because Cisco's controllers and management software are known to incorrectly classify unassociated, probing client stations as Ad-Hoc networks. (And feel free to correct me in the comments area if Cisco has a way to fix the classification of unassociated probing stations.) The way that these smartphones are classified by the Cisco infrastructure is irrelevant, though. What is relevant is that these devices are causing serious damage to the Staples Center WLAN, and any other WLAN that has lots of people crowding into a big, open space. In order to assess the damage that smartphones cause, I used WildPackets OmniPeek to capture the activity of my iPhone 4. The iPhone 4 has a 2.4 GHz 802.11b/g/n WiFi adapter. The iPhone 4's WiFi adapter has a single radio chain ("radio chain" essentially meaning a transceiver/antenna pair) and is incapable of using 40 MHz channels or the short guard interval. In plain(er) English, the iPhone 4 is, at best, a 65 Mbps device in the crowded 2.4 GHz frequency band. Now, a debate can be had on whether the phrase "65 Mbps device in the crowded 2.4 GHz frequency band" means inherent trouble or not. I say "no", some people say, "yes". (I am correct, of course.) For this blog post, let's set that aside and just look at the impact that a typical smartphone has on the WLAN. Here is a screenshot of an OmniPeek capture that I did for all traffic that an unassociated iPhone4 is a party to when the phone is turned on and unassociated for one minute:
08/11/2012
Sniff WiFi
Pgina 18 de 49
There are a few important things I am seeing in that capture. The unassociated phone only caused 128 frames to be transmitted on the channel that I captured on. Compared to a typical, active client station, that is pretty good. The problem is that the traffic is large (well over 300 bytes when in the form of a Probe Response), the traffic uses a low rate (1 Mpbs, or whatever the lowest Basic Rate is) and the client station is also causing similar amounts of traffic on other channels (definitely channels 1/6/11, and probably other channels as well). Contrast the above screenshot with an OmniPeek screenshot taken after an associated iPhone 4 was operating on the channel for one minute:
The associated smartphone caused 229 frames to be added to the channel. More frames is bad, usually. In this case, however, more frames is not so bad. The frames here are smaller (a bunch of 28 byte Null Data frames accompanied by 14 byte Acknowledgment frames) and the frames here use higher rates (the highest Basic Rate will typically be used for the Null/Ack power save sequence).
08/11/2012
Sniff WiFi
Pgina 19 de 49
Let's even do some rough math on this. If we assume that the physical layer overhead (PLCP header and preamble) is identical for all frames since we are looking at traffic going to or from a single device, then the MAC layer overhead is what will make the difference. When the phone is unassociated, lots of 117 byte and 369 byte frames were transmitted at 1 Mbps. That means 117 microseconds or 369 microseconds used per frame for MAC layer activity. When the phone is associated, lots of 28 byte and 14 byte frames were transmitted, usually at 24 Mbps. That means about 1 microsecond or a half of a microsecond used per frame. If we extend the math a bit, that means that each Probe Request/Response pair has the equivalent overhead of about 278 Null/Ack pairs at the MAC Layer. And even if we add 40 microseconds of overhead for the PLCP (a typical amount when 802.11n mixed mode is used), that still means that the unassociated station causes about seven times as much dead (read: unavailable for data) channel time per Probe Request/Response pair as an associated station causes for a Null/Ack pair. And that is not even accounting for the fact that the unassociated station is likely causing this overhead on at least three channels. If the preceding paragraph reads as a bunch of uber-techie mumbo jumbo, let me simplify it: a powered on, inactive smartphone that is not connected causes at least ten times as much damage to your public WiFi network as the same phone when it is connected. The obvious solution to the problem, then, is to treat smartphones the exact opposite way that Samuel L. Jackson's character treats snakes on 2006's internet darling, Snakes on a Plane. Neville Flynn (profanely) wants the snakes off his plane. You probably want smartphones on your WLAN. It may sound counterintuitive, but it may also prevent users from telling their friends that your WiFi network is the Snakes on a Plane of wireless networks.
Windows and Wireshark: Still Searching for the (Free) Answer

mircoles, 28 de marzo de 2012, 2:23:43 | noreply@blogger.com (Ben Miller)
There is an old joke in the IT world that software is like sex: you'll need support after you buy it.
Actually, the punchline to that joke is usually, "it's better when it's free." The problem is that the latter punchline fits poorly in the world of WiFi sniffing. The stuff you pay for really is a lot better. That said, a lot of people like to use free software whenever possible, and for Mac OS X and Linux users, there are some decent free WiFi analysis tools out there. For Windows users, however, the search goes on (and on, and on, and on...).
Long time readers of this blog may be aware that I prefer commercial WiFi sniffing software when doing real work. But free WiFi sniffers do have a place. If you are trying to learn about the technology, troubleshoot your own personal WiFi device or study for a CWNA/CWSP/CWAP certification exam, then you'll probably want some protocol analysis software but you probably won't want to pay a lot of money for it. The best choice for free protocol analysis software (be it for wired or wireless) is Wireshark. The trouble with Wireshark is that it is sometimes tricky to get Wireshark to sniff in the way I need it to sniff. For any real WiFi sniffing, I would recommend the following:
z z
Monitor mode 802.11a/b/g/n
08/11/2012
Sniff WiFi
Pgina 20 de 49
Preservation of physical layer information (channel, rate and RSSI)
Linux:My understanding is that most WiFi adapters can be placed into monitor mode for the Linux version of Wireshark. That is as much information as I have to share with you, because I am a Windows and Mac kind of guy. (And if there are any Linux folks out there who would like to guest-blog on using Wireshark or who have their own blog post that they would like me to link to, tweet me.) Mac OS X:I like using the Mac OS X 10.7 (Lion) utility Wi-Fi Diagnostics to do monitor mode captures. Then I open the captures in Wireshark. With this setup I get 802.11a/b/g/n and I get physical layer information. The only thing I don't get is full data frames. Wi-Fi Diagnostics captures redact the contents of data frames, ostensibly to prevent hacking. I am not trying to hack, so this setup works for me. Windows:Soooo close. But yet, so far away. There is a Windows-based option that does monitor mode, captures 802.11a/b/g/n and preserves physical layer information. Unfortunately it costs seven hundred bucks ($698 to be exact). With the Riverbed AirPcap NX USB adapter I can do what I need to do in Windows with Wireshark, but what's the point? If I'm going to spend hundreds of dollars, I might as well get WildPackets OmniPeek Basic for $1,194 and a DLink DWA-160 802.11a/b/g/n USB adapter for $60 (or less). And neither of those options gives me what I'm looking for here: free Windows-based WiFi analysis. An option that is free (or at least extremely low cost) is to capture using the Airodump application from Aircrack and then view the frames in Wireshark. You get monitor mode and you keep it free. Unfortunately, you don't get physical layer information and -- at least to my knowledge -- you can't capture with an 802.11n adapter. I have had success using the Netgear WAG511 PC Card, but that is an 802.11a/b/g adapter (and who the heck wants to use an 802.11a/b/g adapter nowadays, anyway?). I also tried other options that did not satisfy my WiFi sniffing needs. I found a Windows-based version of Kismet, but it only works with the expensive AirPcap adapters. I installed Network Monitor 3.4 from Microsoft, but it seems to not do monitor mode. I've even done captures in commercial software and then saved those captures in the Libpcap file format so that the frames could be viewed in Wireshark, but that sort of defeats the purpose of trying to use free software. To summarize, I must conclude that free WiFi sniffing in Windows is just one of those things that does not exist in any real way at this point. So if you want to do your 802.11 frame captures on the cheap and you don't want to buy a Mac, it may be time to break out that ol' dusty copy of Linux for Dummies.
WiPry Spectrum is Great, but it's All About the iPad

lunes, 06 de febrero de 2012, 20:48:12 | noreply@blogger.com (Ben Miller)
We all know that the iPad is great. We watch video on it, we play games on it and we can view ourTwitter feedson it (which, really, is where we getall important news). The only problem is, I could never do any work on it. The fact that Apple doesn't allow the internal WiFi radio to be used as for protocol analyzer software, site survey software or spectrum analyzer software always bugged me. Now, thanks to Oscium's WiPry-Spectrum, a spectrum analyzer is available, and boy does it show why the iPad is the ideal form factor for WiFi field work.
08/11/2012
Sniff WiFi
Pgina 21 de 49
Oscium is a company that I was unfamiliar with up until I happened upon their website while searching the web for iPad apps, and there is a reason for that. They are a company that makes device testing tools, not WiFi analysis tools. Luckily, those interests overlap. People who test devices need spectrum analyzers, and so do people who sniff WiFi. In this case that leads to a beneficial crossover, though there are some ways in which you'll wish that Oscium's products were more WiFi-specific. The WiPry product is sold as either a spectrum analyzer ($100), a power meter ($150) or a combination of the two ($200). It is a hardware product that plugs into the bottom of an Apple iOS device (iPad/iPod Touch/iPhone) and it looks like this:
As a spectrum analyzer, the software is pretty standard. You get a view of the spectrum density (called a Heat Map in the Oscium software), average signal and max hold, just as you would with any other spectrum analyzer. There is also an option to add cursors, which simplifies determining the signal-to-noise ratio (SNR). Here is an example of what my WiPry software looked like when I held the receiver pretty close to an 802.11g access point configured for channel 1.
08/11/2012
Sniff WiFi
Pgina 22 de 49
Notice how there are two horizontal lines; one solid and one dotted. Those are reference lines that tell me that there is a 51.23 dBm SNR at the maximum signal strength that was seen by the access point. There are other nice options as well. Two that I like are the highlighting specific WiFi channels and showing a waterfall view so that the amount of time an interference source affected you can be tracked.
The software is good, and at $100 I'd consider this a must-have for anyone who works in WiFi and who already has an iPhone, iPad or iPod Touch. All of this good stuff having been said, there are some warnings I have to give. One note is that Metageek, which is a company that makes a great spectrum analyzer for Windows and Mac OS X devices, is planning to release an iPad based spectrum analyzer at some point. Now, my opinion on things like that is that I'll believe it when I see it. Metageek has released some cool looking demo videos, but until the hardware starts shipping, I will remain skeptical. Still, if you are on a very tight budget and you know that you will only be able to afford one iPad spectrum analyzer that costs $100, then you will have to decide whether to use Oscium's great tool or wait to see if you can use Metageek's possibly-evengreater tool.
08/11/2012
Sniff WiFi
Pgina 23 de 49
The other problem is that is is tough to get exact numbers from WiPry. For example, the screen shows that the minimum received signal is -36.25 dBm and the maximum is 24.62 dBm. Read those numbers again. -36.25 dBm to 24.62 dBm. Has anyone who works in WiFi ever seen a 24.62 (or even 20; or even 10!) dBm received signal strength? Something is strange here. If you look at the second picture I posted above, you'll see that the signal from the access point in the office I write at showed a 17.74 dBm signal strength. I compared this with Metageek Chanalyzer (using the WiSpy DBx USB adapter) and I saw a signal strength of around -45 dBm at the same place from the same AP. When I emailed back and form with my contact at Oscium, his response was essentiallyeverybody's lost but me. His position is that their spectrum analyzer reads the signal strength correctly, and that Metageek (and Cisco, and AirMagnet, and Apple, and Broadcom, and Atheros...) reads the signal strength incorrectly. Whatever your opinion of Oscium's reading of signal strength, the bottom line is that if you want their number to jive with the RSSI values that WiFi stations will see, the Oscium signal strength will have to be reduced by about 63 dBm. The other major drawback of WiPry is that there is no support for the 5 GHz band. WiPry-Spectrum is a great product, and one larger issue that it brings up is that the iPad really is the perfect form factor for WiFi analysis. Oscium has gotten the job done by making a 30-pin adapter that does spectrum analysis. Now let's hope that Metageek, Fluke/AirMagnet, WildPackets, Ekahau and all of the other great WiFi analysis vendors follow suit.
Using AirMagnet to Analyze Voice Over WiFi

mircoles, 18 de enero de 2012, 20:01:54 | noreply@blogger.com (Ben Miller)
Mice in beer bottles, cold hands and supporting VoIP applications. These are a few of a wireless admin's least favorite things. And while this blog is the wrong place to look for solutions to two of those problems, here are some things to look for when evaluating software that lets you talk. Voice over WiFi is a topic that yours truly has written about before, but never in any real detail on this blog. Part of the reason is that the previously linked whitepaper was something less than a performance for the ages, and part of the reason is that VoFi is still a ways away from being a pervasive technology. Over the last few weeks the need to use VoFi software has arisen, and now is as good a time as any to describe how WiFi analysis software can be used to sniff out (pun not intended. Seriously. That word that is also in the name of this blog WAS TOTALLY ACCIDENTAL AND WITHOUT ANY INTENT ATSELFPROMOTION AT ALL.)which VoIP application is best.
08/11/2012
Sniff WiFi
Pgina 24 de 49
The two applications I sometimes use to make VoFi calls are Skype and Truphone. In the case of Truphone, "sometimes" means "often" and in the case of Skype, "sometimes" means "only when absolutely forced to by Skype loyalists who have yet to realize that the software stinks". Skype and Truphone both allow the user to make calls to the public phone network for a small fee and both run on a variety of mobile operating systems (including the only one the author really cares about, iOS). The big difference is that Truphone's calls usually sound great, and Skype's calls usually sound like you might expect this phone to sound. When deploying VoFi across an enterprise, applications like Skype and Truphone are less commonly used. The more likely scenario is that VoFi phones and/or SIP-based applications will be used. Still, the testing methodology is the same. It is best to get on a call, sniff the WiFi frames and see which application handles unlicensed frequencies the best. I decided to switch things up for this post and use Fluke AirMagnet WiFi Analyzer. The same basic activities can be done with WildPackets OmniPeek, but this time I decided to go for AirMagnet's simpler navigation. I began by using my iPhone 4 to make a Skype call on a Linksys 802.11g wireless router that is using TKIP encryption. Once in AirMagnet I navigated to the Infrastructure screen and selected Tx Total/% Total in the statistical analysis area that shows up here in the lower right hand corner of the screen:
I immediately found trouble. Look at that f'n Retry percentage. 34%!?! What the blue heck. Compare that with the same look at a Truphone call:
08/11/2012
Sniff WiFi
Pgina 25 de 49
Same client station. Same wireless router. Same channel. One-sixth the Retrys. Just 6%, to be exact. After seeing this it ceased to be a mystery to me why Truphone's call quality has always been so much better on my iPhone. But, why? What the heck is Truphone doing that Skype isn't? Let's let the eagle-eyed sniffers figure this one out. First, here are two frames that were captured during the Skype call. Skype from the wireless router (MAC address ending in 11:65):
Skype from the iPhone (MAC address ending in F5:C1):
08/11/2012
Sniff WiFi
Pgina 26 de 49
Now, let's take a look at Truphone. Just like with Skype, the first screenshot will be of a frame sent by the wireless router and the second screenshot will be of a frame sent by the iPhone:
So, what's different here? The first difference is that with Truphone, the wireless router is giving the Truphone call Video priority. If you look at the QoS Control field of the frames, you'll see that Best Effort is being used for Skype, while Video is being used for Truphone. The reason for the difference is a mystery to yours truly, but obviously Truphone is doing something with their end-to-end software that allows the wireless router that was used
08/11/2012
Sniff WiFi
Pgina 27 de 49
for this test to prioritize Truphone traffic ahead of ordinary traffic. The bigger difference is in the traffic coming from the iPhone. The QoS Data frames looks the same, but check out what precedes the QoS Data frame when the iPhone transmits a Truphone frame. It's Requestto-Send/Clear-to-Send (RTS/CTS). The Truphone app is apparently lowering the iPhone's RTS Threshold for Truphone traffic only and using RTS/CTS to keep the channel clear. The RTS and CTS frames are pure overhead, but they are small (20 bytes and 14 bytes, respectively). And whatever overhead they add is compensated for in spades by the great effect those frames have in reducing the percentage of Retrys. The same basic testing can be done with SIP applications (or any other media applications, for that matter). A quick look at the frames being sent and received by smartphones and other mobile devices can reveal a lot about which software is good and which software is Skype-like.
How Do I Know (If It Really Links Me)?

mircoles, 04 de enero de 2012, 22:12:25 | noreply@blogger.com (Ben Miller)
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.
Last week I put out a call for blog topic suggestions and my man Keith Parsonsmade the fine suggestion of going through some tips for troubleshooting using Mac OS X. I think that is a good idea, so here is a little bit on troubleshooting connection problems on my (and the unemployed screenwriter industry's) favorite operating system. If you understand 802.11 protocols, then troubleshooting connection problems can be done at an extremely low level. 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. When working with a Mac, I use Wi-Fi Diagnostics (an OS X Lion-only application) and Wireshark. Professional tools like WildPackets OmniPeek and Fluke AirMagnet WiFi Analyzer are unavailable for Mac OS X and, in fact, the same stuff that I'm doing here can be done even quicker with the expensive stuff on a Windows computer. First step in checking out your connection is to start a capture. The aforementioned 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. When a capture of all frames is done, the device disconnection. That means that if my Macbook Air is having problems connection (a too-common occurrence), then I can't run Wi-Fi Diagnostics from my Macbook Air. A perfect example is that to create this blog post 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
08/11/2012
Sniff WiFi
Pgina 28 de 49
Response frames could work, too. The problem with Association frames 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) andmanually scroll to the sequence of frames that were sent when the connection was made. A WPA Personal (PSK) connection will look something like this:
Frames 1865 and 1867 in my capture are Association frames. Those frames are of little use when troubleshooting connection problems, but the Association Request is useful for finding out what specs your station actually supports (security, QoS, 802.11n rates, etc.). Frames 1871, 1873, 1875 and 1877 are the WPA four-way handshake. The Mac OS X Wi-Fi Diagnostics tool essentially redacts these frames to prevent hackers from using Wi-Fi Diagnositcs as a preshared key (PSK) cracking tool, but you can tell that those are EAPoL Key frames by the 1-2-2-1 pattern of frame sizes.
08/11/2012
Sniff WiFi
Pgina 29 de 49
The key in troubleshooting WPA or WPA2 Personal is knowing that if the passphrase is mismatched between your client station and your wireless router, the four way handshake will fail after the second step. That means that with WPA Personal you'll see a 1-2-1-2 pattern of frame sizes in EAPoL Key frames as the client station keeps trying to complete the four-way handshake and the wireless router keepsrejecting it. A WPA/WPA2 Enterprise (802.1X/EAP) authentication can be found in the same manner, but troubleshooting that can get a little bit more complex because there are so many things that can go wrong with the EAP exchange. (And in a little bit of shameless self-promotion, I will point out that when I teach Global Knowledge WiFi classes I cover what to look for in an EAP exchange when trying to figure out which part of 802.1X/EAP is malfunctioning.)
One Card to Rule Them All

viernes, 16 de diciembre de 2011, 22:50:13 | noreply@blogger.com (Ben Miller)
FINALLY!
If you do a lot of sniffing, there is a chance that you have a bag full of USB adapters whose contents look like this:
z z z z z z z
Riverbed AirPcap NX Metageek WiSpy DBx D-Link DWA-160 Cisco-Linksys WUSB600Nv1 D-Link DWL-122 D-Link DWL-G122 Ubiquiti SR71-USB (w/ twoHG2401RD-MMCX2.4 GHz antennas)
I do, and it stinks. AirPcap is for Wireshark, WiSpy is for Chanalyzer, the DWA-160 and SR71-USB are for AirMagnet software, the DWL adapters are for Kismac and the Cisco-Linksys is for OmniPeek. It is a bit frustrating, especially if I need to switch between applications. Well, today I am a happy(er) man.
08/11/2012
Sniff WiFi
Pgina 30 de 49
The screen in that shot is WildPackets OmniPeek, running like a champ. And do you see that little thing on the right, there?
That is the D-Link DWA-160, working with OmniPeek like a champ. It is a little thing, I guess, but I am very happy to be able to use the DWA-160 adapter with WildPackets OmniPeek. This means that Fluke Networks' AirMagnet WiFi Analyzer & AirMagnet Survey, WildPackets OmniPeek and the Linux version of Wireshark all can do 802.11n monitor mode for 802.11n traffic (with up to two streams) with just one adapter. And it is cheap! I bought mine for $75 a couple of years ago. A full fledged WiFi sniffing hardware kit will still require more than just a DWA-160, but it has definitely become a good place to start.
Tell Me Why's, Tell Me Sweet Little Why's

martes, 22 de noviembre de 2011, 19:20:21 | noreply@blogger.com (Ben Miller)
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.
08/11/2012
Sniff WiFi
Pgina 31 de 49
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.
08/11/2012
Sniff WiFi
Pgina 32 de 49
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 sessionsif you want me to tell you what to look for. :)
What the #@*! is wrong with this WiFi? (and what can I do about it?)
lunes, 07 de noviembre de 2011, 23:40:44 | noreply@blogger.com (Ben Miller)
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 fabulousLas Vegas, NV, and I
08/11/2012
Sniff WiFi
Pgina 33 de 49
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 timeallow 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 groupusing 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 consumergrade 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:
08/11/2012
Sniff WiFi
Pgina 34 de 49
That ain't good. When a hundred journosare 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.
And a one, and a four, and a eight, and a 'leven...

viernes, 02 de septiembre de 2011, 6:19:39 | noreply@blogger.com (Ben Miller)
Channel choices can be a tricky thing, especially in the 2.4 GHz frequency band. I saw a network recently that had an unconventional channel design, but the network seemed to work pretty well.
Channel selection has long been a peculiar topic for 2.4 GHz WiFi networks. Per-channel frequency
08/11/2012
Sniff WiFi
Pgina 35 de 49
allocations in the band are 5 MHz wide (enough for a cordless phone or PowerPoint clicker, for example), but transmissions are much wider. The exact amount of bandwidth taken up by WiFi devices varies depending on the standards supported (802.11 b, g or n), the radio's transmission power and possibly other mysterious factors as well. (Just try running a spectrum analyzer around gear that supports transmit beamforming (TxBF) and you'll see what I mean.) A seasoned rule of thumb has been to keep APs running on channels 1, 6 and 11 in an environment that supports ubiquitous coverage. The theory is that, at typical transmission/antenna configurations, WiFi devices will transmit over bandwidths that range up to about 22 MHz wide. Using the aforementioned channels gives one 25 MHz of space between channels (five channels at 5 MHz per channel), thereby limiting the likelihood of interference. The counter to the 1-6-11 design is that a lot of channel space is being wasted. If WiFi devices operate O.K. with only a 20 MHz between APs (or even 18 or 15 MHz), then spacing the channels so far apart could be a waste. Recently I worked in an office with a WiFi installation that was designed to avoid that type of waste. Channels 1, 4, 8 and 11 were used instead of 1, 6 and 11. I was unable to talk to the person who installed the wireless network, but I did get a chance to investigate a few things. The first thing I looked at was the purely qualitative reaction of the people who use the network. Their reaction was one of unanimous approval. Now, that approval could have been due to the endpoint stations being used (just about all notebooks, iPads and smartphones) or due to the infrastructure vendor (Aruba, who I credit for turning the MGM Grand Garden Arena's WiFi from the unusable mess it once was into one of the best sports arena WiFi networks I've seen) or due to the fact that it was a building that was far enough away from neighboring buildings that outside interference was a non-issue. Still, +1 for 1/4/8/11. I also did a little semi-scientific stress test. I checked my channel (8, for the record), used WildPackets OmniPeek to see what other channels had strong signals in the room (only 4, though 1 and 11 could have been strong enough for a low rate connection) and then started watching NBA highlights on YouTube. The video played just fine, but I did notice something disconcerting. The Retry percentage on channel 8 jumped immediately. The number fluctuated, of course, but generally hovered somewhere between 8 and 12 percent. Now, 8-12% Retrys can be just fine, but for this environment I'd say that is too high. I was on a notebook (easy), sitting still (easy), associated to an AP mounted in a hallway (hard) below the ceiling (could be easy or hard) in an isolated building (easy) and running a streaming web application (a little hard). All told, the environment leaned a bit towards an easier installation than a hard one. It is always tough to get a feel for whether something could be improved without chatting with the wireless network administrator, but based on my quick sniff of the channel, it appeared to me that I probably would have gotten better results if APs were placed on channels 1, 6 and 11. (Though if they were, who knows if the VAR could have managed to sell an AP every 45 feet or so.) I am curious to hear feedback from readers, too. If you have a WiFi network that has either channel design (or something altogether different than 1/6/11 or 1/4/8/11), drop me a line or post a comment. If you have the time to do a quick check of your Retry percentages, all the better. My guess is that 1/6/11 is going to give better results because of the 1/4 and 8/11 overlap, but I have been wrong before (as anyone who attended the 2006 CWNA train-the-trainer class and heard me repeatedly pronounce that 802.11n would
08/11/2012
Sniff WiFi
Pgina 36 de 49
never be widely adopted can attest).
Time To Talk Chanalyzer

lunes, 11 de julio de 2011, 23:56:07 | noreply@blogger.com (Ben Miller)
The Metageek spectrum analyzer package (WiSpy hardware with Chanalyzer software) has long been a favorite of thrifty sniffers. It has long deserved some praise from this blog, and with Chanalyzer 4 melting steel like a CM Punk promo, now is a good time to give it. For many years spectum analysis was overlooked or even ignored by WiFi professionals, and for good reason. If you were managing a wireless network back in the days of 802.11b (or even the early days of 802.11g), there was a paucity of good, affordable spectrum analysis tools. You could buy a hardware analyzer (I first usedsomething similar tothis beast), but those things were usually expensive anddesigned as general purpose analyzers rather than WiFi-specific analyzers. Spectrum analysis changed for the better in 2005, when Cognio released the Spectrum Expert analyzer. Their PC Card/software combo immediately became a favorite of WiFi folk and remains one today (though the product is now the Cisco Spectrum Expert after a 2007 acquisition).The problem with Spectrum Expert is that it is expensive ($2,874 at Sears) and it requires a computer with a PC card slot.Some smart folkssaw those problems and formed Metageek, which introduced WiSpy to the market as a USB-based spectrum analyzer that is sold at a fraction of the price. Metageek's signature spectrum analysis package is aWiSpy DBx USB adapter with Chanalyzer software (retail price: $599). It's a great product that does lack some of the short-cuttery that Spectrum Expert offers, but overall makes for a useful product. The WiSpy/Chanalyzer combo has been reviewed elsewhere, so I'll pass on going through a full overview. Instead I want to just talk about some cool new stuff that's been added and some tips that have proven useful in my experience. When Chanalyzer starts up, it looks like this:
08/11/2012
Sniff WiFi
Pgina 37 de 49
Much of what can be seen is self-explanatory, I think. The top portion of the screen shows the current RF environment, the middle portion shows a temporal view of the amount of activity at each frequency and the bottom portion has a number of additional tabs that show information like nearby APs (which I have selected in the screenshot), recordings of possible interference sources or signatures of certain known RFtransmitting devices. I generally use the WiSpy/Chanalyzer combo as sort of a last resort. I prefer to use WildPackets OmniPeek or AirMagnet WiFi Analyzer to sniff 802.11 frames if I'm trying to solve a performance problem, but if I can't figure out why there are high numbers of Retrys (indicating a network problem) or CRC Errors (indicating a problem at the location of my sniffer), I'll look to WiSpy/Chanalyzer to try to figure out why.
z
Spectrogram (waterfall): If there is a temporary interference source, like medical imaging equipment or a poorly shielded microwave oven, the temporal view in the middle of the screen should show it. Max: Great for finding interference sources. You just have to make sure you turn off your notebook's WiFi radio before using the Max view, otherwise you're probably going to just be looking at your own RF transmissions. Density: Sort of the ordinary, every day way to look at interference. The Density view shows a more prominent pattern as the amount of RF transmissions at a given frequency are seen. (This one can be deceptive, especially with 802.11n. Those 802.11n Beacon frames are so large that sometimes you'll see what looks like a very dense outline coming from an AP that barely has any data going through it. That's whyIlike to look at a sniffer first.)
There is one more interesting view in WiSpy/Chanalyzer, and that is the Current view. The theory behind the Current view is that it shows a transmission pattern, thereby allowing a user to identify which type of device is causing the problem. Here's a screenshot of some kind of interference showing up at the office I'm owrking at today in my Current view:
Pretty cool, no? I can see the little spikes going across various frequencies and I can compare that transmission pattern to the Signatures that are packaged with the Chanalyzer installation. (In fact, I can
08/11/2012
Sniff WiFi
Pgina 38 de 49
even add signatures by clicking and dragging across a spread of frequencies.) From that spiked pattern, it sure looks like someone is using Bluetooth (or a microwave oven, or a lighting system, or something else...) in this office. The problem is, I can't tell for certain. In a crowded office space like the building I'm in near La Brea & Santa Monica ($1.66 for splash-less Clorox at the Target down the blocktoday; get it while you can) it's darned near impossible to distinguish between different interference sources. It is quite valuable to have a spectrum analyzer with built-in signatures for common interference sources so that I would receive a little warning if a known interferer in nearby. That is not to say that WiSpy/Chanalyzer should be avoided, because for the $600 price it simply is the best WiFi spectrum analyzer available. It's just that if you have the budget for a $3,000 analyzer, you're probably going to find that thedevice identification capabilities of Spectrum Expert (or possibly AirMagnet Spectrum XT, which I have yet to use) are worth the added price. So there you have it. WiSpy/Chanalyzer is a great tool for finding interference sources (Max), identifying temporary transmitters (Spectrogram) and viewing general RF activity (Density). You can try to use it to identify specifc interfering device types in your vicinity as well (Current), but it may take some practice before that functionality is very useful.
Bad Medicine: Roaming and Sniffers

jueves, 02 de junio de 2011, 23:17:07 | noreply@blogger.com (Ben Miller)
I believe in sniffers. I believe in planning for client roaming. And I believe that mixing the two is a bad idea. Using a sniffer the right way and planning for client roaming the right way are both essential for having a high quality WiFi network, but it's a good idea to keep the two separate. This is, of course, a blog about WiFi sniffing, but to understand why using sniffers to plan for roaming is trouble, let's go into some background on WiFi client roaming. WiFi (802.11) networks were designed like cell phone networks in that client stations would be able to maintain application connectivity while moving between access points. They were also designed to be unlike cell phone networks in that the client station would control when roaming happens. You see, in cell phone networks, the network infrastructure controls when your phone moves to a different base station. That design makes sense because cell phones have a built in way of giving base stations information about the phone's RF environment. A good roaming decision requires accurate RF information procured at the location of the mobile device (since RF is location-specific, after all), so this ability of cell phones and base stations to communicate makes it so that the infrastructure can make a good decision on when a phone should handoff. WiFi networks (at least, prior to 802.11k) lack that ability. Only the client knows its RF environment, so only the client can determine when roaming should occur. Let's think about the impact of having a client that decides when it is going to roam. One thing that means is that we lose the ability to do a fully offline site survey. I can't just upload a floorplan, plot out APs and configure a signal level or signal-to-noise ratio (SNR) at which clients will look for a new AP. I have to test each client individually and figure out approximately what signal/SNR will cause each type of client to engage in roaming. (It actually gets even more complicated than that, as sometimes a client will react differently to two different APs that produce the exact same signal.) There is a way to plan for roaming. In broad strokes, the steps are:
08/11/2012
Sniff WiFi
Pgina 39 de 49
1. 2.
Find the signal/SNR at which your station typically initiates reassociation. This is the client station's roaming threshold. Run a site survey planning application (AirMagnet Survey/Planner being my tool of choice). When you do this, your goal is to plot out an AP's theoretical coverage area and find the areas where client stations are are likely to hit their roaming threshold. Then you want to make sure that a different AP will also cover that area at an even higher signal so that roaming will (hopefully) be smooth. Verify your AP locations by going on site and surveying to see if you get the signal/SNR levels (or, at least something close) that showed up in your plan. You can do this by temporarily mounting APs and recording their signal/SNR levels.
3.
The planning application and the on-site surveying are best left for another time (or, perhaps, another blog). My concern is with testing the client station to determine its roaming threshold. If you're sniffer-friendly, the temptation may be to try to find the roaming threshold by looking at a packet capture. The idea is that you'd plug in a WUSB600N (for WildPackets OmniPeek), a DWA-160 (for AirMagnet WiFi Analyzer) or an AirPcap NX (for my frenemy, Wireshark) and run your packet capture while moving between two test APs. Any one of the aforementioned sniffers will capture your reassociation request/response frames when you roam. Once you find that reassociation response frame (which always is transmitted by the AP), you look at its signal level and, voila, you have a roaming threshold. The problem with using your sniffer to find the roaming threshold is that the reassociation response frame you'd be looking at would be showing a received signal strength as read by the capture adapter. The client station's radio would not be showing you its received signal strength. Due to differing receive sensitivities, antenna gains or radio/antenna connections, the signal strength shown in a reassociation response frame could be quite different than the actual received signal strength at your client. There is a better way to identify the client station's roaming threshold, and that is to view the signal strength from the client utility. And if you have a client utility that doesn't show you a signal strength as a dBm or % reading, you can use some other utility that ties into the client station's radio (MetageekinSSIDer, the Xirrus WiFi Monitor and the netsh WLAN commands are all free tools that are useful for Windows-based clients). This can be tricky because you really have to keep your eye on your BSSID to see exactly when the client station reassociates, but if you run through a few tests you'll get the hang of it. Once you do, you'll have a good idea what level of roaming threshold you should plan for. Client roaming is one of the toughest WiFi problems around. WiFi sniffers are often the best tools for solving tough wireless problems. Unfortunately, in they don't go well together. WiFi sniffers are great if you need to identify, test or solve roaming problems after an installation, but those applications should be set aside during the planning stage.
Three Things I Like: AirMagnet WiFi Analyzer

viernes, 01 de abril de 2011, 2:02:29 | noreply@blogger.com (Ben Miller)
Readers of this blog may have noticed that my frequency of blogging has waned in 2011, so it's time for some self-motivation. I'm going to start a series of blog posts titled, "Three Things I Like"
08/11/2012
Sniff WiFi
Pgina 40 de 49
and apply to all sorts of WiFi (and possibly even some non-WiFi) topics. I'm going to start with a darned good WiFi sniffer, Fluke Networks' AirMagnet WiFi Analyzer.
AirMagnet WiFi Analyzer from Fluke Networks has long been the leading WiFi protocol analyzer by market share. It has also long been one of my favorite tools to use when helping others learn about WiFi. Here are three things that I like about AirMagnet WiFi Analyzer.
1.
Pre-made device filters.When you navigate to the Infrastructure screen (fourth icon from the left in the navigation menu that sits in the far lower left hand corner of the screen), any time you click on an access point (AP) or station, the software immediately starts showing you statistics on frames that are traveling to or from that device only. This is a massive time saver, as in WildPackets OmniPeek or Wireshark, you have to create all filters manually. I use this to attempt to isolate which station or AP is using low rates or experiencing high Retry percentages (the tell-tale signsthat WiFi performance is middling or at some point will be). The Find tool.No matter where you are in the AirMagnet WiFi Analyzer interface, you can always use the Find tool. Just right click on a device (it works best for APs, but you can try it with stations as well) and select Find. At that point you'll be immediately sent to the WiFi Tools screen and into the Find tool. When you click Start you'll see a signal meter become active. If you start walking around, the signal meter will help you find the location of the device you're looking for. To make things even easier, try the Ubiquiti SR71-USB adapter with a directional antenna. Ed note: Long time AirMagnet trainer Keith Parsons commented that he prefers using omni-directional antennas because sometimes the back lobe coverage of a directional antenna can sort of confuse the Find tool. Keith has forgetting more about AirMagnet than most people will ever know, so I trust his advice here.
2.
3.
The Diagnostics tool. The Diagnostics tool is similar to the Find tool in that you can launch it by right-clicking on any device anywhere in the software, but different in that it is more useful for stations than APs. The real usefulness of the Diagnostics tool to me is that you can use it to see a summary of the frames being sent during WiFi Protected Access (WPA) and WPA2 authentications. If you know what a Preshared Key (PSK) or 802.1X/Extensible Authentication Protocol (EAP) handshake is supposed to look like, you can use the Diagnostics tool to pick out anomalies that might reveal the source of your problem.
There you have it; three things I like about AirMagnet WiFi Analyzer. Next up: Chanalyzer 4. If you have a topic that you'd like me to do a Three Things I Like blog post about, email me atben@sniffwifi.com.
Get Personal, Gogo

jueves, 31 de marzo de 2011, 1:21:43 | noreply@blogger.com (Ben Miller)
Last Sunday I took a flight equipped with Gogo in-flight WiFi so that I could work in an office with guest WiFi. The difference in security was stark, and Gogo should make changes to fix their poor (and, in my opinion, negligent) WiFi security.
Gogo in-flight WiFiis a service that I've blogged about before, but I feel compelled to mention it again because the security problems I complained about a year and a half ago are still there even as hacking knowledge and applications have grown. To recap Gogo's poor security design:
08/11/2012
Sniff WiFi
Pgina 41 de 49
Open System authentication with no encryption is used for Gogo's WiFi security. This means that applications like Firesheepallow hackers to do sidejacking attacks, like the one that seems to have been performed on Ashton Kutcher recently. Captive Portal authentication is used to charge passengers for Internet access. This means that anyone who knows how to spoof a MAC address(link is for XP, but the same can be done in Vista/Win7 via the Networking and Security Center) can wait until someone buys Gogo's service and then use the purchaser's MAC address to piggyback on the service for free. Since Open System authentication is used, any device that sends Probe Request frameswhen looking for WiFi networks will become vulnerable to an Evil Twin AP attack from applications like KARMAthe moment the device leaves the plane.
All of these problems have been well known, but the implicit justification from providers of paid WiFi service is that, A) the network must use Open System authentication in order to allow the largest possible number of users to potentially pay for the service, and B) users can always setup their own SSL encryption using services like WiTopia(there are other SSL services, but I tout WiTopia because I use it and I've been very happy with their service and support). This justification is balderdash. On the latter point, it is negligent (in my opinion, to the point where they deserve to be legally liable) for such a large service provider to force their users to provide their own way of even the most basic security. I think that this would be akin to Target allowing their parking lots in Milwaukee to ice over in the winter, and then posting signs telling their patrons to bring a bag of salt so that they don't break their elbow on their way in to buy a Tassimo. The point about Open System authentication being necessary to allow the largest number of potential customers to access Gogo in-flight WiFi used to be a good one, but the guest network at the office I'm working at this week is evidence that Gogo needs to change. In this office the guest WiFi uses a Preshared Key (PSK) passphrase that matches the SSID of the network. This makes it easy for guests to remember and even allows people to make an educated guess if they miss the official notification that the guest WiFi network is using encryption. WPA/WPA2 Personal (the Wi-Fi Alliance's name for PSK-based networks) solves the fundamental problems with Gogo's current security plan. To wit:
z
Applications like Firesheep don't work because each station negotiates a unique AES-CCMP or TKIP encryption key after association. Even if an attacker knows how to decrypt frames in a protocol analyzer, it wouldn't work with Firesheep because Firesheep uses promiscuous mode and protocol analyzers use monitor mode when decrypting frames.* The captive portal would be more secure because each station MAC address would be tied to the AES-CCMP or TKIP encryption key that was negotiated after association. If an attacker spoofed a MAC address, they would get no access because the attacker would lack that unique encryption key. Stations that send probe request frames would be more secure from Evil Twin AP attacks because they would not automatically associate to an open network that uses the SSID of "gogoinflight". Evil Twin AP attacks would still be possible, but only if the attacker is able to create an Evil Twin AP that uses the correct PSK passphrase. Currently KARMA does not do that.
Do the right thing, Gogo. Add a PSK passphrase of "gogoinflight" to the SSID of "gogoinflight" and then run the captive portal after users have created that AES-CCMP or TKIP encryption key. Or heck, just create a second SSID of "gogosecure" with a PSK passphrase of "gogosecure" so that we at least have the option
08/11/2012
Sniff WiFi
Pgina 42 de 49
of thwarting Firesheep attacks and you have less MAC addresses that can be spoofed. There may be some initial pains while that type of change is made, but it'll probably cost less than a lawsuit if anyone ever loses anything really important while connecting to your poorly (and, I would argue, negligently) secured WiFi service. *Decryption can be done by attackers if PSK passphrase (WPA/WPA2 Personal) authentication is used, but it can only be done on one station at a time and currently available software only does it to TKIP-encrypted frames (meaning not AES-CCMP encrypted frames). -I was wrong. CommView for WiFi and Wireshark both now decrypt AES-CCMP encrypted frames. That's what I get for avoiding mediocre sniffing software. :)
Brevity is the Soul of Wit (But Not the CWDP Study Guide)
viernes, 25 de febrero de 2011, 21:13:36 | noreply@blogger.com (Ben Miller)
The CWDP Study Guide was recently released. The certification is valuable and the study guide is great as a reference, but as a book it is just about unreadable.
Certified Wireless Design Professional (CWDP) is a new certification from the CWNP Program, a group that creates and manages vendor-neutral WLAN certifications. The CWNP Program has long had a Certified Wireless Network Administrator (CWNA) and Certified Wireless Security Professional (CWSP) certifications, and here in 2011 they are adding the CWDP and Certified Wireless Analysis Professional (CWAP) certifications. The spirit of these certifications is that WiFi professionals often work in very specific disciplines, so the CWNP Program has a certification track for most industry professionals. Work for an equipment vendor? You probably want CWAP. An integrator? Probably CWDP. The NSA? CPP. (I jest, I jest. And if any NSA people read this blog, let me request the pain-free truth serum in advance.) The CWDP exam is the next exam to be officially released (next Tuesday, to be exact), but the study guide is already available. The study guide does what it's supposed to do in covering all exam objectives, BUT IT'S NINE HUNDRED PAGES LONG! That is crazy. You simply do not need 900 pages to explain how WiFi networks need to be designed. Admittedly, I had a negative perception of this book before I started reading it due to its length, but after reading it I must say that I was exactly right. The book seems to cover every contingency the authors could think of (business needs, building types, applications, 802.11 standards, mobility, etc.), but it ends up being overwhelming. The book is great as a reference because you get all the equations, estimates and calculations you'd ever need. As a guide for designing a WLAN in the real world, however, the book needed to be about 1/3 the size. One of my favorite books I've ever read is Storyby Robert McKee. I love this book for many reasons, but most prominently because it emphasizes form, not formula. It covers what storytelling for movies/television/theater is and why it works rather than breaking down every possible way to plot a reveal for your second act midpoint. (And if you understand that last sentence, you should be reading John August's blog instead of mine.) It takes a topic (storytelling) that is brobdingnagian in relation to the topic of WiFi design, and covers it in half the number of pages. That is what I was hoping for from the CWDP Study Guide. Instead, I got a book that contains so much information that it is a must-have for WiFi designers and surveyors, but also unusable as anything but reference material.
08/11/2012
Sniff WiFi
Pgina 43 de 49
Chiggity-Check Your Phone (With a Sniffer)

martes, 22 de febrero de 2011, 4:30:39 | noreply@blogger.com (Ben Miller)
It should come as no surprise that many WiFi-enabled mobile phones sometimes exhibit behavior that makes them vulnerable to attack. In at least one case, you can use a WiFi sniffer to view such behavior so that the proper changes can be made to your phone.
When a WiFi device associates to an access point, it must first go through the process of Discovery so that it can decide which AP is best (based on SSID, signal strength, etc.). Discovery is done either by listening for Beacon frames or transmitting Probe Request frames in hopes of eliciting a Probe Response frame. The Discovery process reveals the same information about an access point (SSID, channel, rates, security, etc.) whether it is through a Beacon or a Probe Response, it's just that the probing process can be faster because the station can initiate it at any time. The problem with the Probe Request/Response sequence is that it could lead to an attack. Hackers running sniffing software (for the types of nefarious purposes not advocated on this blog, that is) may view the SSID carried in the Probe Response as a way of figuring out what networks a station is trying to connect to. Hackers may then search for that SSID at wardriving sites like wigle.net(perhaps trying to find out where you live or work) or create an Evil Twin access point in hopes of causing your station to make a direct association to the hacker's laptop. Katy, bar the door if that happens. A hacker that has an unsuspecting station associated to his Evil Twin access point can attempt all sorts of attacks, as has been shown over and over again. To prevent such post-Evil Twin access point attacks from occurring, it is wise to disable the sending of Probe Requests in station devices, especially if those devices don't need the faster reassociation that those frames were designed for. In Mac OS X, Windows Vista, Windows 7 and Windows XP SP3 stations, this is trivial. OS X stations only send Probe Requests for a short time after the WiFi radio is turned on, and Windows stations disable the sending of Probe Requests by forcing the user to check a checkbox indicating that the SSID is non-broadcasting in order to enable probing. The fault, dear readers, is not within our laptops, but in our phones; that they are probing. Solving the problem of phones (and tablets, at least in the case of the iPad) sending Probe Requests can be a complicated task. The WiFi client software used by these devices is often primitive. In the case of iOS devices (iPhones, iPod Touches and iPads), users are not presented with a list of Preferred Networks. When you turn the iOS device on, it just starts probing for every SSID you've ever connected to unless you've tapped the Forget This Network button before leaving the network. And if you forget to tap Forget This Network? Well, you're stuck. The iOS device will continue to send Probe Requests containing the SSID, but you won't be able to Forget the SSID until you connect to it again. So what to do if you have an iOS device (or any other device that you want to protect from Evil Twin access points)? If you want to know which SSIDs your device is sending Probe Requests for, you just need to run a frame capture and filter on the unassociated probes. Here's how:
z
In AirMagnet WiFi Analyzer, you go to the Infrastructure screen and select Listed By SSID (I'll add a screenshot next time I'm in Windows) in the drop box at the top of the screen. Any SSIDs that don't have an AP underneath them are SSIDs that stations are probing for. In WildPackets Omnipeek, you go to the WLAN screen and look under ESSID Unknown --> BSSID
08/11/2012
Sniff WiFi
Pgina 44 de 49
Unknown. SSIDs shown there come from Probe Request frames. In Wireshark, use the filter, "wlan.fc.type_subtype == 0x04". After applying that filter, scroll through the Probe Request frames and see which SSIDs your station is probing for.
Once you find out which SSIDs your device is probing for, you can adjust your device to make its operation less vulnerable. If your device has a Preferred Networks list, just go into that list and remove unsafe SSIDs (meaning unencrypted SSIDs or SSIDs that would reveal your location in a Wigle search). If your device doesn't have a Preferred Networks list (like in iOS), then just configure an access point with the SSID you were probing for, and then after your device sees that SSID, tap that Forget This Network button. It may not solve all of the problemswith mobile device security, but it will solve one of them.
WiFi In The Arena

jueves, 20 de enero de 2011, 5:05:38 | noreply@blogger.com (Ben Miller)
UFC 125 happened on New Year's Day, and I was fortunate enough to cover the show for the Wrestling Observer. As with just about every sporting event nowadays, the MGM Grand Garden Arena provided WiFi service for the members of the media who were covering the event. I managed to squeeze in a little bit of sniffing while I was doing my live blog, and the results I found were a little bit surprising to me. When I think of public Wi-Fi, I think of downloads. Maybe that makes me an old codger, but I just imagine all of these web pages, videos and spam emails coming down with just a few requests and acknowledgments going back up. The world has changed, of course, with more people than ever wanting to tweet, blog and upload photos as part of the social media revolution, but I still was dubious when Andrew Von Nagy (@revolutionwifi) told me on Twitter that I should expect a pretty even distribution of data on any public WiFi network nowadays. Sniffing in the media area turned out to be a bit of a chore. When I got cageside (after a scrumptious fajita lunch in the press room; thank you, UFC), I immediately booted into Windows 7 and broke out my trusty WUSB600N adapter so that I could run WildPackets OmniPeek. At that point I slid on over to the WLAN screen (SSIDs/APs/stations) of OmniPeek to find my laptop's AP. What I found was an RF war zone. I wish I would have been smart and taken a screen capture, because this place had all the makings of an unusable hot WiFi mess. Plenty of APs on every 2.4 GHz channel, no 5 GHz APs and a mish-mash of different vendors providing the coverage (Vivato and Aruba, to be specific). Since I was using the Windows 7 wireless client (what can I say, I'm too cheap to spend the fifty bucks on the Juniper Odyssey Access Client) I had no idea which BSSID was mine. I had to sift through a number of APs on channel 11 until I finally found my station's MAC address. (And if you're wondering why I didn't have my laptop named in OmniPeek already, that's a good question. The reason is that my Macbook Air suffered yet another meltdown and had to be rebuilt. I got all of the requisite sniffing software installed on the Windows partition, but I had yet to repopulate the Name Table.) Once I found my BSSID, I quickly created a filter for it and started working. I checked the full stats for the AP (about 120 kbps, on average) and then I modified the filter to check to downlink (~74 kbps) and uplink (~46 kbps) usage. Unfortunately, I was there for a job outside of sniffing, so I lacked the time to do a full analysis of the WLAN. Had I been there for strictly sniffing purposes, I would've looked more closely at other stations (there were tons, but I didn't get a full count), Retry percentages and data rates. The whole experience was an eye opener in one way and quite typical in another way. On the one hand the
08/11/2012
Sniff WiFi
Pgina 45 de 49
MGM Grand Garden Arena had a multi-vendor environment with a ton of APs and no 5 GHz coverage, yet it worked. On the other hand, questionable RF design often does work just fine when WLAN usage is fairto-middlin', but breaks down when put under stress. This event had one of the smaller media attendances in recent years for a Las Vegas UFC show. I'll be interested to see what the results look like next time when WiFi usage is likely to be much higher.
Setting Data Rates - Just (Don't) Do It.

sbado, 01 de enero de 2011, 1:07:29 | noreply@blogger.com (Ben Miller)
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-tonoise ratio and users-per-channel but in the spaces where desired numbers collide, the owner of the WLAN has to make good choices in allocating the resources that are available. One of the obvious choices admins often make is to limit the bandwidth available to guest users. 'Tis a noble idea, but it must be done the right way. Appliances that limit the wired bandwidth of guest users do the job, at least to some degree. (I'll save my treatise on my distaste for bandwidth limits for another time.) Unfortunately, most WiFi controllers and APs lack true a bandwidth limiting function. What controllers and APs often do have is the ability to limit data rates. You can dictate that users associated to the guest SSID are limited to either an exact data rate -- such as the 18 Mbps that I saw at the hotel near Chicago -- or a maximum data rate. In theory this may sound smart, but in reality it is a bad idea because you are limiting data rates, not throughput. Data rates are the speed of one frame across one data link. If you are using WiFi, that means the speed of one frame from your AP to your laptop. The frames that are being sent are also part of a shared channel. That means that when the AP is sending a frame to your laptop, it can't be sending a frame to anyone else's laptop. Throughput is a measurement of the total amount of data divided by the total amount of time it took to send or receive that data. It is the real, usable speed that your applications have available when you are on a WiFi network. Your throughput is affected by your data rate, but it is also affected by the data rate of everyone else who is on the same channel. If you are receiving frames at 216 Mbps (as I was when I began writing this piece), that's great. Your laptop will be taking very little time to receive frames and the other stations on the channel will be very happy that your laptop takes up so little channel time. If someone else on my channel is forced to receive frames at 18 Mbps because they are on a guest SSID, my laptop's throughput will be
08/11/2012
Sniff WiFi
Pgina 46 de 49
compromised because I'll be staying quiet for more time than I need to while that guest user receives their slow frames. Manipulating data rates can have other negative effects besides just slowing down the channel. For most WLAN controllers and APs, setting a specific rate limits the speed of frames transmitted by APs, but not transmitted by stations. Here's a look at a Beacon frame transmitted by my Linksys WRT160N 2.4 GHz 802.11n wireless router:
The rate information (Supported Rates and Extended Supported Rates) is identical to the rate information that was showing up in the Beacon frames at the hotel I was staying at outside of Chicago. Notice how there is no indication that only a 18 Mbps rate will be used by the AP. Stations are receiving Beacon frames that show all rates between 1 Mbps and 54 Mbps as supported. The end result of this is high Retry percentages because stations remain associated to the AP when they are transmitting all the way down to 1 Mbps (where frames can be demodulated at a great distance), but the AP keeps its rates at 18 Mbps (where frames can be demodulated only at a lesser distance) no matter what. Hopefully I've made a convincing argument against specifying low rates for guest access, but there is one other rate-related topic that I want to touch on. It is the topic of disabling low rates in an attempt to enhance roaming quality. I bring up this last topic because I was teaching a class a while back and one of the students told me that he was told that disabling 1, 2 and 5.5 Mbps was recommended to enhance roaming. The theory is that when a station reaches the lowest rate above the disabled rates (6 Mbps, in this case), the station will know to being the reassociation process, thus avoiding the problem of having stations associated to APs where the signal quality is so poor that only the lowest of the low rates are available. I am torn on this subject. On one hand, I would assume that whoever told him to disable those low rates had tested the WLAN using the production clients and found that they roamed better with those rates disabled. I am believe that if you test something and it improves performance you should use it, so in that way I like it. On the other hand, this makes little sense to me. In my experience stations tend to begin the reassociation process based on having a low signal strength or signal-to-noise ratio (SNR), not necessarily a low data rate. If a station is receiving frames at a signal level that is above its roaming threshold, then the
08/11/2012
Sniff WiFi
Pgina 47 de 49
possibility exists that the station would remain associated to the AP but be unable to demodulate frames because the low rates that could be demodulated have been disabled. The end result of that would be high Retry percentages, and I have seen many WLANs with low rates disabled and high Retry percentages. Now, I do want to make clear that if you are working with only 802.11g/n stations, then disabling *all* 802.11b data rates (1, 2, 5.5 and 11 Mbps) is advisable in many cases. What I am skeptical of is the idea of disabling *some* 802.11b data rates and leaving others enabled because some 802.11b stations are present on the network. As always, I'm interested in other peoples' experience. If you have specified data rates or disabled low rates and found improved performance, please do share with us in the comments section. But my experience has been that doing those things is counter-productive, so my general recommendation is to just leave the data rates alone when configuring your WLAN.
If It Ain't Broke, Fix It

mircoles, 08 de diciembre de 2010, 7:56:29 | noreply@blogger.com (Ben Miller)
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 the 2006 World Cup1. And accepting an underperforming WiFi network because it seems to be working fine could cause an administrator to face dire consequences down the road. I bring up this problem because lately I've been running into quite a few WiFi networks that work fine, but have serious problems. Today, for instance, I was connecting to a hospitality network with a slick captive portal, solid Internet access and 20% Retrys. It's just my hotel's WiFi network, so I can only guess what the problem could be. Interference? Bad APs? Too many APs? Hidden node? Any or all of those could be contributing factors. A WiFi network with 20% Retrys may work just fine most of the time, but I wouldn't want to be around when things get difficult. If this hotel had a large conference or wanted to put their push-to-talk handsets over WiFi or even just wanted to place wireless room service ordering kiosks in rooms(why has no hotel done this, by the way? The cool factor alone would lead to a few $17 B.L.T. orders from me), they'd probably be entering a world of pain. The point here is that there sometimes analyzing and making changes to a WiFi network is a good idea even if things seem O.K. from afar. In WiFi, as in life, uninformed analysis and over analysis can leave a bad taste in a person's mouth, but one should be careful to avoid rejecting analysis entirely.
08/11/2012
Sniff WiFi
Pgina 48 de 49
KisMAC and AirPort - A Match Made in Heaven (Almost)

viernes, 26 de noviembre de 2010, 22:27:23 | noreply@blogger.com (Ben Miller)
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-122 adapter. 802.11n adoption has exploded in 2010 (a good topic for a future blog post, I think), so the usefulness of an 802.11b/g adapter to capture is starting to wane. It is true that the majority of enterprise-class WLANs still have a preponderance of 802.11b/g devices in use, but if you run into that odd 802.11n laptop, tablet or phone, you'll regret restricting yourself to 802.11b/g. This made KisMAC with a DWL-122 a limited option. I could use it on airplanes and other public spaces that are still have yet to upgrade to 802.11n, but for money sniffing KisMAC had all but been retired. My use of KisMAC changed when I switched from a MacBook Pro to a MacBook Air recently. (As an aside, the move from HDD to SSD is like the move from SD to HD television: I'll never go back.) Though I now have to keep my iTunes library stored on an external drive due to my scant 64 GB of disk space, the MacBook Air's AirPort drivers now support Monitor mode. (As another aside, I've been told that some newer and older MacBook Pros had AirPort drivers that supported Monitor mode, but I could never get it to work with the non-unibody model I bought back in June, 2008.) Since the MacBook Air boasts an 802.11n (that's MIMO-802.11n, not aniPad-esque 65 Mbps 802.11n) AirPort interface that can be placed in Monitor mode, I can now capture 802.11n traffic with the free combination of KisMAC and Wireshark. See:
08/11/2012
Sniff WiFi
Pgina 49 de 49
Now, notice that there are some limitations here. The supported rates read as if this were an 802.11b/g capture. In addition, KisMAC remains a 2.4 GHz-only sniffing tool, so if you need to analyze a full throttle (meaning 5 GHz) 802.11n network, you're out of luck. Still, it's nice to able to see how the Retrys are looking on my home WiFi network without having to boot into Windows or run a virtual machine. (Below 0.01% Retry bytes, if you're curious. Also, reason #177 why every 2.4 GHz WLAN should have a RTS Threshold of 0.) As always, for professional analysis I'm still avoiding Mac OS X, but if you're just looking to play around with some WiFi frame captures on your Mac, the KisMAC/Wireshark combination has become much more useful.
08/11/2012

Default

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Default

Uploaded by

Copyright:

Available Formats

Sniff WiFi

What's New In the WiFi for iPhone 5

Testing Mobility with OmniPeek: Isolating the Station's Traffic

Mighty iPhone Power Ranges

Retry frames sent by the AP to the iPhone: 155 (9.4%)

Frames sent by the iPhone to the AP: 1973

Retry frames sent by the iPhone to the AP: 329 (16.7%)

How to set up OmniPeek to analyze Phones on a WLAN

Windows and Wireshark: Still Searching for the (Free) Answer

Monitor mode 802.11a/b/g/n

Preservation of physical layer information (channel, rate and RSSI)

WiPry Spectrum is Great, but it's All About the iPad

Using AirMagnet to Analyze Voice Over WiFi

Skype from the iPhone (MAC address ending in F5:C1):

How Do I Know (If It Really Links Me)?

One Card to Rule Them All

Tell Me Why's, Tell Me Sweet Little Why's

And a one, and a four, and a eight, and a 'leven...

never be widely adopted can attest).

Time To Talk Chanalyzer

Bad Medicine: Roaming and Sniffers

Three Things I Like: AirMagnet WiFi Analyzer

Get Personal, Gogo

Chiggity-Check Your Phone (With a Sniffer)

WiFi In The Arena

Setting Data Rates - Just (Don't) Do It.

If It Ain't Broke, Fix It

KisMAC and AirPort - A Match Made in Heaven (Almost)

You might also like