A Fish in the Desert: Chromecast, Sniffed

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.