Just another site

Archive for the ‘WiFi sniffing’ Category

Three Simple Ways to Boost Your WiFi

with 2 comments

Some days you wake up and say to yourself, “how can I be more like Buzzfeed?”  Buzzfeed is popular and beloved and has an office across the street from a great Mexican restaurant.  I have a few friends and wonderful parents, but I can barely cook a taco.  

What is it that I’m missing (besides venture money, a flock of ambitious MBAs and universal scorn from the intelligentsia)?  Lists!  That’s what I’m missing.  Hit-trawling, crowd-pleasing lists!

So here it is: the first in what hopefully will be a series of one.  A list of Three Simple Ways to Boost Your WiFi.  #LOL #cute #OMG #trashy

1) Add an 802.11n/ac USB adapter to old 802.11a/b/g laptops and desktops.

Some folks in the WLAN business like to use the term “5G” to refer to 802.11ac, but I refer to 802.11a/b/g as 1st generation WiFi and 802.11n/ac as 2nd generation WiFi.  The reason I do that is because big improvements to power consumption, receive sensitivity and channel bonding are available in almost all 802.11n and 802.11ac radios.

Smartphones, tablets and single-function terminals may be unable to support external WiFi adapters, but laptops and desktops have USB ports.  A small, low-cost, dual-band 2nd gen WiFi USB adapter like the Linksys AE6000 has worked well for me.  I’ve used it to give devices 5 GHz support (when the internal WiFi is 802.11b/g/n only) and to eliminate 802.11a/b/g associations that can slow down 2.4 GHz channels.

2) Use an external directional antenna on some APs.

Maybe you have an area where you can’t drop a Cat6 cable.  Maybe you want to make it so your client/stations don’t have to roam so often.  Maybe you want to divide up a high-density area.  Whether it’s one of those reasons or something else, external directional antennas can solve certain radio frequency problems.

Access points with internal antennas are simpler to install.  They also are often easier to use when planning and surveying, because experienced WiFi folks tend to be more familiar with them.  I’m not advocating that every AP for every installation use an external directional antenna, but if the coverage you need needs to spread out in one direction, then give external antennas a look.

3) Use a protocol analyzer.

Alert the press!  “WiFi Sniffing Blogger Advocates WiFi Sniffing”

Let’s tighten up this third rule, then.

3) Use a protocol analyzer instead of a spectrum analyzer or site survey utility.

Protocol analyzers tend to be the least popular troubleshooting tool.  They are more difficult to understand than spectrum analyzers, more expensive than discovery software and look less flashy than site survey utilities.  But they are better! (at least in my opinion)

Protocol analyzers are better than discovery software because they tell you more.  inSSIDer will allow you to see APs, channels and standards, but sniffers like WildPackets OmniPeek show client/stations and frames (packets) as well.  Discovery software can’t do that.

Spectrum analyzers like Metageek WiSpy/Chanalyzer are attractive because they show you all RF activity over a range of frequencies.  They are great tools.  But I believe that they are best as a backup to a protocol analyzer rather than a primary troubleshooting tool.  Protocol analyzers like Fluke AirMagnet WiFi Analyzer offer more detail about which specific WiFi devices are generating activity on the channel and how much harm that activity might be causing.

Site survey tools like Tamograph have a wider audience than protocol analyzers and it’s understandable why.  Reading a floorplan with color coded signal areas is a lot easier than reading a bunch of arcane statistics like data rates and Retry percentages.  But it’s also less specific.  Seeing that signal is strong/weak or noise is high/low or APs are sparse/saturated is nice, but it may fail to allow you to burrow down to the essential issue that is causing a WiFi problem.  Viewing device-by-device information in a protocol analyzer may be tedious at times, but it offers more salient information.

So there you have it.  Three things to try some time on your WiFi.  They might help you turn a frustrating deployment into something that runs smoothly.

If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoins to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

Thank you.


Written by sniffwifi

February 11, 2014 at 1:01 am

A Choice of Filters

with 5 comments

People who do WLAN analysis agree that filtering is a part of sniffing WiFi frames/packets.  More information can be extracted from captures when the focus is on one AP or station or protocol (or a combination of same).  Where people disagree is on which type of filtering is best: capture filters or display filters?  Yours truly is a capture filter man, and some iPhone analysis was a reminder why.

Filtering 802.11 captures is covered pretty well in the CWAP Study Guide (of which I am a co-author).  A capture filter extracts frames before they are captured.  The only frames captured are the ones that match the filter.  A display filter extracts frames after they are captured.  Every frame is captured.  Then the filter is applied so that only frames matching the filter are shown in the protocol analyzer.  To use the example of a filter on my iPhone, if a capture filter were used then all of the frames from all of the other stations on my iPhone’s channel would be lost.  Using a display filter, on the other hand, would mean that everything is captured.  Nothing is lost.  The filter for my iPhone would be applied after the capture has been done, thus allowing frames from other stations to be analyzed later.
The CWAP Study Guide takes a neutral position on WiFi capture filters, but the CWAP course written by Marcus Burton is friendlier to display filters.  The rationale make sense on the surface: with a display filter nothing is lost.  If an iPhone is being analyzed and the iPhone’s frames appear to betray a congestion problem, the display filter can be removed and frames from other stations or APs can be examined.  If a capture filter is used, then that moment of congestion may have been lost.  Those uncaptured frames can never be examined.
There is a down side to using display filters, especially in a congested area: the lack of real-time analysis.  It can be tremendously valuable to be able to watching frames as they are being captured.  If you know what WiFi should look like, then you may be able to identify cases where the WiFi is having problems.  (That’s how I fingered the APs as the culprit when investigating that iPhone VoIP problem that I blogged about a while back.  I watched the frames show up in OmniPeek in real time and saw a stream of Retrys.)  
In general, the best way to filter will depend on your level of expertise.  If you are relative new to sniffing WiFi, then it’s probably best to use display filters.  You probably won’t know what to look for in real time, so it will be best to keep all captured frames.  Once you become an expert, then switching to capture filters is usually better.  The ability to correlate real world, real time behavior (What app is running now?  Is the tablet moving now?  Is the user actively using her device now?) with that scrolling trace of captured frames/packets is often valuable in identifying what is really going on.

If you like my blog, you can support it by shopping through my Amazon link.  Same Amazon store and prices, but I get a kickback.  Thank you.

Written by sniffwifi

January 30, 2014 at 6:09 pm

Sniffophobia Is Alive and Well

leave a comment »

Fear not your sniffers, dear WiFi folk.  For they are your path to the truth.

I had a conference call today and the topic of carrier devices (smartphones, 3G/4G enabled tablets, etc.) on Wi-Fi networks came up.  The person on the other end needed to make sure that his WiFi devices were optimized for a variety of different WLAN infrastructures.
My first reaction (as is my first reaction to most WiFi related topics) was to sniff.  First set up the infrastructure.  Then use the device (which could mean connecting, roaming or running an app).  Then sniff what’s happening.  
His reaction to my sniffing idea was pretty negative.  Their testing procedures are basically trial & error.  Set up the WLAN, then connect the device and then document what the user experience is.  If the user experience stinks, then make a change.  He was a sniffophobe.
I get why people are sniffophobes.  WiFi sniffers can be expensive and difficult to learn.  The idea that you’re going to have to train a large group of people to understand sniffing software before you even run your first test may seem daunting.
Sniffers are worth it because actions speak louder than words.  The “words” of a device are its GUI.  The “actions” of a device are its WiFi frames.  Sniffing frames reveals the truth.  If you device is too sticky or too slow or too jumpy or too whatever, then those WiFi frames will usually reveal it.  If you don’t have those frames, then you might be seeing a problem that is caused by something that you are unaware of.
WiFi sniffing is a specialized skill.  But for the people who really need to know details on how a device works or why a connection is unstable or if performance will hold up under stress, sniffing is worth it.  Try to avoid letting sniffophobia keep you from getting the information you need.

Written by sniffwifi

August 22, 2013 at 7:43 pm

Worthless Capture, Part II (Or, "Why I Need To Buy A MacBook Pro")

with 2 comments

A year ago yours truly wrote about the importance of device location when capturing Wi-Fi frames in a post titled, “Worthless Capture“.  Well, recently another Wi-Fi sniffing bugaboo has become more prevalent: devices that lack the physical capability to capture a  data frames.

This whole problem really stems from 802.11n.  As many people (including the author) found out when the iPad was released in 2010, not all 802.11n devices have the same capabilities.  That is an annoyance to consumers, but it’s downright dangerous to Wi-Fi professionals.  Most Wi-Fi networks require sniffing at some point (for surveying, for event preparation, for troubleshooting, etc.), but most Wi-Fi sniffing devices are incapable of sniffing high rate data frames.

One more time: Most Wi-Fi sniffing devices are incapable of sniffing high rate data frames.

The Linksys WUSB600N, which yours truly uses to sniff with WildPackets OmniPeek?   Only 2 radio chains (a radio chain is a transceiver/antenna pair), so no 3 stream spatial multiplexing (which is required for rates above 300 Mbps) .

The D-Link DWA-160, which is one of the few adapters that works with OmniPeek, Fluke AirMagnet WiFi Analyzer and the Linux version of Wireshark?  Only 2 radio chains.  (Same for the Ubiquiti SR71-USB, which has the same chipset as the DWA-160 and supports external antennas.)

AirPcap NX, which is the only way to get a monitor mode capture with the Windows version of Wireshark?  Also only 2 radio chains.

Basically, if you want to capture high rate data frames with an external Wi-Fi adapter, you’re [excrement] out of luck.  At least most of the time.

What can you use to sniff Wi-Fi frames that use 3 stream spatial multiplexing?

Why, a MacBook Pro (not Air).  The MacBook Pro (like all Mac OS X 10.7 or 10.8 devices) has the Wi-Fi Diagnostics utility that supports monitor mode capture through the built-in Wi-Fi interface.  And the MacBook Pro’s built-in Wi-Fi interface has 3 radio chains.  So the bottom line is that I need to get me a MacBook Pro, otherwise I’ll continue to miss valuable frames when 3 stream data frames go through the air.

It should be noted that a limited number of devices support 450 Mbps Wi-Fi (which is what 3 stream spatial multiplexing maxes out at), so you may not need a 3 stream capture device.  iPhones (and other smartphones), iPads (and other tablets), MacBook Airs, netbooks, eReaders, bar code scanners and point-of-sale terminals all have built-in Wi-Fi adapters with only 1 or 2 radio chains.  The next Sniff WiFi blog post will cover how you can check to see if you actually need to capture using a 3 radio chain adapter.

Written by sniffwifi

April 2, 2013 at 9:24 pm

Sniff Like Silver

leave a comment »

Sometimes I dream
That he is me
You’ve got to see that’s how I dream to be
The dream I riff, the dream I sniff
Like Nate
I want to be like Nate (Silver)

Much has been made of the increased emphasis on statistical analysis, especially in the wake of New York Times blogger Nate Silver correctly predicting the electoral results for all 50 states in the recent United States presidential election.  Can analytics be applied to WLANs?  Of course they can.  It’s just a matter of sniffing the right stuff.

There are a lot of bad WiFi networks out there.

There.  I said it.  It’s out there and I can’t take it back.  I see a lot of Wi-Fi in my travels.  Almost all of it could be improved upon and much of it seems like it was installed by folks with little understanding of how 802.11 networks work.

So, what do we do to fix it?

We can have best practices.  We can finally ditch automatic RF controls.  (Please, people.  If you haven’t head yet, you want to set your 2.4 GHz channels to 1, 6 and 11 only and you want to keep your AP transmit power between 12 and 15 dBm.)  We can embrace directional antennas.  We can stop thinking that the solution to poor client/station connectivity is to place another AP nearby.  But what does that solve?  Are we really getting to the core of the problem, or are we just playing Whack-A-Mole?  (It’s a fun children’s game where you use a foam hammer to hit Moles that pop up, but whenever you whack one mole, another is certain to surface.)

If you really want to improve WiFi, you need to know how WiFi works.  The Boston Red Sox (gosh I hate the Red Sox so this next part is really, really, really painful to write) studied how baseball works, and they went and signed David Ortiz.  (Who was RELEASED by the Twins!  Hahahaha!  Reveling in the Twins’ incompetence is almost enough to make up for having to praise the Red Sox.)  They picked up Keith Foulke and Kevin Millar and Curt Schilling.  They analyzed how baseball works (in their case, that meant looking at historical statistics in an attempt to identify what statistics tended to identify players who contribute to winning teams) and they applied what they learned when building two World Series champion baseball teams.

So we need to know how WiFi works.  Great.  Now how do we do that?

Part of knowing WiFi is understanding the 802.11 standard.  (WARNING: shameless self-promotion coming)  If you are unfamiliar with the standard, a great place to start is the CWNA Study Guide and a great place to finish is the CWAP Study Guide, which I am a co-author of.  (See, I told you this would be disgusting self-promotion.)

The other part of knowing WiFi is understanding how your devices work.  Not just the APs.  The client/stations.  You want to figure out how your iPads, iPhones, Kindles and Blackberrys are going to act.  What will my iPad do when it wakes from sleep?  When I enable the WiFi radio?  When I put it to sleep?  When I open the Twitter app?  When I download the Wall Street Journal?

Nobody has the time to sniff every possible activity that every possible device could possibly endeavor.  But we can sniff some of it.  If I work at a university, I can sure as heck see what iPads do when they go to sleep and wake from sleep, because that will probably happen thousands of times per day on my campus.  If I work at a hospital, I can run the Andoid app that some of my doctors use to view doctor-y stuff.

To engage in WiFi client/station analytics, one should really use a professional tool like WildPackets OmniPeek, but you can do this stuff with free tools like Wireshark.  For example:

If I have a laptop or desktop running Mac OS X, I can hold the [Alt] key while clicking the signal bars and then select Open Wi-Fi Diagnostics.  I’ll get a screen that looks like this:

I can then select Capture Network Traffic and click Continue.  That takes me to this screen:
To sniff WiFi properly, one needs to be in Monitor Mode (NOT promiscuous mode).  To get Wi-Fi Diagnostics to use Monitor Mode, I select Capture all data from all nearby networks and then I select a specific channel.  (The office I’m working from today is using channel 2 and that’s just silly but that’s another story for another blog post.)
Once I have set up a Monitor Mode capture, I can then click Start Capturing.  From there, I just do what I would normally do.  I put my iPad to sleep, I woke it up, I turned on airplane mode, I turned on and off the WiFi radio and I ran the Twitter app (say hello to me on Twitter sometime at @Ben_SniffWiFi).
After you finish capturing the Wi-Fi Diagnostics application will zip up all of your diagnostics information and give you a .pcap file like so:
Open that file and, voila!, you have a Monitor Mode capture that you can use to analyze your WiFi client/station’s behavior.
Now, as any person who embraces analytics will tell you, gathering the data is the easy part.  What separates the Red Sox (grrr!  Hate to give them credit) from the Twins (hah hah!  Brewers rule and you know it) is the ability to understand which parts of the data are useful and which are not.  And that, my dear readers, is a topic for another time and place (and maybe, a blog post).

Written by sniffwifi

January 3, 2013 at 7:50 pm