Just another site

Archive for the ‘WildPackets’ Category

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

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