Wi-Fi Roaming Secrets Revealed – Part 3

Introduction

Part 1 of this series looked at how a device with known roaming behavior worked with a NETGEAR Orbi router and satellite. Part 2 was a deep dive into using Wireshark filters to determine device support for 802.11k,v and r roaming assistance technologies. This third and final part will wrap things up with a look at the roaming behavior of Windows and Android devices.

To recap, the Windows STA is a Lenovo M600 computer running Windows 10 Pro 64 bit with an Intel Wireless-AC 8260 internal adapter with latest 20.40.0.4 driver. I chose this adapter because Intel says the AC-8260 supports 802.11k,v and r and Microsoft says Windows 10 supports 802.11k,v and r (depending on device driver support, of course). Note that I used cable connection between the Intel card and RF splitter, so signal levels were comparable to those I got using the octoScope Pal.

Roaming test setup

The Samsung Galaxy Tab A 8" (2017 version – SM-T380) was chosen because it was found to support 802.11k and v by packet inspection, even though neither is specified.

Intel STA w/ Windows 10

The information that can be extracted from Windows is different than what we can get from an octoScope Pal. It also requires two netsh calls to get WiFi information and IP address. The Wi-Fi information and the command to get it are shown below. For IP address, I used netsh interface ip show config. Note Windows provides only a Signal parameter, not RSSI, so the roaming plots will look a bit different.

Windows netsh command result

Here’s the BSSID decoder for decoding the following Pal logs, RSSI plots and packet captures.

Packet capture inspection confirmed Intel’s spec that the AC 8260 supports 802.11k and v, but I could find no evidence of support for 11r.

With octoScope’s help, I am now able to reliably restart iperf3 traffic if the connection is broken during roaming. So the plot below shows the roam with traffic running throughout. As you can see, Windows’ signal level reporting isn’t very granular, but it appears that the STA tries to keep the signal % above 75%.

Roaming test – Windows STA w/ traffic

The capture file doesn’t have a lot of events, but it has some things we haven’t seen before. One of the two Action frames is expanded to show it’s an 11k Measurement Request issued by Orbi. However, the Intel STA doesn’t respond to the requests.

The other interesting things are that the Intel adapter issues Reassociation requests instead of Association requests and that Orbi doesn’t try to force the Intel adapter to disconnect using Disassociation or Deauthentication.

Packet capture – Windows STA w/ traffic

If we can believe the values in the capture file, it looks like the Intel STA wants to move when its RSSI is -65 to -70 dBm. The first move from the Orbi router’s 5 GHz to 2.4 GHz radio is at -68 dBM and the move to the Orbi Satellite 5 GHz radio is at -70 dBm.

Finally, it looks like Orbi tries to band steer the STA using BSS Transition Management Requests @ 186 and 217, but it doesn’t move before the capture ends.

In all, it looks like the Intel STA and Orbi get along just fine, with relatively quick roams that don’t involve a lot of probing (scanning) by the STA.

Android

Packet captures revealed that the Samsung Galaxy Tab A supports 802.11k and v, but not r. But it was harder to get good roams using the device. I think part of this was the lower signal levels I had to operate with due to the antenna coupling required to connect the tablet to the testbed.

At any rate, the plot below shows the Galaxy Tab stuck to Channel 6, switching to the Orbi Satellite around -75 dBm. I was able to run traffic throughout the test run.

Roaming test – Android STA w/ traffic

The packet capture below doesn’t include the initial STA association. I had to manually connect the tablet before starting the test run and have no way of controlling the connection during testing.

The capture shows the Samsung’s response to a Measurement Report request from Orbi. It’s not very helpful, containing no power or signal-to-noise level or even the BSSID being reported. The Samsung uses a Reassociation vs. Association request when roaming to the Orbi satellite @ 22.3.

Packet capture – Android STA w/ traffic

The Action frames at 59.3 are the Orbi satellite requesting a Beacon Measurement request, which the Samsung answers with the same was as before. The Orbi router tries a Beacon Measurement request again at 87.7 and 110.8, but gets no response.

Although our plot stops around 80 seconds in when the connection drops, the capture continues to run while the script attempts to reconnect. The Samsung finally figures that the connection is dead and deauthenticates and tries to re-establish the connection back to the same AP @ 112.5.

Multiple runs showed no sign of Orbi attempting to band steer the Samsung via BSS Transition Management Requests. Since the tablet provides no band preference controls, I couldn’t see if I could force it to use 5 GHz.

Closing Thoughts

What I hope you take away from this series is that there is no "magic" in Wi-Fi roaming. By design, the STA controls the process, deciding when to roam and where to roam to, depending on algorithms baked into its Wi-Fi drivers. APs can attempt to influence the process by deauthenticating or disassociating the STA to initiate the process. But the STA can decide to connect right back up to the same radio.

Once a STA has decided to roam, an AP can also attempt to influence a roam by delaying or completely withholding responses on a particular radio or AP. But if an AP has previously responded to STA probes, using the "I can’t hear you" trick when the STA comes knocking to connect may result in a dropped connection while the confused STA probes to find a more receptive AP.

The new roaming enhancement standards can be used to shorten roam times, band steer a device or both. But implementations vary widely on both AP and STA and bugs abound. So support for 802.11k,v and r are by no means a roaming panacea. And remember each standard—and the options within the standard—needs to be supported by both AP and STA to work.

Discuss this in the Forums