UNIVERSITY OF ANTWERP

Academic year 2020-2021

Faculty of Science

Reverse Engineering Google Wifi

Freek De Sagher

Supervisors: Paola Soto-Arenas

Ensar Zeljković

,
Contents

1 Introduction 1

1.1 What is Google Wi-Fi? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 802.11s Mesh Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Goal of the Research Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Gitlab Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 General Information and Used Devices 3

2.1 Google Wi-Fi devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 General Information Google Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 Google Wi-Fi Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.3 Google Wi-Fi Access Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Additional Wi-Fi Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 IDLab Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 OpenWRT Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Devices Used in Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Monitor PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.2 Intel NUC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.3 PC 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.4 PC 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.5 Smartphone 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Google Wi-Fi Mesh Configuration 13

3.1 Configuration Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Search for Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.2 Connect Device to Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

i
ii CONTENTS

3.1.3 External Services Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.4 Finalizing the Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.5 Final Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Configuration Process: 2.4 GHz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.2 Configuration Process: 2.4 GHz and 5.0 GHz . . . . . . . . . . . . . . . . . . . . . 21

3.2.3 Configuration Process without Packet Filtering . . . . . . . . . . . . . . . . . . . . 23

3.2.4 Experiments Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3 Authentication and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Channels 29

4.1 Interference Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Channel Selection/Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.3 Side Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Handovers 39

5.1 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.1 Move Client Away from Google Device . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1.2 Interference Based Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Band Steering 49

6.1 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1.1 Band Steering Based on Client Distance . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1.2 Band Steering Under Heavy Interference . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7 Power Management 57

7.1 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.1.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
CONTENTS iii

8 Reflection on the Project 59

8.1 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.2 Process Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

References 61
iv CONTENTS
Chapter 1

Introduction

1.1 What is Google Wi-Fi?

Figure 1.1: Google Wi-Fi devices

Google Wi-Fi is a product made by Google. It is a home Wi-Fi system that aims to provide reliable
Wi-Fi coverage in every corner of your home. It basically replaces your home router. The main idea is
that you can have multiple Google Wi-Fi boxes that seamlessly interconnect and in that way extend the
Wi-Fi signal coverage in your home. Additionally, it has a set of interesting features, such as mobility,
network assisted channel selection and so on.

The connections between the devices are made by using technology based on the 802.11s amendment [1]
for mesh networks.

1.1.1 802.11s Mesh Networks

802.11s is an amendment to the 802.11 standard. The document describes how mesh networks could be
formed in a standardized manner such that it is compatible with other 802.11 devices.

A mesh network is a group of devices that act as a single Wi-Fi network; so there are multiple sources
of Wi-Fi around your house, instead of just a single router. Since Wi-Fi is broadcasted from each Wi-Fi
point (and not just a single router), it can provide better coverage over a wider space. The more Wi-Fi
points you have, the more you can spread them around your house for better Wi-Fi. And all Wi-Fi
points are connected to each other wirelessly.

1
2 CHAPTER 1. INTRODUCTION

1.2 Goal of the Research Project

The goal for this research project is to reverse engineer how Google manages to perform mesh related
tasks. Google advertises that its devices are capable of a lot of interesting features such as mesh channel
selection, handovers, band steering and so on. However, not many technical details are found in how it
implements these features.

For this project, access to a Google Wi-Fi product is given and the main goal is to explain how these
advertised features are accomplished. More information on the concrete tasks is provided in a document
that can be found in the Gitlab repository. (IDLab - Reverse engineering Google Wi-Fi - Internship
(pdf))

1.3 Gitlab Repository

For this research project, experiments were conducted. These experiments sometimes used custom
scripts and generated data such as capture files (pcap). All those files are gathered in a public repos-
itory on the IDLab Gitlab (https://gitlab.ilabt.imec.be/reverse-engineering-google-wi-fi/
reverse-engineering-google-wifi/). Each custom written script and each output file that is gener-
ated are present in this repository.
Chapter 2

General Information and Used

Devices

In this chapter, the general parameters of the used devices are described as well as the capabilities of each
device. This includes the configuration options for the Google Wi-Fi devices, the advertised protocols
and standards that are used, general information such as BSSID and so on.

Besides the Google Wi-Fi devices, each additional device and network that is used throughout this
research project is described with its capabilities and general information.

2.1 Google Wi-Fi devices

For this research project, two Google Wi-Fi devices were available. First, there is the Google Wi-Fi
Router which handles connections to the outside world. It does act as an access point as well. Secondly,
there is the Google Wi-Fi AP, delivered with the router. This access point has no cabled connection
to the outside world and thus must communicate to the router over the mesh network. The following
section describes some general parameters and general information about the Google Wi-Fi network.
This is followed by two sections that describes details of the two Google Wi-Fi devices.

2.1.1 General Information Google Wi-Fi

Google Wi-Fi is designed to be used by people that do not have a thorough understanding of networking.
Setup of the network should be straightforward and easy. That is reflected in the options that are
available and in the way configuration has to be done. In order to configure the mesh network, users
should download the Google Home app [3] for their smartphone. All configuration and setup is guided
from this smartphone application.

2.1.1.1 Advertised Capabilities

On the Google website [5], one can find the capabilities that the Google Wi-Fi devices have. Each
capability is given in table 2.1.

3
4 CHAPTER 2. GENERAL INFORMATION AND USED DEVICES

Option Value

Standard expandable 802.11s mesh-wifi

WiFi standard simutaneous dual band WiFi with support for IEEE 802.11a/b/g/n/ac
WiFi optimizations 802.11k/v client roaming
proactive band steering
uses beamforming
Security WPA3 encryption

Table 2.1: Advertised specifications

2.1.1.2 Configuration Options

There is only a sparse amount of settings that can be configured. Settings can only be changed from
within the Google Home smartphone app. There is no web interface or something different to configure
the network. The most important configuration options are given in table 2.6 in section 2.2.3. Note
that this table is not entirely complete. Only settings that are relevant for this research project are
given. As it can be seen from table 2.6, Google does not allow much flexibility when configuring a Wi-Fi
device. This complicated quite some experiments that had to be done for this research project. For
example, there is no way to manually pick a channel to operate on which complicated channel selection
experiments. Further, it is not possible to disable encryption of packets. Encryption happens at a low
level, on the devices itself. It is impossible to monitor the secret keys that are used for the encryption
method. As a result, many of the capture files that are generated during experiments contain encrypted
packets that cannot be decrypted.

2.1.2 Google Wi-Fi Router

Table 2.2 shows the MAC addresses, or BSSIDs that are used by the Google Wi-Fi Router.

Interface BSSID

2.4 Ghz CC:F4:11:6A:B6:87

5.0 Ghz CC:F4:11:6A:B6:81
LAN CC:F4:11:6A:B6:81
WAN CC:F4:11:6A:B6:80

Table 2.2: BSSID’s of the Google Wi-Fi Router

Each interface has its own BSSID. The BSSID of the WAN interface can also be found on the bottom of
the router. The other BSSIDs were found while performing experiments, or by using a smartphone app
that can monitor the nearby networks. [10]

During some experiments later in the research project, a new MAC address popped up which looked very
similar to the addresses given in the table. This separate interface is used to manage the mesh network.
More on this in chapter 3. The encountered MAC address was the following.

CE : F 4 : 11 : 6A : B6 : 81

By default, Google Wi-Fi uses the following IPv4 subnet

192.168.86.0/24

The router uses 192.168.86.1 as IP address.

2.2. ADDITIONAL WI-FI NETWORKS 5

2.1.3 Google Wi-Fi Access Point

Similar to the Google Wi-Fi router, a table (2.3) containing the BSSIDs is given for the Google Wi-Fi
access point.

Interface BSSID

2.4 Ghz F0:72:EA:56:AB:82

5.0 Ghz F0:72:EA:56:AB:85

Table 2.3: BSSIDs of the Google Wi-Fi Access Point

Again, during some future experiments, a similar looking BSSID was encountered which is used for mesh
management. This extra BSSID is the following

F 2 : 72 : EA : 56 : AB : 84

The IP address is in the same subnet as the router. Since it can change throughout experiments, there
is no specific IPv4 given.

2.2 Additional Wi-Fi Networks

Some of the experiments for this research project required interference to check how the Google Wi-
Fi devices react on this. Aside from the noise from the commercial networks in the neighborhood,
interference was generated by using two additional networks consisting out of one router each. These
networks can be configured to use the same channels as the Google Wi-Fi does in order to generate
interference on those channels. The two networks and their capabilities are described in the two following
sections (2.2.1 and 2.2.2).

2.2.1 IDLab Network

The IDLab network consists of one router only. It is a TP-Link router with model AP 200 AC 750. The
basic setup of the router was already done by someone at IDLab before the research project started.
That is why this network is referred to as the IDLab network.

2.2.1.1 Capabilities

Since this router is equipped by the standard TP-Link firmware, it has more configuration options than
Google Wi-Fi has. Table 2.6 shows some of the most important configuration options compared to the
other networks. This network can be setup based on the needs for the experiment, which is a huge plus.

2.2.1.2 General Parameters

The table 2.4 shows the BSSIDs for each interface that is present on the access point.
6 CHAPTER 2. GENERAL INFORMATION AND USED DEVICES

Frequency BSSID

2.4 Ghz 50:C7:BF:52:A8:30

5.0 Ghz 50:C7:BF:52:A8:2F

Table 2.4: BSSIDs of the IDLab Network

The IP address is setup to be 192.168.0.254 and is kept the same throughout the research project.

The BSSIDs and other general parameters are all found on the web interface that is presented to the
user when browsing to the IPv4 address of the router.

2.2.2 OpenWRT Network

The final network that is used is named the OpenWRT Network. It is a TP-Link router with model C7
AC 1750. Despite being a TP-Link router, it uses the OpenWRT firmware [6] (version 19.07.4). Before
the router was used, a complete reset of the operating system was performed in order to start from a
clean version of the firmware. This network will be referenced as the OpenWRT Network further in this
report.

2.2.2.1 Capabilities

OpenWRT firmware is extremely flexible. It is even possible to run custom servers or services on the
operating system. For this research project, no additional services were configured on the OS of the
router.

Since OpenWRT is highly flexible, many configuration options are available (see table 2.6). Configuration
needs to be done using the web interface of the router.

2.2.2.2 General Parameters

The BSSIDs of the router were the following:

Frequency BSSID

2.4 Ghz 14:CC:20:0C:64:72

5.0 Ghz 14:CC:20:0C:64:71

Table 2.5: BSSIDs of the OpenWRT access point

The IPv4 address that was used for this network was 192.168.1.1 and did not change throughout the
research project.
All this information is found on the web interface of the routers configuration.
2.3. DEVICES USED IN EXPERIMENTS 7

2.2.3 Summary

This section gives a comparison of the capabilities of all network devices described above. The comparison
is given in table 2.6.

Option Google Wi-Fi IDLab Network OpenWRT Network

Change SSID D D D
Manual channel selection X D D
Power management options X D D
Select channel width X D D
Hide SSID X D D
Enable or disable 2.4/5.0 Ghz X D D
Select 802.11 version X D D
Disable security X D D
View connected clients D D D
Manual LAN IP D D D
Portforwarding D D D
Google Wi-Fi Router
Label(s) in figures IDLab Network OpenWRT Network
Google Wi-Fi AP

Table 2.6: Comparison of capabilities and information of the network devices

These networks are often used in experiments. When they are used, they are represented by the icon
displayed in figure 2.1. The label below the icon is the name of the network device, as given in table 2.6.

Figure 2.1: Representation of networks in diagrams

2.3 Devices Used in Experiments

In the experiments that are performed for this research project, many other devices were used: some were
used as clients to networks, others were responsible for monitoring traffic on network channels. Each of
these devices is limited by its capabilities and features. These are described in the following sections for
each device. The purpose of these devices in the experiments is given as well.

2.3.1 Monitor PC

2.3.1.1 General Information and Capabilities

The Monitor PC is a laptop of the brand ASUS. The model is ASUS X550CC.
The most interesting information for this project is the information regarding the wireless network
capabilities. An overview of this information is given in table 2.7.
8 CHAPTER 2. GENERAL INFORMATION AND USED DEVICES

Option Value

Operating System Ubuntu 18.04.5 LTS

Wireless interface vendor Qualcomm Atheros
Wireless interface product AR9485 Wireless Network Adapter
MAC address 48:d2:24:45:16:5c
Wireless interface name wlp3s0
Support 2.4 Ghz D
Support 5.0 Ghz X
Support monitor mode D

Table 2.7: Monitor PC information

This information is retrieved by using the lsb release − a command on the command line.

2.3.1.2 Purpose

The Monitor PC is a rather old laptop that only supports the 2.4 GHz band. For the major part of
the research project, this was the only computer available to monitor the air. As a consequence, only
information on the 2.4 GHz band is retrieved for most experiments.

The main purpose of this device was to monitor the channels that were used by the Google Wi-Fi de-
vices during experiments. The wireless network card has been put into monitoring mode thanks to the
airmon-ng command from the aircrack-ng suite [2]. The laptop rarely acted as a client to one specific
network.

It is one of the most important devices used throughout this project. It is used in almost each experiment
that has been conducted.

2.3.2 Intel NUC

2.3.2.1 General Information and Capabilities

This device is the 5.0 GHz counterpart of the Monitor PC. It is a NUC device from Intel with as model
NUC7i5BNHXF and is property of the research group.
Before this device was used, a clean version of Ubuntu was installed on it.

Some general information and capabilities are given in table 2.8.

Option Value

Operating System Ubuntu 20.04.1 LTS

Wireless interface vendor Intel Corporation
Wireless interface product Wireless 8265 / 8275
MAC address 18:56:80:22:27:44
Wireless interface name wlp3s0
Support 2.4 Ghz D
Support 5.0 Ghz D
Support monitor mode D

Table 2.8: Intel NUC information

2.3. DEVICES USED IN EXPERIMENTS 9

This information was retrieved using the same command as before: lsb release − a.

2.3.2.2 Purpose

As mentioned before, the Monitor PC is only capable of sensing the 2.4 GHz band. Since Google Wi-Fi
operates on both 2.4 GHz and 5.0 GHz, it was important to also have a device that can monitor the 5.0
GHz simultaneously. This is exactly what the Intel NUC was used for: it monitored the air on the 5.0
GHz band while performing experiments.

2.3.3 PC 1

2.3.3.1 General Information

PC 1 is a Notebook N85 N870HL laptop. Table 2.9 gives some more information about its capabilities.

Option Value

Operating System Microsoft Windows 10 Pro

Wireless interface vendor Intel
Wireless interface product Intel(R) Dual Band Wireless-AC 3168
MAC address B0:35:9F:2B:9E:BD
Service name Netwtw04
Support 2.4 Ghz D
Support 5.0 Ghz D
Support monitor mode X

Table 2.9: PC 1 information

This information is retrieved from the device manager in Windows and from system information.

2.3.3.2 Purpose

Note that this laptop does not support monitor mode. This was an initial issue when starting the project,
but has been resolved thanks to the Monitor PC and the Intel NUC.

Instead of monitoring the air, this laptop is mainly used as a client device to the Google Wi-Fi network and
executed scripts to gather data. Note that the operating system is Windows, which has as consequence
that the used scripts had to be written to run within the Windows environment.

A virtual Linux machine has been considered, but this is no option since a virtual machine creates virtual
(wired) network adapters which interfere with the obtained results.

2.3.4 PC 2

PC 2 is a Lenovo B71-80 80RJ laptop. Some capabilities are given in table 2.10
10 CHAPTER 2. GENERAL INFORMATION AND USED DEVICES

Option Value

Operating System Microsoft Windows 10 Home

Wireless interface vendor Intel
Wireless interface product Intel(R) Dual Band Wireless-AC 3165
MAC address E0:94:67:BD:9C:EB
Service name Netwtw04
Support 2.4 Ghz D
Support 5.0 Ghz D
Support monitor mode ?

Table 2.10: PC 2 information

The information is received from the Windows system information. Note that it is unknown whether
this device supports monitor mode or not as it was not used for monitoring purposes.

2.3.4.1 Purpose

The purpose of this laptop is to act as an iperf3 server or client in some of the experiments.

2.3.5 Smartphone 1

2.3.5.1 General Information and Capabilities

For some experiments, many devices are required. Aside from the laptops, some times it was required
to use smartphones as well in order to generate enough traffic on the used network(s).

The used smartphone is a Motorola One Vision. Its capabilities are given in table 2.11.

Option Value

Operating system Android 10

MAC address randomized
Support 2.4 GHz D
Support 5.0 GHz D
Support monitor mode X

Table 2.11: Smartphone 1 information

Note that the smartphone does both support 2.4 GHz and 5.0 GHz. There is, however, no possibility
to disable one of the two. The system automatically decided whether it should connect to the 2.4 GHz
band, or to the 5.0 GHz band. Further, it is important to note that MAC address of Android phones
are randomized [9].

2.3.5.2 Purpose

Since it is not possible to select a frequency on the smartphone, it is only used to act as a client. Usually,
its purpose is to act as iperf client and to generate traffic.
2.3. DEVICES USED IN EXPERIMENTS 11

2.3.6 Summary

The capabilities of each device are summarized in table 2.12. Irrelevant options are marked as ’/’.

Option Monitor PC Intel NUC PC 1 PC 2 Smartphone 1

Support 2.4 GHz D D D D D

Support 5.0 GHz X D D D D
Support monitor mode D D X / X
Wireless interface name wlp3s0 wlp58s0 / / /
Purpose Monitor Monitor Client/Server Server Client

Table 2.12: Devices summary

Each of these devices is used at least once in an experiment.

They are represented by the icons as shown in figure 2.2 The labels below the icon indicate which specific
device it refers to.

Figure 2.2: Representation for each type of device

12 CHAPTER 2. GENERAL INFORMATION AND USED DEVICES
Chapter 3

Google Wi-Fi Mesh Configuration

In this chapter, we will look at how Google manages to setup its mesh network. The experiments that
were used to find this information are briefly explained in section 3.2. Each step of the configuration flow
is explained in section 3.1. Further, a comparison is made with the official standard for mesh networks
to see which configuration options are used by the Google Wi-Fi devices.

3.1 Configuration Flow

Before we can start looking into the details of how the devices communicate with each other to setup
the mesh network, we will look into the setup that each user has to go through in order to setup the
devices. This setup is done using the Google Home smartphone application [3]. Configuration can only
be done using this application. There is no other way in which the devices can be configured to work.

In what follows in this section, a screenshot and some explanation is given of each step that the user
should take to set everything up. The process is quite simple and straightforward as all people should
be able to perform these actions. Note that this process only describes how to add an access point to
the existing network. The router (and the network that belongs to it) are setup in a similar way and are
not included in this report.

13
14 CHAPTER 3. GOOGLE WI-FI MESH CONFIGURATION

3.1.1 Search for Device

Figure 3.1: Configuration start

Setup starts at the home screen of the Google Home application. It already sensed that an unconfigured
Google device was in the vicinity and immediately gives an option to configure it (see text below ”Ap-
partement” on figure 3.1).
Clicking this button navigates the application to the screen which can be seen in the second image. Here,
the user should pick the ’house’ to add the device to. In the Google Home app multiple networks can be
managed (referred to as ’houses’).
For this particular case, only the house called Appartement is available containing the configured Google
Wi-Fi Router. In my case, I only have the Appartement house which contains the Google Wi-Fi
Router. When the user presses the continue button, the app starts looking for devices. After a short
period of time, the unconfigured device is found, and the user can continue. The entire process is shown
in the images of figure 3.1.

Figure 3.2: Initial pairing

When the device is found, a QR code should be scanned (figure 3.2). This code can be found on a sticker
3.1. CONFIGURATION FLOW 15

at the bottom of the device. When this QR code is not present anymore, the user can enter a code which
is engraved in the bottom of the device. This step is to ensure that the user has physical access to device
and thus is not able to configure devices that are not his/her property.

Figure 3.3: Connect phone to device

When this is done, the application tries to connect to the Google Wi-Fi AP (using Bluetooth LTE). A
successful connection is indicated by a sound produced by the access point (figure 3.3).

Figure 3.4: Basic network and device information

Now, some basic settings are asked to the user. This includes whether you want to send anonymous data
to improve the Google services.

Note that picking an option always gives the warning that the device is made for another country. The
devices used in this research project are made for France. This pop-up can be ignored.
16 CHAPTER 3. GOOGLE WI-FI MESH CONFIGURATION

3.1.2 Connect Device to Network

Figure 3.5: Connect the access point to the network

With the basic settings out of the way, it is time to add the access point to the existing network (figure
3.5). First, a room should be picked, or created.

When this is done, a connection is made from the access point to the existing Google Wi-Fi network.

Figure 3.6: Notices given by app

When the connection is established, the user gets notified twice (figure 3.6). The first one indicates that
anonymous statistics are shared with Google. This can be turned off in the settings of the mobile app.
Secondly, the user is informed that cloud services are enabled.
3.1. CONFIGURATION FLOW 17

Figure 3.7: Adding the point to the network

Finally, the access point is added to the network, as seen on figure 3.7.

3.1.3 External Services Setup

Figure 3.8: Google Assistant setup

Since the Google Wi-Fi AP has built in support for the Google Assistant, the user gets some information
on this and can activate voice match if he wants to (figure 3.8).
18 CHAPTER 3. GOOGLE WI-FI MESH CONFIGURATION

Figure 3.9: External services setup

In the end, the user has some options to setup other external services such as Spotify or Netflix (figure
3.9).

3.1.4 Finalizing the Setup

Figure 3.10: Confirmation and mesh test

In the end, a confirmation screen is presented, and the option is given to add even more devices to the
network (figures 3.10 and 3.11).
3.2. EXPERIMENTS 19

Figure 3.11: Final screens of configuration

3.1.5 Final Remarks

As can be seen in the previous sections, the configuration flow is extremely simple. Any user should be
able to complete these steps without any problems. This has as a drawback that there are not many
configuration options present that are helpful for experiments in this research project.

3.2 Experiments

In order to find some more details on how this configuration flow works, some experiments were created.
Each experiment that was conducted is explained in this section using a diagram and some information.
Results are discussed afterwards.

Note that all capture files can be found in the Gitlab repository under the capture-files/mesh-configuration/
folder and its sub-folders. The experiments are numbered in the order in which they occur in this docu-
ment (Configuration Process: 2.4 GHz is experiment 1 and so on).

3.2.1 Configuration Process: 2.4 GHz

The first set of experiments focused on the 2.4 GHz band. This is because at the time of this experiment,
no devices was available to monitor 5.0 GHz band yet. In later experiments, the Intel NUC was available
to fix this issue.

The goal for these experiments was to get insights in how the mesh network is initialized during the
configuration process. In order to gather data, the air was monitored during the configuration process
described in section 3.1.
20 CHAPTER 3. GOOGLE WI-FI MESH CONFIGURATION

Figure 3.12: First set of experiments

The setup shown in figure 3.12 was used to monitor the traffic being sent from the router to the access
point and vice versa. This procedure was done two times: once with the router and access point 5 meters
apart, and once where the devices were 10 meters apart. By increasing the distance between the two
devices, they were forced to use the 2.4 GHz band rather than the 5.0 GHz band. This is the only way
to enforce this as there is no option to disable one band for the Google Wi-Fi devices.

The monitor PC was setup to be in monitor mode on channel 6, the channel selected by the Google
Wi-Fi Router. Wireshark [11] was used to capture traffic. A capture filter was used to filter out beacon
frames, probe request, probe responses, and traffic that is from different BSSIDs. This capture filter was
used in both experiment variants (5m distance and 10m distance). Later, it became clear that this is
not a good idea since a lot of information resides in beacon frames and probe requests/responses.

3.2.1.1 Results

From the first set of experiments, not many useful information could be extracted. Most frames were
beacon frames, probe requests and probe responses, QoS frames... but none of these contained mesh
related information.

Some parts of the configuration workflow generated some relatively interesting packets. For example, we
can see that the access point authenticates with the router at some point in the configuration.

Figure 3.13: EAPOL packets sent on channel 6

From this point, Wireshark was able to decrypt some traffic that was sent between the access point and
the router. This did not contain any useful new information. Packets such as IGMP packets, MDNS
packets and so on are now decrypted in Wireshark.

Figure 3.14: Decrypted packets after EAPOL packets

3.2. EXPERIMENTS 21

3.2.2 Configuration Process: 2.4 GHz and 5.0 GHz

Figure 3.15: Second set of experiments

Later in the project, the Intel NUC was available which allowed the capture of the 5.0 GHz band as
well. A similar experiment setup was created. Now, not only the 2.4 GHz band, but also the 5.0 GHz
was monitored while setting up the mesh network.

For this experiments, the same capture filter was used as in the previous set of experiments.

3.2.2.1 Results

These experiments were executed two times: one time with a distance of 5 meters between the Google
Wi-Fi Router and the Google Wi-Fi AP and one time with a distance of 10 meters between the devices.

10m distance

There is not much new information that is discovered with these experiments. Even though the access
point and router were relatively far apart, the authentication frames (EAPOL frames) of the access point
were sent on the 5.0 GHz band (channel 36). The 2.4 GHz band capture (channel 6) did not contain any
EAPOL frames related to the access point.

Note: there are EAPOL frames in the image of channel 6. These correspond to the authentication of the
smartphone to the access point.
22 CHAPTER 3. GOOGLE WI-FI MESH CONFIGURATION

Figure 3.16: Monitored frames when far away on channel 6 (top) and channel 36 (bottom)

5m distance
When the devices are close together, it is expected that they use the 5.0 GHz band again. As observed
during the experiment, this was exactly the case: EAPOL packets are still captured on channel 36.

Figure 3.17: Monitored frames when close to each other on channel 6 (top) and channel 36 (bottom)
3.2. EXPERIMENTS 23

3.2.3 Configuration Process without Packet Filtering

The setup for this experiment was exactly the same as in figure 3.15. The only difference now is that no
capture filter was used anymore: all traffic was monitored without any explicit filtering.

The reason for this is that some mesh specific parameters are sent in the beacon frames, probe requests
and other management frames (see 802.11s [1]). The goal for this third iteration of experiments was to
find some mesh specific parameters from these mesh frames. The specific frame entry that was searched
for was the Mesh Configuration Report as it contains the most useful information (see 7.3.2.98 in [1]).

3.2.3.1 Results

In these experiments, the obtained results are thoroughly compared with the official 802.11s amendment
[1]. This way of working allowed for a more focused approach in examining the results: it gives a more
clear indication on what to look for.

While executing these experiments, the Mesh Configuration Report was found on some frames: beacon
frames, action frames and probe requests/responses. These frames were not sent by the BSSIDs we would
expect. They were sent by a BSSID that looks very similar to the BSSIDs we know (as stated in chapter
2) but with a slight difference.

Device New BSSID

Router CE:F4:11:6A:B6:81
Access Point F2:72:EA:56:AB:84

Table 3.1: New BSSIDs of the Google devices

These frames were sent on the 5.0 GHz band only (channel 36). The 2.4 GHz band did not contain
frames that contain mesh related information.

Mesh Beacon Frames

The official standard explains what each value of all the tagged parameters that are attached to the
beacon frames sent by mesh devices could be. The most important fields are explained in this section.

First, the SSID parameter is set to the wildcard SSID. The standard specifies that this is required for
mesh beacon frames. (see 7.3.2.1 in [1])

Figure 3.18: Mesh related tagged parameters

Now, lets take at a look at the Mesh ID tagged parameter. It has 114 as tag number. The length is
24 CHAPTER 3. GOOGLE WI-FI MESH CONFIGURATION

always set to 8 bytes. The final field contains the Mesh ID, which identifies the mesh network.

The Mesh Configuration parameter contains the most useful information. It has tag number 113 and
its length is set to 7 bytes. The path selection protocol is set to 1. It indicates that the Hybrid Wireless
Mesh Protocol is used for path selection, which is the default. Google does not use a vendor specific
path selection protocol. The used metric is set to the default value (0x01) as well. It is the airtime link
metric.

The congestion control field is set to 0 which indicates that at the time of this beacon frame, no congestion
control protocol was active on the mesh station. Note that this experiment was conducted on a congestion
free link. If a value of 255 is encountered, then a vendor specific method is used. When it is set to 1, the
default method for congestion control is used as defined in the amendment.

The synchronization method is set to 1 as well. Again, this is the default. It is the Neighbor Offset
Synchronization method, which is defined in the amendment.

For the authentication protocol, the default value is used as well. This is the Simultaneous Authentication
of Equals or SAE algorithm.

Figure 3.19: Mesh formation parameters and capabilities fields

The formation fields (figure 3.19) contain information about the mesh itself. It shows whether the device
is connected to a mesh gate or not, the amount of peerings and whether the device is connected to an
AS. When the access point is configured completely, the amount of peerings will be set to 1.

Finally, we have the mesh capability (figure 3.19) fields. It indicates whether the device accepts more
peerings (yes in this case). MCCA, MBCA and TBTT are not activated. The Mesh Forwarding field is
set to 1 indicating that traffic will be forwarded.

To conclude, there is one more field that is interesting. On the website where Google gives the speci-
fications [5] of the devices, it says that beamforming is supported and that the devices are MU-MIMO
devices (figure 3.20).

Figure 3.20: Beamforming settings

3.2. EXPERIMENTS 25

If we look at the VHT capabilities tagged parameter however, we see that only SU beamforming is
supported (single user beamforming).

Probe Requests and Responses

Probe requests and probe responses are sent back and forth between the router and the access point.
Not all of them contain mesh related information.

First, the access point sends a probe request using its default BSSID (F0:72:EA:56:AB:80). This probe
request does contain a tagged parameter that holds the Mesh ID only. A response is received from both
addresses from the router: CC:F4:11:6A:B6:83 and CE:F4:11:6A:B6:81. Only the latter contains both
the Mesh Configuration tag and the Mesh ID tag.

Somewhat further in the capture file, another probe request is sent, but this time from the other BSSID
of the access point (F2:72:EA:56:AB:84). It again contains the Mesh ID tag. The router responds with
both addresses again, just as in the previous step. At this point, authentication starts using the SAE
algorithm (figure 3.21). Authentication happens between the two special BSSIDs (F2:72:EA:56:AB:84
and CE:F4:11:6A:B6:81). Action frames are sent back and forth as well to finalize the authentication.

Figure 3.21: Authentication frames (other frames are filtered)

From this point onward, the access point and router are connected with each other and the number of
peerings field in the Mesh Configuration parameters is set to 1.

Mesh Action Frames

Not all action frames are readable in plain text. Many are encrypted and are not useful. The action frames
regarding to the mesh peering management are readable and are discussed in this section. Readable
mesh action frames contain a Mesh ID tag and Mesh Configuration tag as well. The information in these
parameters is the same as in the beacon frames.

Figure 3.22: Peering management parameter

Further, the action frames contain a new mesh related tagged parameter called Mesh Peering Management
(see figure 3.22).

The fixed parameters (figure 3.23) contain new information as well.

26 CHAPTER 3. GOOGLE WI-FI MESH CONFIGURATION

Figure 3.23: Fixed parameters

There exist two peering tags: Mesh Peering Open and Mesh Peering Confirm. These mesh peering
tags are sent after the access point authenticated to the router.

3.2.4 Experiments Conclusion

Some conclusions can be derived from the conducted experiments. From the experiments, we can see
that only 5.0 GHz is used for mesh configuration. EAPOL packets however, can be sent either on the
2.4 GHz or 5.0 GHz bands. It is not clear how it is decided which band to use for these packets.

From the third experiment (section 3.2.3), the most can be concluded. In general, Google Wi-Fi uses the
default parameters for things such as path selection, synchronization and authentication. Further, we
know that some dedicated BSSID is used to handle mesh related configuration. Both the Google Wi-Fi
Router and Google Wi-Fi AP have such a BSSID. These BSSIDs are only visible on the 5.0 GHz band.
No alternative BSSID was found on the 2.4 GHz band, no matter how far the devices were separated.
Based on this observation, we might conclude that only 5.0 GHz is used for mesh configuration.

Finally, we have monitored how the Google Wi-Fi AP is paired with the network. It is explained in the
following section.

3.2.4.1 Pairing flow

All transmitted frames can be combined to reconstruct how a mesh device is configured. It is shown
schematically in figure 3.24.
3.2. EXPERIMENTS 27

Figure 3.24: Mesh peering flow

Note that in practice, there are also QoS frames being sent from the router and access point. Since these
all contain an encrypted payload, they were not considered in the diagram. The EAPOL packets are not
shown in the diagram either.
28 CHAPTER 3. GOOGLE WI-FI MESH CONFIGURATION

3.3 Authentication and Security

As mentioned before, many frames have encrypted payload. This made it hard to gather information on
many of the frames. Encrypted frames are useless for this research and are thus not considered through
out the project.

From the experiments, the used authentication protocol: SAE (see figure 3.24). It makes sure that each
link between each device is encrypted such that only the two devices can send data on it and read data
from it.
Chapter 4

Channels

For this chapter, experiments were executed to investigate information about the used channels. First,
the performance of the Google Wi-Fi devices is measured when interference is present on the active
channel. Then, the experiments that tried to reveal information about channel selection are discussed.
Finally, the experiments regarding channel switching are explained.

4.1 Interference Testing

Before anything can be said about channel selection or channel switching, we should investigate how
high the effect of interference is on the Google Wi-Fi devices. Usually, channels are selected or switched
based on how much deteriorated the connection is due to heavy load on the channel. If the devices are
not (enough) affected by interference, then it is unlikely that a channel switch will happen.

The resulting iperf3 log files are visualized by a custom Python 3 script. This script can be found in
the Gitlab repository under scripts/visualizers/. The output of the iperf3 command on the other
hand, can be found under script-outputs/channels/interference/.

4.1.1 Experiments

A couple of experiments were conducted that only differ slightly. The main idea was the following.
Generate traffic using iperf3 [4] on the Google Wi-Fi network and monitor the throughput. This was
done once without any other active network in the neighborhood. Secondly, the OpenWRT Network was
activated. This network was setup to use the same channel as Google Wi-Fi did. A high load of traffic was
generated on the OpenWRT Network by using iperf3 again. While there as a lot of traffic on the channel,
an iperf3 client was executed on the Google Wi-Fi network as well. When these two measurements
were made, a comparison could be made between them.

29
30 CHAPTER 4. CHANNELS

4.1.1.1 Both Google Devices

Figure 4.1: Setup of first variant

The setup is given schematically by figure 4.1. Both Google Wi-Fi devices were used. They were on a
different channel while executing this experiment. The Monitor PC did not monitor the air this time. It
acted as an iperf3 client and was connected to a public iperf3 server through the internet. Interference
was generated on the OpenWRT network using iperf3 as well. On this network, both an iperf3 server
(PC 1) and an iperf3 client (Smartphone 1) were used locally.

Note that this scheme only represents the setup when interference was generated. Logs without interfer-
ence were generated by disabling the OpenWRT network.

The experiments were executed a couple of times, with different iperf3 bandwidth parameters.

Results
With the experiment described above, it is easy to compare the generated log files. The first time the
experiment was executed, the bandwidth option of the iperf3 client was set to 1G.

The results are visualized in figure 4.2 (left: no interference, right: with interference).
4.1. INTERFERENCE TESTING 31

(a) No interference (b) With interference

Figure 4.2: Results of iperf3 with (right) and without (left) interference

A clear difference can be seen. On average, a bandwidth of 51.0 Mbits/sec was achieved when no in-
terference was being generated. With interference, this average dropped to 14.8 Mbits/sec which is a
significant difference. These average values are calculated by iperf3 itself in the summary at the end of
the generated log files.

The second time this experiment was executed, the bandwidth option was set to an even more extreme
value (10G). The results are in figure 4.3.

(a) No interference (b) With interference

Figure 4.3: Results of iperf3 with (right) and without (left) interference

On average, a bandwidth usage of 56.6 Mbits/sec was achieved without interference. With interference,
it was 43.9 Mbits/sec. The difference is way less significant. As this was a strange finding, it was
checked to which device the client was connected after the experiment. Instead of being connected to
the Google Wi-Fi Router, PC 1 was connected to the access point instead. Somewhere while executing
this experiment, a handover occurred between the Google Wi-Fi AP and the Google Wi-Fi Router.
Unfortunately, the air was not monitored during this experiment. Recreating this phenomenon was
without success either.
32 CHAPTER 4. CHANNELS

4.1.1.2 Google Wi-Fi Router Only

Figure 4.4: Setup of second variant

This second variant (figure 4.4) was created because in an execution of the first variant, an unexpected
handover occurred. Since in this case, we were looking for interference only, this was undesired. That
is the reason why in this experiment, only the Google Wi-Fi Router was used. The access point was
turned off to avoid unexpected handovers.

Results
With the Google Wi-Fi AP being inactive, no handovers were possible. As bandwidth option for the
iperf3 client, 10G was used again.

(a) No interference (b) With interference

Figure 4.5: Results of iperf3 with (right) and without (left) interference

The difference in bandwidth usage is significant again (see figure 4.5).

4.2. CHANNEL SELECTION/SWITCHING 33

4.1.2 Conclusion

As a conclusion to these experiments, we can say that the interference that was generated has a significant
impact on the performance of the network. This should assure that enough traffic is being generated in
order for the Google Wi-Fi devices to detect it, and to act upon it. There are mechanisms to avoid this
quality degradation such as for example channel switching, which will be discussed in the next section.

4.2 Channel Selection/Switching

In this section, the experiments are discussed that tried to reveal how a channel is selected. An answer
to questions like ’Does the Google device prefer a channel without much traffic or not?’ or ’How does
the Google Wi-Fi device pick a channel initially?’ is searched by performing these experiments.

4.2.1 Experiments

A couple of experiments were conducted. In general the setup looked like the scheme given in figure 4.6.

The output of the scripts can be found in the Gitlab repository under script-outputs/switch/.

Figure 4.6: General setup of experiments

There is some traffic being generated on the IDLab Network using iperf3. The Monitor PC runs a
custom written script called scan-channel.sh. It can be found in the Gitlab repository under scripts/.
In some experiments, other channels were used by the devices, or the IDLab Network was exchanged for
the OpenWRT Network, but the same concept still holds.

4.2.1.1 Restart Google Devices with Traffic on Selected Link

In the first set of experiments, a Google device was restarted (turn off and on by plugging out/in of the
power outlet). The Monitor PC kept running the custom script. Then, based on the generated log, we
could see whether the device picked another channel than the one that has lots of traffic on it.

In total this is done three times: one time where the Google Wi-Fi Router was restarted, one time
where the Google Wi-Fi AP was restarted, and one where both were restarted.
34 CHAPTER 4. CHANNELS

Results
The script generated an output file that contained the channel of the Google Wi-Fi devices. From these
files, we can see that channels did change after restarting the devices in many cases.

For example, in the case where the router was restarted, the following lines were present in the log.

Listing 4.1: Output snippet of experiment 1

...
TIME : [ 1 4 : 3 7 : 3 8 ]
Address : F0 : 7 2 :EA: 5 6 :AB: 8 2
Channel : 6
Frequency : 2 . 4 3 7
ESSID : ”UA−Google−WiFi”

TIME : [ 1 4 : 3 8 : 0 3 ]

TIME : [ 1 4 : 3 8 : 1 3 ]
...
TIME : [ 1 4 : 4 0 : 1 3 ]

TIME : [ 1 4 : 4 0 : 2 8 ]
Address : CC: F4 : 1 1 : 6A: B6 : 8 7
Channel:11
Frequency : 2 . 4 6 2
ESSID : ”UA−Google−WiFi”
...

Initially, the router was on channel 6. After restarting, it selected channel 11 instead, since on channel
6 traffic was being generated by the separate network.

When the access point was disconnected instead of the router, there did not occur any change in channel:
channel 6 was reused after reboot even though there was interference on this channel.

When all Google Wi-Fi devices were disconnected, only the router changed to channel 11. the access
point persisted on channel 6.

4.2.1.2 Channel Selection Based on Traffic only

The same setup was used as in the previous experiments with one difference: the Monitor PC was con-
nected to the Google Wi-Fi network. Traffic was being generated on the separate network (the OpenWRT
Network in this case) while the Monitor PC ran the custom script in order to detect changes in channel.
These experiments ran for quite a long time over night.

Two different variants were executed. Once, there was no traffic being generated on the Google Network
and once, there was traffic being generated on the network using iperf3 on the Monitor PC. The Monitor
PC connected to a public iperf3 server in this case.

Results Without Traffic on Google Wi-Fi

These experiments had to run for quite a long time before something changed. The first iterations of
this experiment ran for approximately 10 minutes without any change in channel.

When running for a long time over night however, changes in channel were recorded as can be seen in
the snippet of output below. It took 105 minutes before a channel change happened.
...
TIME : [ 0 1 : 2 9 : 0 0 ]
Address : CC: F4 : 1 1 : 6A: B6 : 8 7
Channel : 1 1
Frequency : 2 . 4 6 2
4.2. CHANNEL SELECTION/SWITCHING 35

ESSID : ”UA−Google−WiFi”

TIME : [ 0 1 : 2 9 : 1 3 ]
Address : CC: F4 : 1 1 : 6A: B6 : 8 7
Channel : 1 1
Frequency : 2 . 4 6 2
ESSID : ”UA−Google−WiFi”
−−
Address : CC: F4 : 1 1 : 6A: B6 : 8 7
Channel:6
Frequency : 2 . 4 3 7
ESSID : ”UA−Google−WiFi”

TIME : [ 0 1 : 2 9 : 2 5 ]
Address : CC: F4 : 1 1 : 6A: B6 : 8 7
Channel : 1 1
Frequency : 2 . 4 6 2
ESSID : ”UA−Google−WiFi”
−−
Address : CC: F4 : 1 1 : 6A: B6 : 8 7
Channel : 6
Frequency : 2 . 4 3 7
ESSID : ”UA−Google−WiFi”

TIME : [ 0 1 : 2 9 : 3 8 ]
Address : CC: F4 : 1 1 : 6A: B6 : 8 7
Channel:6
Frequency : 2 . 4 3 7
ESSID : ”UA−Google−WiFi”

TIME : [ 0 1 : 2 9 : 5 1 ]
Address : CC: F4 : 1 1 : 6A: B6 : 8 7
Channel : 6
Frequency : 2 . 4 3 7
ESSID : ”UA−Google−WiFi”
...

In another run of the experiment, both the access point and the router changed channels, after 1 hour
and 23 minutes and after 2 hours and 26 minutes respectively.

Results With Traffic on Google Wi-Fi

Finally, it was checked whether there was a noticeable difference when there was an active stream of
data on the Google Wi-Fi network. In total, 4 runs of this experiment were done.

Experiment no. Experiment details Channel change

1 Start time [00:18:22] D
End time [09:06:07]
2 Start time [09:47:45] D
End time [12:37:54]
3 Start time [10:01:41] X
End time [23:56:27]
4 Start Time [08:07:51] X
End time [11:20:42]

A channel change was detected in the first and second run. In the third and fourth iteration, no channel
change happened.

The change in channel had a (positive) impact on the throughput that was achieved by the iperf3 client
running on the Monitor PC. By taking a look at the following graph for example, it can be seen that after
approximately 2.5 hours (9000 seconds), the average throughput increases significantly (approximately
×2). At the same time, the channel changes can be seen in the output of the script.
36 CHAPTER 4. CHANNELS

Figure 4.7: Change in throughput after channel switch

4.2.2 Conclusion

It is very hard to get an accurate conclusion from the conducted experiments. Interference does have
an impact on the performance of the network, so we would expect that there is software on the Google
Wi-Fi devices that tries to mitigate this.

Channel changes are quite a costly operation as the connected clients may experience an impact on it.
This might be the explanation for why it takes so much time before a change happens. Further, the times
at which a channel change occurs are far from consistent. It looks like that a channel must experience
heavy load for at least one hour before any action is taken. When actions are taken, and the channel
changes, an improvement in terms of throughput can be noticed.

Finally, it looks like there is no distinction between when there is an active client connected to the Google
Wi-Fi network and when the network is idle.

4.2.3 Side Note

The used script for some of these experiments makes use of the iwlist command. In many of the output
files, it can be seen that instead of one channel, multiple channels originated from the same device, which
is highly unlikely to be possible.

To test whether this happens due to the iwlist command needing some time before the change is
propagated completely, or whether this is something implemented by Google, a small experiment is
created to find this out. The setup is given in figure 4.8.
4.2. CHANNEL SELECTION/SWITCHING 37

Figure 4.8: Small experiment related to iwlist issue

The Monitor PC is used to run an altered version of the scan-channel.sh script which, instead of the
Google Wi-Fi channel, monitors the OpenWRT channel. When changing the channel of the OpenWRT
network manually, it can be seen that the output of the script showed similar results as before: two
channels were detected from the same access point. As a short conclusion: iwlist needs some time
before a change in channel is propagated completely.
38 CHAPTER 4. CHANNELS
Chapter 5

Handovers

In this chapter, experiments related to handovers are explained.

What causes a handover to occur and how are those handovers instantiated? Does the client device
instantiate the handover or does a Google Wi-Fi device instantiate it? An answer to questions like this
are sought in this chapter.

5.1 Experiments

Two different sets of experiments were executed. In the first experiment, a client device (PC 1) physically
moved away from one Google Wi-Fi device to the other. In the other experiment, a huge amount of
traffic was generated on the channel of one device. Then, it was checked whether the Google Wi-Fi
network decided to move the client device to another device.

Both iperf3 log files as the output of the scan-power.bat script are visualized. This is done with the
same custom Python script that can be found on the Gitlab repository under scripts/visualizers/.

39
40 CHAPTER 5. HANDOVERS

5.1.1 Move Client Away from Google Device

Figure 5.1: First experiment

In these experiments (figure 5.1), the client (PC 1) physically moved back and forth between the Google
Wi-Fi AP and the Google Wi-Fi Router.

In the first experiment, PC 1 ran a custom written script called scan-power.bat. It monitored the signal
strength over time. Note that it is a Windows only script as PC 1 has Windows installed only. A Linux
script is written as well, but this one is not used in experiments. The output format of the Linux script
differs from the Windows version and can thus not be visualized with the visualizer scripts. The script is
not 100% reliable either. It uses the netsh command which sometimes fails to detect the signal strength
accurately. Sometimes, the signal strength did not change over time, even though the distance between
the access point and the client device became significant.

The 5.0 GHz capability of PC 1 is disabled for the experiments in this chapter. This is to ensure that
all handover related traffic is sent on the 2.4 GHz band.

Apart from this script, PC 1 ran an iperf3 [4] client which was connected to a public iperf3 server.

The Monitor PC used Wireshark [11] to monitor the traffic that is being sent during the experiment.
Capture filters were used to filter out all traffic that did not come from the access point or the router.

The first experiment was executed four times in total. The differences between each execution are listed
below.

1. Did not use an iperf3 client on PC 1.

2. Used an iperf3 TCP client on PC 1.

3. Used an iperf3 UDP client on PC 1 with the bandwidth option set to 1G.
5.1. EXPERIMENTS 41

4. Used an iperf3 UDP client on PC 1 without using the bandwidth option.

Figure 5.2: Second experiment

The second experiment (figure 5.2) was the same as the previous, with the difference that now a local
iperf3 server is used instead of a public one.

Three variants of this experiment were executed two times each. They were executed two times because
the results were not always very consistent. (For example sometimes handovers did no occur while they
should).

1. Used an iperf3 TCP client without any parameters on PC 1.

2. Used an iperf3 UDP client with the bandwidth option set to 1G.

3. Used an iperf3 UDP client with no special options.

The output of the scripts can be found in the Gitlab repository under script-outputs/handovers/experiment-1/.
Capture files are stored under capture-files/handover/experiment-1/.

5.1.1.1 Results

Experiment Variant 1

From the generated output files, it can be seen that handovers did occur. In the graph (figure 5.3), they
are indicated by a red dot. Some information on these handovers is given below the figure in text.
42 CHAPTER 5. HANDOVERS

Figure 5.3: First iteration signal strength (%) over time (s)

Changes i n BSSID
1 . c c : f 4 : 1 1 : 6 a : b6 : 8 7 −> f 0 : 7 2 : ea : 5 6 : ab : 8 2 ( 1 9 0 s )
2 . f 0 : 7 2 : ea : 5 6 : ab : 8 2 −> c c : f 4 : 1 1 : 6 a : b6 : 8 7 ( 3 4 0 s )

From this first experiment two different handovers are present, as expected. With the first handover
however, the signal strength seemed to be dropping after the handover which does not really make much
sense. This was probably due to the script being not that accurate. The second handover on the other
hand, shows behavior we would expect: the signal strength drops, and after the handover, the signal
strength is higher again.

The other visualized output files can be seen in figures 5.4, 5.5 and 5.6.

Figure 5.4: Second iteration results. Left: signal strength (%) over time (s). Right: bandwidth
(Mbit/sec) over time (s)

Changes i n BSSID
1 . c c : f 4 : 1 1 : 6 a : b6 : 8 7 −> f 0 : 7 2 : ea : 5 6 : ab : 8 2 ( 3 9 s )
2 . f 0 : 7 2 : ea : 5 6 : ab : 8 2 −> c c : f 4 : 1 1 : 6 a : b6 : 8 7 ( 1 3 2 s )
5.1. EXPERIMENTS 43

Figure 5.5: Third iteration results. Left: signal strength (%) over time. Right: bandwidth (Mbit/sec)
over time (s)

Changes i n BSSID
1 . c c : f 4 : 1 1 : 6 a : b6 : 8 7 −> f 0 : 7 2 : ea : 5 6 : ab : 8 2 ( 1 2 8 s )
2 . f 0 : 7 2 : ea : 5 6 : ab : 8 2 −> c c : f 4 : 1 1 : 6 a : b6 : 8 7 ( 3 0 9 s )

Figure 5.6: Fourth iteration results. Left: signal strength (%) over time. Right: bandwidth (Kbit/sec)
over time (s)

Changes i n BSSID
1 . c c : f 4 : 1 1 : 6 a : b6 : 8 7 −> f 0 : 7 2 : ea : 5 6 : ab : 8 2 ( 2 4 2 s )
2 . f 0 : 7 2 : ea : 5 6 : ab : 8 2 −> c c : f 4 : 1 1 : 6 a : b6 : 8 7 ( 3 2 1 s )

From these files, a notable change in throughput always occurs right before (and after) handovers. From
the second iteration (figure 5.4), it is hard to see because the iperf3 client and the script started
on different times. In the other two iterations, both started on approximately the same time, so the
handovers can be aligned with the change in throughput.

Especially in the third iteration (figure 5.5), a clear difference is notable. At the time of the handover,
throughput drops. Right after it, the throughput peaks to catch up for the time that the client was
changing from one device to the other.

In the fourth iteration (figure 5.6), this is harder to see since here the throughput is in Kbit/sec rather
than Mbit/sec.

Looking at the capture files (figure 5.7), a reassociation request can be found which is sent by the client
device (PC 1) in order to perform the handover.
44 CHAPTER 5. HANDOVERS

Figure 5.7: Capture file example of iteration 2

Experiment Variant 2
Results are given in the figures 5.8, 5.9 and 5.10. They are very similar to the results of the previous
experiment which confirms its findings.

Figure 5.8: The two executions of variant 1. Left: signal strength (%). Right: bandwidth (Mbit/sec).
5.1. EXPERIMENTS 45

Figure 5.9: The two executions of variant 2. Left: signal strength (%). Right: bandwidth (Mbit/sec).

Figure 5.10: The two executions of variant 3. Left: signal strength (%). Right: bandwidth (Kbit/sec).

Note that for some reason, there is only one handover monitored in the first execution of variant 3. The
reason for this is unclear.
46 CHAPTER 5. HANDOVERS

Looking at the capture files generated by Wireshark (figure 5.11), the same reassociation requests as
in experiment 1 are present. After this, a new authentication session is initialized using the EAPOL
protocol.

Figure 5.11: EAPOL packets after reassociation request

5.1.2 Interference Based Handovers

Figure 5.12: Third experiment

The goal of this experiment (figure 5.12) was to detect whether a handover occurred because the link of
one device was saturated. The OpenWRT Network was used to generate interference. PC 1 was connected
to a public iperf3 server.

The output of the scripts can be found in the Gitlab repository under script-outputs/handovers/experiment-2/.
Capture files are stored under capture-files/handover/experiment-2/.
5.1. EXPERIMENTS 47

5.1.2.1 Results

Unfortunately no interesting results were found from this experiment. Handovers based on interference
sometimes happened but it is very inconsistent in how it happened.

Due to some occasional issues with Wireshark on the used monitor devices, the capture files for these
experiments are missing.

5.1.3 Conclusion

Note that in these experiments only 2.4 GHz is monitored. Due to a lack of devices, it was not possible
to capture both 2.4 GHz and 5.0 GHz at the same time. No conclusions can be derived for the 5.0 GHz
band.

In all recorded cases of handovers, it was instantiated by the client device. It sends a reassociation
request to the device it currently is connected to. This device sends a reassociation response. After
this, the client authenticates to the new device it wants to connect to using the EAPOL procedure to
exchange security parameters. Note that it is not required to re-enter the passphrase of the Google
Wi-Fi network.

From the graphs generated by the experiments, it can be concluded that a handover is not 100% seamless.
For a short period of time, a significant change in throughput is recorded. This change in throughput,
however, does not last long (usually not more than 1 second). As a result, for a normal user, the
procedure happens seamlessly as he/she cannot see it. The procedure itself is a hard handover, as the
client devices briefly disconnects from the network after which it connects to the other device.

Further, we have seen that sometimes a handover can occur to optimize the mesh network under heavy
interference. It was very hard to test this thoroughly though. Such a handover is only useful if the
Google Wi-Fi AP and Google Wi-Fi Router use a different channel, which is not always the case. It is
not possible to change the used channel manually, which made things more difficult. Further, a handover
based on interference does not happen consistently. A conclusion for handovers based on interference is
hard to formulate.

Finally, it is important to notice that for each experiment, a capture filter is used. It is entirely possible
that some important information is not measured by doing so. Due to a lack of time, no more experiments
could be performed to gather more information about this.
48 CHAPTER 5. HANDOVERS
Chapter 6

Band Steering

In this chapter, the experiments and their results are described regarding band steering. Experiments
were made to detect whether there is some way in which Google Wi-Fi determines which band is the
most appropriate for the connected clients.

6.1 Experiments

Two sorts of experiments were conducted for this chapter.

The graphics in this section were generated using the custom Python script again. It can be found in
the Gitlab repository under scripts/visualizers/.

The results of the scripts are stored in the Gitlab repository under script-outputs/band-steering/.
Capture files are under capture-files/band-steering/.

6.1.1 Band Steering Based on Client Distance

The first experiments measured whether the band changed when the client moved further away. For this,
the following setup was used.

Figure 6.1: First experiment for band hopping

49
50 CHAPTER 6. BAND STEERING

This experiment (figure 6.1) is executed four times in total. In the first two iterations, PC 1 ran an iperf3
[4] client which connected to a public server. For the second two iterations, no traffic was being generated
by PC 1. In all iterations, PC 1 ran the custom script to measure the power level (scan-power.bat).

While the experiments were executed, both the Monitor PC and the Intel NUC monitored the air. Both
channel 1 and channel 36 were monitored respectively.

6.1.1.1 Results

The results of the first iteration are shown in the graphics of figure 6.2.

Figure 6.2: Signal strength plot and throughput (in Mbit/sec) plot

c h a n n e l change :
1 . 36 −> 1 ( 1 0 6 s )

From the plot on the left, it can be seen that the largest drop in throughput is around 105 seconds, which
is exactly the time at which the frequency band changed. After changing bands, the signal strength
increased again. When slowly moving back, closer to the access point, the band did not change back to
5.0 GHz though. This does make sense as changing channels (or bands) is quite a costly operation. It
is not entirely seamless so it is entirely possible that Google decided to not change to 5.0 GHz as there
was an active client on the network.

Unfortunately, the iperf3 log of the second iteration did not save correctly. The signal strength plot
shows similar behavior as before.

Figure 6.3: Signal strength plot of second iteration

6.1. EXPERIMENTS 51

c h a n n e l change :
1 . 36 −> 1 ( 1 4 9 s )

When there was no traffic being generated by PC 1, the signal strength plots did not differ.

Figure 6.4: Signal strength plots of third and fourth iteration without traffic from PC 1

Capture files
By analyzing the capture files we can learn how this change of band happened.

Figure 6.5: Deauthentication on channel 36

In the part of the capture file shown in figure 6.5, it is visible that the Google Wi-Fi Router (cc:f4:11:6a:b6:83)
sent some deauthentication frames to the client device (b0:35:9f:2b:9e:bd). The reason code in this frame
is set to 0x0002 (previous authentication no longer valid). It is not clear how the router decided to send
these messages. Note that there are action frames transmitted from the router as well. These action
frames originated from BSSID ce:f4:11:6a:b6:81. The data in these frames is encrypted and thus useless.

Figure 6.6: Authentication on channel 1

When the client got kicked by the router on channel 36, it authenticated on channel 1 (see figure 6.6)
instead. The responsibility is by the client device as it has to send a new probe request to the Google
Wi-Fi Network. It does this by setting the SSID tag under the tagged parameters of the probe request
frame. The router responded with a probe response. Then the client sent an authentication frame to
which the router responded as well. After this, a reassociation request is sent by the client, to which the
router responded. Then, the EAPOL procedure is used to set the security related parameters.
52 CHAPTER 6. BAND STEERING

6.1.2 Band Steering Under Heavy Interference

The goal of the second set of experiments was to check whether there is some form of band steering when
a channel was experiencing heavy interference. First, the setup of figure 6.7 was used.

Figure 6.7: First experiment for band steering

The core of the experiment was the same as in the previous section. In addition, the OpenWRT Network
was setup to use a common channel with the Google Wi-Fi Network (channel 36). Smartphone 1
executed an iperf3 client which connected to a public server. Instead of executing iperf3 a simple ping
command was issued from PC 1 instead.

Important to note is that both networks used the same outgoing link to connect to the internet. Both
networks were connected by cable with the same network switch that connected to the internet. This
had an important influence on the results of the experiment.

In this experiments, PC 1 was disconnected initially. When everything was setup (both monitoring
devices, interference...), it was connected to the Google Wi-Fi Network to check which band is picked.
The distance between PC 1 and the router was not greater than 2 meters.

In total, this experiment is conducted 6 times.

To avoid the problems that arose with the previous setup, a new setup was created (figure 6.8).
6.1. EXPERIMENTS 53

Figure 6.8: Second experiment for band steering

In this setup, only the Google Wi-Fi Network was connected to the internet using the same link as before.
The OpenWRT Network contained a local iperf3 server and client (setup by PC 2 and Smartphone 1
respectively).

This setup was used for four iterations of experiments.

6.1.2.1 Results

The first setup is used 6 times in total. The graphics in figure 6.9 show to which channel the client
connected in each iteration.
54 CHAPTER 6. BAND STEERING

(a) first iteration (b) Second iteration

(c) Third iteration (d) Fourth iteration

(e) Fifth iteration (f) Sixth iteration

Figure 6.9: Channel change over time

The most obvious thing that should happen is that the client is immediately connected to the band with
the least interference (2.4 GHz on channel 1). In the six cases, only two of them followed this obvious
approach, the fifth and sixth iteration.

In some cases, the client started connected to the 5.0 GHz band (channel 36), in the first, second and
fourth iteration. The logical choice for Google is to switch to the 2.4 GHz band quickly, but this only
happened in the first iteration. In the second and fourth iteration, it kept trying to send on the 5.0 GHz
6.1. EXPERIMENTS 55

band.

The third iteration displayed the most strange behavior. During this experiment PC 1, the client,
disconnected entirely from the access point. When reconnecting, it did not reconnect to the 2.4 GHz
band, but picked the 5.0 GHz band again (channel 36).

To test whether a performance difference can be seen, a ping command was started from PC 1. Most
of these requests timed out. At first, this looked like extremely strange behavior, but an explanation is
rather trivial. Since both the Google Wi-Fi Network and the OpenWRT Network were connected to the
internet on the same link, congestion did not happen in the air between the two networks, but on the
common link instead.

The second experiment should confirm this.

Second Setup
First, a ping command was issued without any interference to check what the performance was under
normal circumstances. This command was issued when PC 1 was connected to the 5.0 GHz band without
interference.
Ping s t a t i s t i c s f o r 1 7 2 . 2 1 7 . 1 6 8 . 2 3 8 :
P a c k e t s : Sent = 2 9 , R e c e i v e d = 2 8 , L o s t = 1 (3% l o s s ) ,
time =27ms Approximate round t r i p t i m e s i n m i l l i −s e c o n d s :
Minimum = 19ms , Maximum = 49ms , Average = 22ms
TTL=116

In total, this setup was used for four iterations. Only in the first iteration, PC 1 connected to the 2.4
GHz band (channel 1) instead of the 5.0 GHz band (channel 36). A ping command was issued in all
iterations. The results of the first and third iteration are given below.
FIRST EXECUTION (CH 1 )
−−−−−−−−−−−−−−−−
Ping s t a t i s t i c s f o r 1 4 2 . 2 5 0 . 1 7 9 . 2 0 6 :
P a c k e t s : Sent = 6 8 , R e c e i v e d = 6 8 , L o s t = 0 (0% l o s s ) ,
Approximate round t r i p t i m e s i n m i l l i −s e c o n d s :
Minimum = 18ms , Maximum = 35ms , Average = 22ms
−−−−−−−−−−−−−−−−

THIRD EXECUTION (CH 3 6 )

−−−−−−−−−−−−−−−−
Ping s t a t i s t i c s f o r 1 4 2 . 2 5 0 . 1 7 9 . 1 7 4 :
P a c k e t s : Sent = 4 8 , R e c e i v e d = 4 8 , L o s t = 0 (0% l o s s ) ,
Approximate round t r i p t i m e s i n m i l l i −s e c o n d s :
Minimum = 25ms , Maximum = 89ms , Average = 42ms
−−−−−−−−−−−−−−−−

We see that the average round trip time is almost doubled when the 5.0 GHz band is experiencing heavy
interference. It is strange that only in one out of four iterations, the Google devices decided to pick the
2.4 GHz band over the interfered 5.0 GHz band.

Capture Files
Nothing interesting was found in the capture files. There are no management frames found which
indicated the choice for the band.

6.1.3 Conclusion

A change in the frequency band can happen in two ways: when a client moves out the range of the 5.0
GHz band or when a band is experiencing high traffic load. From the experiments, the latter seems to
be quite inconsistent. In some cases, the band without interference is picked. However, most of the time,
56 CHAPTER 6. BAND STEERING

the interfered 5.0 GHz band is still preferred. There are no management frames captured that indicate
or explain this choice.

When the client device moved out the range of the 5.0 GHz band on the other hand, more information
was found from the experiments. From the capture files we know that the procedure is started by the
access point itself by sending a deauthentication frame to the client. Then the client device reconnects
by sending a new probe request on the other band. The entire process is shown schematically in the
next figure.

Figure 6.10: Band hopping process

Chapter 7

Power Management

In this chapter we check whether Google Wi-Fi does some form of power management.

7.1 Experiments

No new experiments were created for this chapter. The official standard [1] states that power related
information is attached to the mesh configuration report which is already captured in chapter 3.

It is thus sufficient to look at the capture files we have created there to get some information about the
power management that does (or does not) happen.

For convenience, the capture files are copied to capture-files/power-management/ in the Gitlab repos-
itory.

7.1.1 Results

From the capture files of chapter 3, we can extract the information shown in figures 7.1, 7.2 and 7.3.

Figure 7.1: Mesh configuration report

57
58 CHAPTER 7. POWER MANAGEMENT

In the mesh configuration report, there is a flag that indicates how many devices of the mesh are in deep
sleep mode. In all capture files, this flag is set to 0 (None of the peer-specific power modes is deep sleep
mode).

Figure 7.2: Fixed parameters

Under the capabilities field under the fixed parameters, there is a flag that indicates whether automatic
power save delivery [8, 7] is active. The flag is set to 0, indicating that it is not implemented on the
device (both the Google Wi-Fi Router as the Google Wi-Fi AP do not support this).

Figure 7.3: HT Capabilities

Finally under the HT Capabilities field, there is a flag that specifies whether HT SM Power Save [7] is
enabled. In this case, it is disabled.

7.2 Conclusion

Since in all capture files, everything related to power management is disabled, it is safe to assume that
Google Wi-Fi does not have any support in power management options.
Chapter 8

Reflection on the Project

The project did not go very fluent at all times. Quite some issues and problems were encountered while
preparing or performing experiments. In this chapter, I provide a short reflection on how I felt the
research project went with a focus on the process and the encountered problems.

8.1 Problems

The first problem is introduced thanks to COVID-19. The measurements by the government did not
allow me to go to the university buildings, as consequence I could not create a persistent setup of devices
that I could use for my project. I had to take everything home and install everything there. A lot of
time is lost with rebuilding the setups for some experiments, as a persistent setup is infeasible at home.

Apart from this, another problem was encountered: a lack of physical devices to perform experiments
with. Since I could not go back and forth between campus and home that easily, I could only use the
devices that I have available myself. The main problem was that I had only one computer with a UNIX
based OS (Monitor PC). This laptop however, only supported 2.4 GHz. This last problem was solved
by the Intel NUC I could borrow, quite late in the project.

Further, for many experiments, a lot of client devices were required (for example to generate traffic,
running iperf servers...). I managed to gather all devices we still have at home, but for some more
complex experiments, it was barely enough.

During some experiments, some other technical difficulties were encountered. The public iperf3 servers
for example, were not that reliable. Sometimes it was hard to find a reliable server to use. This could
have been solved if there were enough devices to run both servers and clients locally.

Another technical difficulty that showed up was the fact that sometimes, a monitoring interface crashed.
This resulted in incomplete or even empty capture files that were not usable.

8.2 Process Reflection

In general, I am quite pleased with the progress I have made throughout the year. At the start, I did
not have any idea of what was expected and how I should tackle this. I tried some things intuitively
and adapted to the feedback of the supervisors as good as I could. Even though not many results were
obtained from the experiments, I learned a lot of new techniques and tools to perform network testing.
Further, I have gained insights in how mesh networks work and what challenges there are to create a
mesh network infrastructure. Specific details were not extracted from the Google devices. Some basic
information is found, and quite some observations were made, but unfortunately, no big conclusions
could be derived.

59
60 CHAPTER 8. REFLECTION ON THE PROJECT

If I look back at things that could have been better, there is one major point to work on in the future: I
should start reading papers way earlier to get a better grasp of what I am investigating. In this project,
I only started reading the official IEEE standard for mesh networks in April, while this should have been
something that had to be done at the start of the project. I was mainly poking around in the dark with
the experiments I created. If I had read more at the start, then maybe I could have come up with more
clever, targetted experiments. Further, I would have saved time in doing so, as I could have known what
to look for. To give an example: in many experiments, I set up a capture filter which filtered out beacon
frames and probe requests/responses, while this were actually valuable frames.

As a conclusion I can say that I am quite proud on the progress I have made in this project. Unfortunately,
not many things were discovered, but learning new techniques and tools is of equal value.
References

[1] Ieee standard for information technology–telecommunications and information exchange between
systems–local and metropolitan area networks–specific requirements part 11: Wireless lan medium
access control (mac) and physical layer (phy) specifications amendment 10: Mesh networking. IEEE
Std 802.11s-2011 (Amendment to IEEE Std 802.11-2007 as amended by IEEE 802.11k-2008, IEEE
802.11r-2008, IEEE 802.11y-2008, IEEE 802.11w-2009, IEEE 802.11n-2009, IEEE 802.11p-2010,
IEEE 802.11z-2010, IEEE 802.11v-2011, and IEEE 802.11u-2011), pages 1–372, 2011.

[2] Aircrack-NG Suite. https://www.aircrack-ng.org/index.html (last accessed: 30/05/2021).

[3] Google Home. https://play.google.com/store/apps/details?id=com.google.android.apps.
chromecast.app (last accessed: 30/05/2021).
[4] iperf3. https://iperf.fr/ (last accessed: 30/05/2021).

[5] Google Nest WiFi specs. https://store.google.com/product/nest_wifi_specs (last accessed:

30/05/2021).
[6] The OpenWRT Project. https://openwrt.org/ (last accessed: 30/05/2021).
[7] 802.11 Power Management with packet capture examples. https://dot11zen.blogspot.com/
2018/02/80211-power-management-with-packet.html (last accessed: 30/05/2021).
[8] WMM APSD On or Off. https://routerguide.net/wmm-apsd-on-or-off/ (last accessed:
30/05/2021).
[9] Privacy: Mac Randomization. https://source.android.com/devices/tech/connect/
wifi-mac-randomization (last accessed: 30/05/2021).

[10] WiFi Analyzer. https://play.google.com/store/apps/details?id=abdelrahman.

wifianalyzerpro (last accessed: 30/05/2021).
[11] Wireshark. https://www.wireshark.org/ (last accessed: 30/05/2021).

61
62 REFERENCES