There are plenty resources online that explains how Chromecast works. But most of them focus on up-layer protocols, such as mDNS, DIAL/HTTP. I am more interested in the 802.11 MAC layer. In particular, I was curious in questions such as:
- What happens when you set up a Chromecast?
- How the cast device (such as an Android phone) and Chromecast communicate (in 802.11 layer)?
Some of the questions were obvious, others are not. In this post, I will document the process about the Chromecast setup process. This will be the first of the series of posts on this topic.
Hardware and Tools
Hardwares:
- Chromecast (first gen, model: H2G2-42): test device
- TP-LINK WDR3500: AP
- TP-LINK WDR3500: Wifi sniffer, capture packets for analysis
- Nexus 6P: cast device
Software Tools:
- OpenWRT: running on both the AP and the sniffer. Makes AP configuration and trace collection easy.
- tcpdump: used to collect trace
- Wireshark (v2.0.2): used to view trace
- Google Cast app on Android: used to setup Chromecast.
Chromecast Setup
The cast device and the chromecast dongle have to connect to the same Wifi Access Point (AP) before the cast can happen. Because the Chromecast does not have a GUI where you can configure it to connect to your Wifi network, this step is done in-directly on the cast device.
The basic flow is this:
- The Chromecast dongle creates a Wifi network with the default SSID ChromcastXXXX, where XXXX are 4 digit number identifying the device.
- The Google Cast app searching for such networks and associates with it once found.
- You select which AP the Chromecast device should connect to, and enter credentials accordingly.
- The Chromecast device tries to connect the AP using the credentials provided in last step.
- Once the Chromecast is connected to the AP, it sets the SSID field of the beacon frames to NULL (0 in length) such that the ChromecaseXXXX SSID disappears in your phone's scan result,
The Beacon
Here is a snapshot of the beacon frame sent by the Chromecast device BEFORE it is configured.
There are couple of interesting facts I found.
The OUI of the Chromecast device (fa:8f:ca) is actually not registered. I can not find it anywhere (Wireshark OUI lookup, IEEE OUI database). I don't know how to interpret this...
I tried to fool the Google Cast app by creating a fake Wifi AP with the SSID Chromecase5089, and see if it will be list as a Chromecast in the app. The answer is: NO. Then I realized of course not, since you can name the Chromecast device whatever you want after setting it up, so SSID is not a good classifier of whether an AP is a potential Chromecast device.
My second try is to fake the BSSID, especially the OUI. I set the BSSID of my test router to some value similar with the true Chromecast. It works this time. Like I guessed earlier, the SSID does not matter at all. As show in the following screenshot. The first is the true Chromecast device, while the second one is a fake.
Link Setup
After the cast device connects to the mini Wifi network created by the Chromecast dongle, we can instruct the Chromecast to connect to the actual AP.
After filling in the AP to connect to, I observed an association request from a device with a different MAC address (OUI 6c:ad:f8) than the Beacon SSID in previous step. OUI lookup result show this OUI belongs to "AzureWave Technology Inc.", which matches its hardware spec.
After Chromecast connects to the AP, the SSID field in the beacon frame was set to NULL.
Given the OUI difference and the Chromecast simultaneously broadcasts beacon and associates with the AP, I suspect it actually contains two Wifi chips inside: which does not make much sense given its small form factor and low price. Or maybe the AzureWave chip supports both mode simultaneously?