sniffwifi

Just another WordPress.com site

Archive for the ‘Uncategorized’ Category

Ask Me Anything

leave a comment »

Written by sniffwifi

October 15, 2013 at 12:52 am

Posted in Uncategorized

My Favorite Part of AirMagnet

leave a comment »

It’s Columbus Day!  A holiday that many of us heard of, a few of us object to and some of us don’t get the day off for.  Let’s call it a half-holiday.

Yours truly is going to celebrate the day by celebrating one of my favorite sniffers, Fluke AirMagnet WiFi Analyzer.  Due to it being half-holiday, this will be a half-efforted blog post.  So no links and no graphics.  Just a little talk about my favorite part of that fine sniffer.

AirMagnet WiFi Analyzer from Fluke Networks has been around for a long, long time (at least in WiFi years) and it continues to be one of the top WiFi sniffing options available.  I probably like WildPackets OmniPeek a little bit more because of its ease in manipulating frame traces, but AirMagnet (as I’ll call Fluke AirMagnet WiFi Analyzer from here on out) has long been the best option for solving the vast majority of in-the-field WiFi problems.

Last week I got to introduce AirMagnet to a few folks and it struck me that even though it is more intuitive than the average WiFi sniffer, it is still challenging to a new user.  So I figured I’d go through a quick overview of what I like best about it.

My favorite part of AirMagnet is that it allows you to quickly drill down from Channel to AP to Station when viewing those most important of WiFi statistics: the data rates and the Retry percentages.  (Low data rates and high Retry percentages are two big wastes of channel time, which is what makes those statistics important.)  The person doing the sniffing can take his (or her, but for simplicity’s sake I’ll honor the Y chromosome in this blog post) AirMagnet laptop or tablet to the location of the problem and quickly gauge whether channel time is being wasted.  Are the channel statistics bad?  If yes, then is one AP or another especially bad?  Once a bad AP is identified, then are there specific stations that seem to be dragging things down for everyone else?

What sets AirMagnet apart is the automatic filtering of captured frames when a Channel, AP or Station is selected.  If someone navigates to the Channel screen and clicks “6”, then only channel 6 frames are captured.  If someone then navigates to the Infrastructure screen and clicks on an AP that is using channel 6, the only statistics displayed are from frames that were going to or from that AP.  Single station statistics are also filtered if one station is clicked on in the Infrastructure screen.

All of this may sound like mumbo-jumbo if you are unfamiliar with AirMagnet.  And in the near future yours truly will do a non-holiday blog post that includes all of the links and graphics that may help this come to life.  But if you are already an AirMagnet user on this fine Columbus Day, then maybe you can use my favorite part of AirMagnet.

Written by sniffwifi

October 14, 2013 at 7:50 pm

Posted in Uncategorized

We Rally ‘Round The Sniffer (With A Pocket Full Of Cards)

leave a comment »

Ahh, the good ol’ days.  The days when USC was beating UCLA by 50 points, AirTran was flying nonstops from LAX to Milwaukee and WiFi sniffing folks only had to carry one USB card for 802.11 protocol analysis.  Those days are gone, my friends.  It’s time to update which cards we need for which applications.

December of 2011 was a time yours truly looks back on with fond memories for the reasons cited above.  In the wireless world, the good news was that WildPackets OmniPeek had begun supporting monitor mode capture from Atheros-based 802.11a/b/g/n chipsets, thus allowing one USB adapter to be used for any good WiFi sniffing app.

Things change, and when WLAN infrastructure vendors began selling APs that support three-stream spatial multiplexing (thus rendering high rate data frames un-sniffable to the D-Link DWA-160 802.11a/b/g/n USB adapter), the handwriting was on the wall.  The halcyon days of only needing one USB adapter for wireless protocol analysis were numbered.  For a while most client/station devices continued to use one-stream or two-stream spatial multiplexing, thus keeping my old USB friend relevant.

Today, too many devices use three-stream spatial multiplexing for it to be ignored.  If you try to run a protocol analyzer using an adapter that only supports up to two streams, you may end up with a worthless capture.

We can capture three-stream data if we have a three-stream adapter that is compatible with our Wi-Fi sniffing software, but there’s a problem.  No single USB adapter works will every application.  If you want to be ready to use any protocol analyzer, you’ll have to carry around a pocket full of capture devices.

It is doubtful that you come to this-a-here blog [DiCaprio-in-Django-Unchained voice] to see me whine about changin’ tech-nol-gy (see, with a ludicrous Southern Gentleman accent, I can both add syllables and subtract).  So here, then are the current top options for getting a three-stream wireless data capture into a quality Wi-Fi sniffer:

  • WildPackets OmniPeek: Still my favorite Wi-Fi sniffer, and now it has a simple option for capturing 450 Mbps data.  The OmniWiFi adapter is a dual-band 802.11a/b/g/n USB adapter that supports three-stream capture.  
  • Fluke AirMagnet WiFi Analyzer: AirMagnet is still great software, but the capture options stink.  You’re best bet is a laptop with an Intel 6300 internal Wi-Fi interface.  The problem is that rules out virtual machines (since USB adapters are available in virtual machines, but internal adapters are not) and Apple laptops (which use a Broadcom-based Wi-Fi interface).
  • Wireshark for Mac OS X: You can capture using the internal three-stream interface on a MacBook Pro (not MacBook Air) using Wi-Fi Diagnostics and open the captured .pcap file in Wireshark.
And this is even leaving out Wireshark for Linux, which works with the old DWA-160.  I’m unsure if there is a three-stream USB adapter that has monitor mode drivers for Linux Wireshark, but if anyone knows of one leave a comment or email me.
The hard truth is that this re-scattering of capture capabilities is annoying to a person like me, but may not matter as much to a WLAN administrator.  If you’re just going to use one WiFi sniffer, then you can just choose the appropriate card option and go with it.


Written by sniffwifi

May 10, 2013 at 5:02 am

Posted in Uncategorized

Roam Like No Other

leave a comment »

Ahh, mobility.  The bane of my (and many others’) wireless humanity.  Wherefore art thou be so fickle?  Different devices roam differently.  Different apps make the same device roam differently.  And sometimes it seems that the same device and same app will roam differently depending on the situation.  So what can we do about it?  And, perhaps more importantly, how can a WiFi sniffer help?


Let’s face it, folks: nomadic WiFi is easy (comparatively).  At a university, you have students that want WiFi for their iPads in dorms, classrooms, labs, the basketball arena and at lunch.  But rarely in between.  A student using an iPad nomadically is just plain easier to support than a doctor who wants to pull up an X-Ray while she’s moving or a retail manager that needs to see a picture from the Band of Outsiders fall collection while she walks over from the jewelry section.
Compounding the mobility problem is that the iPad may not be your only device.  There’s an old saying that goes, “if the Vocera works, then the WiFi works,” and usually that is true.  But what if it isn’t.
The solution to supporting mobility is often infrastructure design, but to design a proper infrastructure, we need to know how a device behaves.  That means WiFi sniffing.  I always like to say that if Actions speak louder than Words, then a device’s 802.11 frames are its actions while the WiFi client/connection utility is its words.
So if we’re going to use a WiFi sniffer to get a gauge of how our devices behave, then what do we look for?  
I like to start by tracking the association and reassociation behavior of a client device.  Start a capture using WildPackets OmniPeek or (if you can afford to waste time so that you can save a little money) Wireshark on the channel of a nearby AP.  Then go away from your AP so that the device roams on to the channel that you are capturing on.  Ideally, it is best to do multiple captures.  For example, here’s what you might do if you had to support iPad’s at a hospital:
  • Turn the iPad’s screen on and open the Mail app, then move to the nearby AP.
  • Turn the iPad’s screen off and move to the nearby AP, then turn the screen on.
  • Open whatever medical apps are used and move to the nearby AP while using those apps.
Check out your captures and see if you notice any patterns.  Does the iPad associate or reassociate when it moves with the screen off?  Does the signal strength or SNR that the reassociation initiates at vary depending on whether a medical app is running?  Does the iPad send probe request frames for a significant amount of time before or after reassociation?  The answers to these questions could change your perspective on what the best infrastructure design is.
In the near future I plan to blog a bit more about mobility, including with screenshots of WiFi sniffing applications like WildPackets OmniPeek, Wireshark and Fluke AirMagnet WiFi Analyzer.  Check back again or subscribe to Sniff WiFi by mousing over the little panel on the right hand side of the screen and clicking the Subscribe button.

Written by sniffwifi

March 13, 2013 at 7:30 pm

Posted in Uncategorized

Back To Basics (Again)

with 2 comments

The hot topic in WiFi nowadays is high density (HD), and for good reason.  It seems you can’t swing a dead cat anymore without hitting some place (concert hall, convention center, tourist trap) where there’s an attempt to offload cell phone data onto a WiFi network.  The most interesting thing about HD WiFi to yours truly is that it’s the same fundamentals we’ve always known about, just recycled.

If you were one of the lucky (unlucky?) ones to work in WiFi during its more formative years, you may have been taught certain basic concepts about WiFi.  For the author, fond memories still remain of sitting an Enterprise WLAN Administration course way back in 2003 (taught by noted Massachusetts Yankees fan David Westcott) as part of my preparation for the certified wireless network administrator (CWNA) exam.

What did Mr. Westcott teach us lo these many years ago?

Plan out your space alternating between channels 1, 6 and 11 in the 2.4 GHz band.

If APs are spaced too close together, adjacent channel pairs (1 & 6 or 6 & 11) will interfere.

Keep the transmit power of your APs near 30 mW (which was the typical transmit power of an 802.11b PC card).

Use directional antennas whenever you can.

Use 802.11a in high usage areas because the 5 GHz band has more channels.

Do any of these things sound familiar?  Does this nine-year old information resonate today?

If you have designed, deployed, managed or troubleshot a HD WiFi installation, these rules should sound familiar.  Some of the details may have changed (stations that dynamically adjust transmit power; more 5 GHz channels; 40 MHz channel options in 802.11n), but the basics are the same as they always were.

During the Dark Ages of WiFi (I just watched The Name Of The Rose, so I’ll choose that term instead of “Medieval WiFi”), just about everyone everywhere was trying to beat the basics.

Remember adaptive transmit power on APs?

Remember automatic channel selection?

Remember trying to use channels besides 1, 6 and 11?

Remember co-locating 2.4 GHz AP radios close to each other, or even in the same box?

Remember APs without external antenna interfaces?

Actually, all of these things still exist.  And they all are still used, and — in some unfortunate cases — these things are used for HD WiFi.  None of them should be* (save auto channel selection, which still works in the 5 GHz band), but when WiFi folks fail to learn WiFi basics, these things happen.

There was one other thing that Mr. Westcott taught us during that August in Pasadena so long ago.  He taught us the importance of analysis.  He taught us that if you can’t see what’s going through the air, you’ll have a tough time getting your infrastructure optimized.  That basic of WiFi still applies, too.  Learn your sniffers, folks.  Get familiar with WildPackets OmniPeek or Fluke AirMagnet WiFi Analyzer (or if you prefer to save a little bit of money and waste a whole lot of time, Wireshark) and get yourself a good portable spectrum analyzer (I like Metageek Chanalyzer with WiSpy DBx) to go with it.

*If you’re supporting low density, non-mobile WiFi, then by all means use those outdated WiFi design principles and features.  Just keep that crap away from sports facilities.  Yes, I am there to watch the Milwaukee Bucks, but I also would like to set my DVR from my seat if I forgot to record The Mindy Project.

Written by sniffwifi

November 30, 2012 at 9:16 pm

Posted in Uncategorized

What’s New In the WiFi for iPhone 5

leave a comment »

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:

  • 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.
  • 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.
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.

Written by sniffwifi

September 19, 2012 at 8:18 pm

Posted in Uncategorized

Testing Mobility with OmniPeek: Isolating the Station’s Traffic

with 2 comments

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×2: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 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?
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.

Written by sniffwifi

August 9, 2012 at 12:51 am

Posted in Uncategorized