sniffwifi

Just another WordPress.com site

Archive for the ‘OmniPeek’ Category

An Android Change for the Better (Maybe)

with one comment

Chatty smartphones have been an issue for years.  Whether you’re concerned with security or performance (or both), the amount of Probing being done by unconnected iPhones, Galaxies and the like has been worrisome.  

Today, things have changed.  Smartphones don’t Probe as much.  This is probably for the better, but there could be a catch.

I’m an Apple guy.  Even when I was using PCs in college (things were different back in the 90’s, I tell ya), it was always because they were free.  Once I finally had to buy a computer, I went straight to the very first iBook in 2001.  I own an iPod, iPad, iPhone and MacBook Air.  My next computing purchase will probably be an iMac (to better record those promised-but-not-yet-delivered online training videos on WiFi that I touted six months ago).  So, I like the company.  And I like bashing its competitors sometimes.  (Not my most magnanimous trait, but nobody’s perfect.)

I liked pointing out that Google’s Android operating system had worst wireless security than Apple’s iOS.  Including:

-Apple requires server certificate validation by default for WPA2 Enterprise authentications (even if it is user-controlled), while Android does not.

-Apple smartphones and tablets Probe only for hidden SSIDs, like so:

(That’s a Probe Request filter in WildPackets OmniPeek.  The SSIDs that you see in those Probe Requests are all hidden SSIDs, with the exception of “Google Starbucks”.  Read on to learn why my local Starbucks’ SSID is showing up in there.)

-Android smartphones and tablets Probe for all saved SSIDs.

At least, they used to.

I was demonstrating the inferiority of Android’s wireless security recently when I learned something new.  They’re not inferior anymore.  Some time recently (or, at least in between the time of my previous Android OS update and my recent update to Android 4.2.2) Google changed Android devices’ wireless behavior to match that of Apple’s.  Android smartphones and tablets started Probing for hidden SSIDs and staying quiet for broadcasting SSIDs, like so:

Of course, I was ambivalent.  GOOD that Android devices’ wireless security has improved!  BAD that I can no longer tout Apple devices’ wireless security superiority in comparison!

So, there you go.  A begrudging admission that Android’s wireless security has been shorn up to match the level of Apple’s.  (In fact, Android’s wireless security is even considered superior in some circles because Android has an option to eliminate user-based verification of server certificates during WPA2 Enterprise authentication.  But we don’t need to discuss that right now.)

But… (and, there’s always a But)

…this may actually be bad for mobility.

Apple iOS and Android devices don’t Probe unless they connect to a hidden SSID.  Nice.  But, let’s take a step back.  Why is Probing in the IEEE 802.11 standard to begin with?

Probing (a process where a client/station device sends a Probe Request frame in order to elicit a Probe Response frame from an access point [AP]) is in the 802.11 standard to facilitate mobility.  Roaming.  Handoff.  Whatever you want to call it when someone moves out of the range of one AP and into the range of another.  Probing also helps devices connect more quickly when starting/waking up and can help devices find an AP in areas that are congested with neighboring WiFi devices and APs.

So, Probing can be a good thing.  Especially for mobile devices in crowded areas.  And now Android devices (like Apple iOS devices) do less of it.

If you say to yourself, “gosh, this iPhone/iPad/Galaxy/HTC One seems to really crap out when I go to a crowded place” (like the Starbucks by my place in Los Angeles), then you might want to ADD Probing to your device.  How?  By tricking your device into thinking that the SSID is hidden.

That’s what I did at my local Starbucks.  My phone sends out these Probe Requests…

…because I manually added the “Google Starbucks” SSID to my phone.  Instead of tapping on “Google Starbucks”, I tapped Settings -> Wi-Fi -> Other… (ellipse in the GUI, not added by me) once I got in line for a Tall Skinny Peppermint Mocha, Hold The Whipped Cream and then typed in “Google Starbucks”.  I don’t know if it helps a whole heck of a lot (Starbucks still uses the darned Captive Portal, which will slow down any wireless connection), but it does optimize a couple of things.
In summary, Android’s move to Apple-like wireless behavior is good for security and overall channel performance.  But if your problems are mobility and speed of connectivity, then you might want to un-do what Android has done by adding your SSID manually.
***
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Advertisements

Written by sniffwifi

December 19, 2014 at 8:33 pm

I Have Seen the Future (of WiFi Sniffing), and It Is OmniPeek (on a Mac)

with 9 comments

Yours Truly has been worried about the future of WiFi sniffing.  Yours Truly worries about the people (they seem to prefer site surveyors) the software (AirMagnet has yet to support 802.11ac adapters) and the methods (WildPackets has been pushing AP-based capture).  To a person who believes that portable WiFi sniffing is essential for optimizing WiFi performance, it is all very disconcerting.  And yet, there is hope.  WiFi sniffing is ready to step into the 802.11ac/Internet of Everything era, and here is how it can be done.

WildPackets OmniPeek has long been the author’s favorite WiFi sniffer, but it only runs on Windows.  For years and years and years that was fine.  There were always a few Windows-compatible WiFi adapters that worked great with OmniPeek.  Now, however, WildPackets has gone in a different direction.  They are promoting WiFi sniffing via an AP (which often results in a worthless capture) and saying that they don’t expect USB-based capture to be viable for 802.11ac.

So, what to do?  OmniPeek only runs on Windows, but they’re not planning to support capture via Windows-compatible USB adapters.

The answer is to switch to a Mac and use virtualization software.  Here is what I did:

1) Buy a Mac

I prefer the MacBook Air because it is cheap, light and cool.  (Literally cool.  Meaning temperature.  The darned MacBook Pro gets too hot to place comfortably on your lap.)

2) Buy Parallels

Parallels is virtualization software and it runs seamlessly on a Mac.  Check out OmniPeek:

You can see the little Apple logo in the upper left, showing that I’m running Mac OS X as I run OmniPeek.
3) Capture in Wireless Diagnostics
I even made a video to show you how!  
In case the video is unclear, you hold down the alt/option before clicking the WiFi icon on the top menu bar.  Then you select “Wireless Diagnostics”, go to the “Window” menu, choose “Utilities”, click on “Frame Capture” and select your capture channel & bandwidth before clicking “Start”.  YOu click “Stop” when you’re done capturing.
4) Open the capture file into OmniPeek
In case the picture above is unclear, you go to the Desktop, right-click on your *.wcap capture file, select “Open With” and select OmniPeek.
5) That’s it!
The limitation of this method is that you’re unable to see live frames as they are captured.  Boo hoo.  (Actually, it’s more than boo hoo.  For certain tasks (like analyzing Probing behavior), not having access to a live capture is a real problem.  But for most tasks, analyzing a capture file after the actual WiFi sniffing is done is just fine.)
On a MacBook Air, the capture I open in OmniPeek is a two-stream, 802.11ac capture.  On a MacBook Pro, it would be a three-stream 802.11ac capture.  That means capturing on an Air will result in me missing data sent and received by a Pro.  Most 802.11a/b/g/n/ac devices will have all of their WiFi traffic captured just fine by an Air, however.
I am still hoping that someone creates a three-stream 802.11ac USB adapter that I can use for OmniPeek (or Fluke AirMagnet WiFi Analyzer, for that matter) capture, but in the meantime these steps will allow you to do useful, portable captures now and in the future.
***
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

Thank you.

Written by sniffwifi

April 23, 2014 at 7:01 pm

Sometimes, Two Plus Two Ain’t Four

leave a comment »

My love for WildPackets OmniPeek may be one of the few things in technology that exceeds my love for the iPhone…


Now that I’ve run off 20% of my audience, let’s talk about how the former can be used to figure out if the latter is causing a problem.

I have a lot of enemies in life, and I’m proud of that.  In my opinion, part of being an adult is recognizing who your enemies are.  UCLA football players are my enemy when they play college football.  Drivers who text while stopped at green lights are my enemy when I am running late.  (No comments from the peanut gallery on that one, GT Hill.)  And deductive reasoning is often my enemy when troubleshooting.
Deductive reasoning is oh so tantalizing.  It’s simple math; A + B = C.  The WLAN works (C) when VoFi handsets (B) connect to my APs (A).  If I switch out the VoFi handsets for SIP-based iPhones (thus changing the value of B) and the WLAN stops working, then the iPhones must be at fault.  Right?  Wrong.
Deductive reasoning only works if you eliminate all variables but one.  A switch from a VoFi handset to an iPhone is not the changing of one variable.  It is the changing of numerous variables.  The chipset changes.  The client utility changes.  The apps that run in the background change.  The SIP app changes. 
Another problem I have with deductive reasoning is that sometimes a device that we think is working really isn’t working.  That’s what was happening recently when I was doing some work on site at a health care provider.
The Problem

The health care provider had been using dedicated VoFi handsets for years.  Like many organizations, they decided to move away from dedicated voice devices and use a smartphone app instead.  In this case, it was an Avaya smartphone app running primarily on iPhone 5s.  
Once the iPhones started getting used, the WiFi folks at the health care provider immediately starting noticing problems.  Users were saying that the phones kept beeping.  Avaya said that the app will cause the phones to beep if the app gets disconnected.  It is a way to protect phone from being stolen or taken to locations where they’re not supposed to go.
The problem for the WiFi admins is that the phones were still connected when the beeping was happening.  Something was causing the iPhone to think it was disconnected when it really wasn’t.
Faulty Deductive Reasoning

The natural reaction of the WiFi admins was to blame the iPhones and/or Avaya.  The health care provider had a working VoFi solution.  They changed to iPhones and Avaya.  The solution stopped working.  The rest of the WiFi continued to work well, so the problem was thought to be the phones.

I was skeptical that the iPhones and the Avaya app were the problem right from the beginning.  iPhones have been blamed innumerable times over the years for problems that were actually the infrastructure’s fault.  What’s more, I tend to almost always blame the network.  My attitude is that networking (both wired and WiFi) is the business of support.  We don’t make money for the company.  We create infrastructure that allows saleswomen and craftsmen (see what I did there, ladies?) and executives to make money for the company.  If a user wants to use a certain device, we should try to make our infrastructure support that device.  (That is, assuming we want the company we work for to grow and be successful.)
OmniPeek to the Rescue

Armed with my natural skepticism of iPhone blame syndrome, I had the lead WiFi guy do an WildPackets OmniPeek capture with me.  (OmniPeek is the WiFi sniffer that he was already using.)  We set the capture to the channel of the nearest AP.  We associated the iPhone.  He made an received a call.
We then looked at the OmniPeek WiFi statistics (Summary -> 802.11 Analysis, for those of you OmniPeek users).  I noticed that the Retry percentages were astronomical.  Getting as high as 60% at their worst.  That told me that something was wrong.  During normal operation the WiFi channel was seeing Retry percentages well below 10%.
From the Summary screen of OmniPeek, we switched to the Packets screen to get more detail.  I turned on Auto Scroll (a little icon above the packets list that looks like a little padlock) and watched the packets come in while we repeated our iPhone test.  I kept my eye on the Flags column in my Packets window because I knew that Retry frames always caused a red colored “+” to show up in that column.
Sure enough, the next time the iPhone connected a whole slew of frames with a red “+” showed up in the Flags column.  I saw more than 5 consecutive HTTPS frames in a row all with the Retry flag and none of them were followed by acknowledgment (802.11 Ack) frames.

We Found a Problem, but Whose Fault is It?

Once we saw a flood of unacknowledged frames, we had to determine what the cause might be.  Was it the iPhone misbehaving?  A bad Avaya app?  Or the AP being unresponsive.

All of the Retry frames had the iPhone 5’s MAC address as the second address in the 802.11 header.  The second address is always the transmitter’s MAC address.  That meant that the iPhone was sending all of the frames that were failing.

After seeing that the iPhone was the device that was sending the failed data, I immediately began to suspect that the APs were the problem.  It is quite rare that a device will disconnect itself while sending a bunch of data at the same.  Remember, our initial problem was that we were getting a beeping sound that indicated a network disconnection.

Let’s Get Specific

Blaming the WiFi infrastructure for an iPhone problem is always satisfying (at least, if you’re an Apple loyalist like yours truly), but in order to get people to believe you it’s best to pile on the evidence.  My usual method is to try to find something logical.  Why would an AP just stop acknowledging iPhone data?  Why might I be using the same WiFi APs and controllers that have always worked fine with VoFi handsets and never see a problem that is the fault of the infrastructure?

I used OmniPeek to look inside the frame decodes for any unique properties of the unacknowledged frames.  I noticed that some of the problem data had the same WMM/QoS category in the QoS Control field: Background.  I immediately added the Decode column to the OmniPeek Packets screen, then selected the Traffic Identifier (TID) subfield within the QoS Control field of the 802.11 header.  In the Decode column of the OmniPeek Packets screen, whichever field or subfield selected in the frame decode below will be displayed.  So in my case, that meant that the Decode column displayed the TID for every frame.

Once I was able to easily see the TID for each captured data frame, I started quickly scrolling up and down through the capture.  Sure enough, I saw a consistent pattern.  Every time the iPhone sent a frame tagged with the Background TID to the access point, the access point would fail to send an acknowledgment in return.  We didn’t have time to identify which specific app within the phone was sending data tagged as “Background”, but at that point it was peripheral to the issue.  If an AP can’t handle Background traffic, then that AP is a potential problem that could spread beyond just iPhones and Avaya apps.

The Conclusion

The lead WiFi administrator was in the room with me looking at OmniPeek as we were investigating this iPhone disconnection problem (and, unfortunately, this is why I am unable to show screenshots of our OmniPeek captures).  He came into the day looking for an iPhone problem.  After an hour or so of using OmniPeek, he realized that the problem was his APs.  The fact that he was using 802.11a/b/g APs made things all the logical.  The AP vendor had mentioned to the lead WiFi admin that those old APs were no longer receiving firmware updates and that it could lead to problems.  Our little OmniPeek exercise convinced him that it was either time to upgrade or to look for a new vendor (and his current AP vendor shall go nameless in this blog post, because I like to avoid trashing vendors for hardware or software that is no longer kept up to date).

I am aware that I sometimes come across as too sniffer-centric.  I realize that some people find management software easier to access or spectrum analyzers easier to understand or discovery software easier to afford.  But there is a reason that I am such a zealot for WiFi sniffers.  They help me identify causes of the really difficult problems that plague so many high level wireless networks.

Written by sniffwifi

November 11, 2013 at 11:37 pm

Posted in iPhone 5, OmniPeek, VoFi

A Fish in the Desert: Chromecast, Sniffed

with 4 comments

It’s a rough world out there, folks.  The economy stinks (or, is great if you live in western North Dakota), finding love is harder than ever (or, easier than ever if you use online dating) and WiFi bandwidth is scarce (or, plentiful if you use the 5 GHz band).  Into this quagmire wades the Google Chromecast.  A cheap ($35 USD), little (about the size of an e-cigarette case) gadget that allows you to mirror your smartphone/tablet/computer screen to your television.  If you want to feel like a member of the 1% (at least, the top 1% of WiFi spectrum consumers), this is the gadget for you.

Reviews, tutorials and takes on Google’s Chromecast are plentiful, so let’s skip that.  On this blog we don’t care whether people like the gadget.  We care about what the gadget does to the WiFi.  Does it suck up bandwidth?  Is it chatty during down times?  Does it interfere with existing networks?

Let’s take the first question last (Charles Van Doren voice).  The Chromecast will interfere with existing networks, whether in a pre-working or working state.

When in a pre-working state, the Chromecast acts as an AP.  Initially the Chromecast will have a default name that it will use as an SSID.  (Though when I did my test I had already given it a name of “BenChromecast”.)  Being an AP may not be a problem in some cases, but in this case it may be.  The Chromecast is 2.4 GHz only, and it supports a maximum rate of 72.2 Mbps.  Not only is it taking up one of the three (or, four, if you are in the parts of the world that allow for 2.4 GHz channels 1-13) available channels, but it is doing so at a non-MIMO (and, thus, relatively low) rate.

The good news is that most Chromecast usage will not occur with the Chromecast in master mode (which just means “acting like an AP”).  Most of the time it will be in managed mode (which means “acting like a staiton”).
First about the transition from AP to station: in the frame capture it looked buggy.  The Chromecast is using two different MAC addresses; one when acting like an AP and another when acting as a client/station.  That is pretty normal.  When Windows devices use the hostednetwork function, their WiFi radios use separate MAC addresses for AP and client/station activity.  The problem with the Chromecast is that it appeared to be unable to stop acting as an AP as long as a client/station remained associated to it.  
Over and over in my captures, I saw the Chromecast trying to deauthenticate my iPad (3rd gen):
By this point my Chromecast was already acting as a client/station (using a different MAC address) to my home wireless router.  What seemed to be happening (and when I say, “seemed to be,” that’s carny for “I saw this, but I need to investigate further before I make a conclusion) was that my iPad was stubbornly trying to stay associated to the Chromecast’s BSS, and the Chromecast wouldn’t shut down the BSS until the iPad got off.  I’m guessing that it has something to do with running the Chromecast app on the iPad.
The long and the short of the Chromecast stubbornly acting like an AP is that it could lead to congestion of the airspace.  If someone plugs in a Chromecast, that Chromecast is just going to keep acting like an AP all day, at least until the Chromecast user disassociates from the SSID that Chromecast creates.
A bigger problem with the Chromecast acting like a client/station is that it is chatty.  While idle, I saw Chromecast using between 200 kbps (on about 2,000 frames) and 400 kbps (on about 4,500 frames).  That may not seem like much, but it’s still 40 microseconds of channel time for each frame’s physical header on top of the channel time being take up by actual data.  Trust me.  That’s a lot of wasted channel time for a WiFi-based app.
Once mirroring began, the Chromecast got really active on the channel.  The Chromecast is designed to mirror a high quality video stream, so I was prepared to see lots of data.  (And the fact that my Chromecast mirror was from my WiFi laptop to my WiFi Chromecast meant that double the number of frames would be needed for a wireless-to-wireless transmission.)  Still, what I saw surprised me:
Look at that!  71,452,996 bytes of data in one minute.  That’s 571,623,968 bits of data.  Even if you figure an average data rate of 30 Mbps (which may be high for a non-MIMO, 2.4 GHz only device) and then add 2.62 seconds for the physical layer headers (which is40 microseconds for each of the 65,497 frames), that means that almost 23 seconds of the 61 seconds of total available channel time was used by this one Chromecast stream.
I guess for a home user, having over 37% of your WiFi bandwidth taken up by a Chromecast is fine.  If you don’t have neighbors that are close enough to interfere with your WiFi, then your other devices will probably be able to survive just fine on the other 63% of channel time that the Chromecast isn’t using.  But gosh darn, if the Chromecast ever gets really, really popular in dense apartment complexes or office spaces, it’s hard to see where the channel space will come from.
Given how much WiFi channel time the Chromecast needs, the fact that it is a 2.4 GHz device makes me wonder.  It makes me wonder if there are larger problems afoot.  I have a Cisco-Linksys WUSB600Nv2 802.11a/b/g/n USB adapter (Ralink chipset) that absolutely stinks when connected to a 5 GHz WiFi network.  Maybe Google either is unable to find good 5 GHz silicon or is too cheap to do it for a $35 USD device.
Whatever the reason for Chromecast’s restriction to the 2.4 GHz band, the bottom line is that it is a bandwidth hog in a land of scarce bandwidth.  A fish in the desert, so to speak.  And if your WiFi isn’t an oasis where 2.4 GHz channels are plentiful and untouched by neighbors, then you might want to think twice before embracing Chromecast.  

Written by sniffwifi

September 26, 2013 at 8:17 pm

Can Single Stream Sniffing Work?

with one comment

A bunch of WiFi vendors made presentations at the Wireless Field Day events a couple of weeks ago, and the one that piqued my interest the most (at least in a positive way) was WildPackets’.  The WildPackets OmniPeek software can now sniff 802.11ac traffic, with a catch.  The catch?  It only sniffs single streams 802.11ac traffic.  Is that a useful thing?


First things, first: In order to sniff 802.11ac traffic, you need a AE6000 (Linksys Wireless Mini USB Adapter AC 580 Dual Band) adapter.  (And if you decide to buy one and want to support this blog, you can use that link to Amazon.)

The AE6000 adapter is a single stream 802.11ac adapter with a Ralink chipset.  WildPackets is developing a driver for the Ralink chipset and demonstrated the AE6000 in action.  The expectation is that it will be a month or two before the OmniPeek drivers for the AE6000 actually get released, but I bought one so that I’m ready.

Being able to sniff 802.11ac traffic may be great, but the even greater question is, “how useful is single stream sniffing?”

After all, it was less than six months ago that yours truly was writing that three stream capture is necessary for the modern enterprise.  Without three stream capture, the data going to and from a lot of laptops and media centers is going to be missed.  If you work in an area that needs to support those types of devices, that makes three streams a requirement for in-depth troubleshooting.

There are some use cases for single stream capture.  Smartphones, tablets, bar code scanners, point of sale terminals and a number of other smaller devices all use single stream WiFi, and are expected to for the foreseeable future.  All data going to and from those devices can be captured with a well-placed AE6000.

In the future we may see even more devices embrace single stream WiFi.  Remember, single stream WiFi saves battery life.  We all know how frustrated users get with laptops that can’t hold a charge.  Just from my personal experience, I can tell you that I would gladly trade my MacBook Air’s two stream WiFi interface for my iPad’s single stream interface.  My iPad has slower networking than my MacBook Air, but not slow enough that it bugs me.  I’ll gladly take a little bit of delay in my web surfing, emailing and perusing of Twitter in order to extend my laptop’s battery life.  I have to imagine that there are a lot more people out there like me, and so I expect that laptop makers will start to embrace single stream WiFi radios at some point in an effort to serve us battery life fiends.

For today, though, just make sure you know what you’re trying to sniff.  If you have a bunch of tablets and smartphones that need attention, then the AE6000 works.  If the environment includes some multi-stream devices, then stick to sniffing from an adapter that supports multiple streams.

Written by sniffwifi

August 21, 2013 at 2:24 am

An OmniPeek Deal

leave a comment »

WildPackets has a sizable discount for OmniPeek Professional right now if you bundle it with three OmniWiFi 802.11a/b/g/n 3-stream USB adapters.  

WildPackets OmniPeek has long been my favorite WiFi sniffer, and the OmniWiFi USB adapter is currently my favorite capture device.  So getting a package of OmniPeek Pro with three OmniWiFi adapters at a $900 discount would seem to be an awesome deal, right?  Sort of.

There are several versions of WildPackets OmniPeek, and for the most part the more expensive versions add features that are far more useful for wired sniffing than for wireless sniffing.  One look at the OmniPeek comparison chart reveals that the Compass screen and roaming testing are the only features that could possibly maybe justify a WiFi person spending $3,000 (discounted to $2,400 as part of the deal referenced above) on OmniPeek Pro rather than $1,200 on OmniPeek Basic.

Compass is nice, and if you have a relatively large budget for WiFi sniffing software, then the deal referenced above may be a good deal.  Budget-conscious folks might have a tougher choice.  Do you want OmniPeek for general monitoring, troubleshooting and analysis?  If so, then maybe Pro is the move.  If you’re more of a hardcore capture person who uses OmniPeek for filtering, statistics gathering and deep analysis, then Basic may be better.

Written by sniffwifi

August 12, 2013 at 2:30 pm

Posted in OmniPeek, OmniWiFi

OmniWiFi USB Adapter and OmniPeek 7.5: Compass is King

with one comment

As long time readers of this blog might know, WildPackets OmniPeek has been my favorite WiFi sniffer for nearly a decade.  Then I found out about WildPackets’ OmniWiFi 3-stream 802.11n USB adapter and I fell even more in love.  Now I learn that OmniPeek 7.5 has added wireless features to the Compass screen.  A good product has been made better (though time will tell if it lasts).

First, OmniWiFi:

The fact that different 802.11n devices have different capabilities is one of those things that sometimes flies under the radar.  The standard may say 600 Mbps, but just on the Apple website one can buy 802.11n devices with maximum rates of 65 Mbps (iPhone 4S), 150 Mbps (iPad Mini), 300 Mbps (Macbook Air 2012) and 450 Mbps (Macbook Pro 2012).

450 Mbps WiFi devices are the ones that give WiFi pros trouble because so many sniffing tools fail to capture 450 Mbps traffic.  The popular (at least with Wireshark devotees) AirPcap NX from Riverbed, the beloved (at least by yours truly) D-Link DWA-160 and the hacker-ish SR71-USB from Memphis Grizzlies owner Robert Cera’s Ubiquiti Networks all are dual-band 802.11a/b/g/n USB adapters that can be used with WiFi sniffing software, but none of them can capture 450 Mbps data frames.  Those adapters all have two radio chains (and thus, can capture two-stream 802.11n) and 450 Mbps traffic uses three-stream 802.11n.

OmniWiFi is a USB adapter that gives WildPackets OmniPeek users the ability to capture three-stream 802.11n traffic.  It also dynamically adjusts its capture settings when 802.11n traffic is in the air.  When my iPhone was sending and receiving data frames over a 40 MHz channel, OmniWiFi captured all 40 MHz.  When my acknowledgment, request to send or clear to send frames went out on a 20 MHz channel, OmniWiFi caught that as well.

The limitation of OmniWiFi is that it is 802.11n, and the consumer side of WiFi is moving towards 802.11ac.  Management frames and most control frames will still be captured with OmniWiFi.  Data frames over WLANs that have yet to upgrade of 802.11ac access points, as well.  The problem is that if a coffee shop on the ground floor of an office building decides to buy a new Apple Airport Extreme, you won’t be able to tell exactly how the data traffic going to and from a new Macbook Air is affecting your WLAN.

When I spoke to a representative from WildPackets, I was told that an 802.11ac version of OmniWiFi might be in the works.

To repeat:  When I spoke to a representative (someone whose job description presumably includes promoting the company) from WildPackets (the company who makes the best enterprise-grade 802.11n WiFi sniffing solution), I (a WiFi sniffing blogger) was told that an 802.11ac (the hot new standard) version of OmniWiFi (the best wireless hardware ever created by the company) might (as in, might-or-might-not) be in the works.

What the heck?

When I was told that an 802.11ac version of OmniWiFi was not a certainty, I sort of couldn’t believe it. The WildPackets rep (a technical guy who knows 802.11 quite well) shoveled over some mumbo-jumbo about OmniPeek capture support in 802.11ac access points (from Ruckus Wireless) and the speed limitations of the USB 3.0 interface (and I was proud that I avoided giving my stump speech on the lack of value in throughput tests in response).  He said that USB-based wireless capture was limiting, and that most WildPackets customers prefer to capture from APs, anyway.  Great.  Fantastic.  But how about using a WiFi sniffer to solve the tough problems?  That requires field work.  That requires a portable device from which to capture.  That is not the type of thing you do from an AP.

I am going to enjoy OmniWiFi while 802.11n continues to be relevant, but I really, really, really hope that WildPackets pushes Ralink (makers of the current 802.11n OmniWiFi chipset) to make a USB adapter that does 802.11ac capture.  I don’t want to have to write a blog post titled, “Worthless Capture, Part III”.

And Then, OmniPeek 7.5:

My conversation with the WildPackets rep also covered OmniPeek 7.5.  If you are a user of OmniPeek Basic ($1,200 USD), then you can skip the rest of this blog.  OmniPeek 7.5 doesn’t add anything all that new.  The Packets screen has a new MCS (modulation and coding scheme) column and a new Spatial Streams column (see below).

Neither the MCS column nor the Spatial Streams column works, so forget it.  Maybe OmniPeek will get things going in a future update, but that picture above clearly shows 54 Mbps (which could be single stream 802.11a/g or dual stream, MCS 3 802.11n) data and it clearly shows no indication of which type of 54 Mbps data it is (answer: 802.11n.  Now can you tell me in the Comments how I know that from looking at JUST THE PACKETS in this capture…?).  (To be fair, the WildPackets rep used Go To Meeting to show me a capture that had information in the MCS and Spatial Streams columns.  It did not work for me, however.)
For those of you that use OmniPeek Pro ($3,000 USD) or OmniPeek Enterprise ($6,000 USD), there is something new in version 7.5, and it involves the Compass.
The OmniPeek Compass is something that has been present in OmniPeek, but I never used to use it because it didn’t give me relevant WiFi information.  I want to know Data Rates.  I want to know Retry percentages.  I don’t care about Mbps averages or conversations.  Save that for wired sniffing.  Wireless sniffing should be all about wireless (connection, performance, security, etc.) analysis.
OmniPeek Compass now shows data rate and retry information, and it is great.  
Let’s take an example.  Say I have a smartphone that is having WiFi problems.  I can create a couple of smartphone filters (one for data coming to my smartphone and one for data coming from my smartphone) and then go to Compass.  First I apply one filter (To the phone) and then the other (From the phone).  I can then track what rates are typically being used in both directions.
The screenshot above shows that my smartphone is using higher rates than my AP.  On the left hand side (in the area where I was applying the To Phone filter) the maximum rate fluctuated between 54 and 81 Mbps (MCS 3 and 4).  Once I switched to the From Phone filter, the maximum rate immediately spiked to being between 81 and 108 Mbps (MCS 4 and 5).  That tells me that my phone is very aggressive in trying to send data at high rates.
A quick flip of the Compass screen from Rates to Retries allows me to see if my smartphone’s use of high rates has consequences.
Again, the To Phone filter was applied first (on the left of the graph) and the From Phone filter was applied after (on the right).  Data going to my smartphone was almost never retried (which made sense, since the office uses a 5 GHz channel that is unoccupied by any other WiFi networks).  Once the filter switched to data being sent by my phone, Retries started to show.  The percentages were still below 8% (which is the rule-of-thumb number I use to determine if Retries are a problem), but they were still there.  It means that, at least for the application I was running for the test, the iPhone 5 might be a little bit better off using lower rates so that Retries can be almost entirely eliminated.
That is just one example.  One of the best things about OmniPeek is the myriad ways that filters can be configured and applied, and Compass is a perfect place to see what those filtered devices and protocols are doing in real time.
OmniPeek 7.5 is worth having, but it could still be improved.  I’d still like to see WildPackets copy off of the superb work that Metageek did with Eye P.A. and add a Time metric in addition to Packets and Bytes.  OmniPeek also needs to give better breakdowns of exactly how many packets or bytes are using which data rates.  Still, it remains a great tool and the additions to Compass in version 7.5 make it even more useful.

Written by sniffwifi

July 1, 2013 at 11:47 pm