You can stick to 802.11r only by lowering the transmission power and have all the APs on the same channel, in my tests it ended up switching much faster than K/V. (~75ms)
On iOS, equal channel with correct ESS will switch liberally. On Android 14+ with Broadcom chip it will start conservative, then switch liberally after the first poor signal switch-over event, up until disconnection.
Android (Pixel/Moto) will never switch (even with K/V) on large network activity, only VoIP/video call. It depends on vendor implementation.
I use "dp.logcatapp" log reader while roaming, "ModemStats" shows the score/load and is used on Moto.
Samsung is known to push protocol support early: 802.11r in 2013, 802.11w 2015, some models do not use Android's default connectivity manager.
To add, WPA3 with 802.11r is known to have issues on Apple hardware before 2021 on all iOS versions, many Android devices, especially smart TVs don't support it, will not connect or are unreliable (protected beacon frame), can be searched in buried report results at OpenWrt forum mega threads and Ubiquity. WPA2+FT and forced MFP with a long password is a safe alternative.
802.11K/V is more suitable for campus and load balancing, tuning it based on RSSI and station metrics is very difficult, enterprise hardware rely on network traffic and air time.
Until it gets stuck on a far away AP because it was the first AP to come online the last time the network rebooted.
Not sure if roaming is actually the fix for this problem. For whatever reason my Ring cameras just love connecting to the worst and most far away AP in my house.
Not sure how widely available this feature is, but the unifi controller software for the popular Ubiquiti APs lets you bind individual client devices to specific APs such that they can only connect to the ones you choose.
I had to solve a similar issue for some crap IoT lights that would join the incorrect AP after a power cut every time.
I need my TV to rapidly switch APs in very heavy load wide area networks with thousands of devices while I'm cruising through the venue with my motorized couch and entertainment system.
Now I want to actually build that for GPN24 next week. Wouldn't use AndroidTV for that though.
Good luck watching the office when your cat pushed your upstairs AP off the balcony. Your tv won't auto switch to the downstairs AP which is now closer than the one that's suddenly in the driveway.
> The obvious advice for roaming is “use one SSID everywhere”, and that is often correct if you’re running Wi-Fi in an office, a public venue, or generally somewhere where you don’t have (or care about) legacy devices.
What difference does the presence of legacy devices make? Is the intent to isolate them from modern devices from a network perspective? Then create a separate SSID on both 2.4 and 5 GHz for modern devices.
I can't think of any legitimate reason for split SSIDs anymore. Linux clients used to be pretty bad at preferring 5 over 2.4 GHz if RSSIs were both excellent but 2.4 was slightly better, but I haven't seen that in years.
I don't quite understand the benefit of the setup. If there are legacy IoT devices that need unique named 2.4G network, just broadcast another SSID for them. So each router broadcasts main 5G (common name, fast roam etc), main 2.4G (same as above) and legacy IoT 2.4G (with a different name for each AP, and possibly worse encryption and maybe even TKIP). That wouldn't hold back the network for legacy devices.
I run a single ssid dual band network ... what tends to happen is 5Ghz is effectively ignored. 2.4Ghz has better coverage, so everything wants to live there. At least wifi 6 brought improved encoding to 2.4Ghz.
I haven't had luck with the roaming extensions; when I run them, some of my devices won't connect or won't stay connected and it's a pain to monitor. I guess I could run a different SSID with roaming enhancement, but effort.
This used to be pretty common on at least Linux and Android clients some years ago.
Not sure if they finally got around to making the BSSID selection algorithm a bit smarter or whether all my access points just support active steering at this point, but I haven't seen this in the past couple of years.
When I move from Europe to the US I realized that roaming is not as prevalent here as it is back home. The (mostly) wooden houses enable me to just use one really powerful AP for most of my needs.
I need to spend some time on it but I purchased two Omada APs to pair with my OpenWRT router thinking roaming would just work with mostly Apple devices. That didn’t happen. I’m hoping some of this article applies and I can improve the situation a bit.
For Omada devices, you need a "Controller". You can run the Omada Controller software on an existing computer, get one of their controller devices, or use their cloud-based service, which should be free at your scale.
You can also "just" set the 802.11k entries manually. Add 802.11r and you should be mostly good. Usteer makes it slightly better by moving clients to the best AP when they stay stationary for longer whiles.
Cool! I dont need this anymore since im broke and moved to a 1 room apt. but yeah the ‘set the same ssid’ “trick” def. is not enough and often achieves the opposite effect.
I'd used DAWN for band steering/roaming at my last place, which worked ok. uSteer is a little newer & is an official openwrt project. https://github.com/berlin-open-wireless-lab/DAWNhttps://openwrt.org/docs/guide-user/network/wifi/dawn
DAWN has a wild amount of knobs to tune, which aren't super well described. I haven't been running it since a single AP covers my current place very well. But it would be interesting to go evaluate DAWN & it's config with an LLM, to dice in & see more. uSteer too.
Great write up, good information to share. This really is such an important next step for many people's wifi and it's documentation is pretty so-so.
You can stick to 802.11r only by lowering the transmission power and have all the APs on the same channel, in my tests it ended up switching much faster than K/V. (~75ms)
On iOS, equal channel with correct ESS will switch liberally. On Android 14+ with Broadcom chip it will start conservative, then switch liberally after the first poor signal switch-over event, up until disconnection.
Android (Pixel/Moto) will never switch (even with K/V) on large network activity, only VoIP/video call. It depends on vendor implementation. I use "dp.logcatapp" log reader while roaming, "ModemStats" shows the score/load and is used on Moto.
Samsung is known to push protocol support early: 802.11r in 2013, 802.11w 2015, some models do not use Android's default connectivity manager.
To add, WPA3 with 802.11r is known to have issues on Apple hardware before 2021 on all iOS versions, many Android devices, especially smart TVs don't support it, will not connect or are unreliable (protected beacon frame), can be searched in buried report results at OpenWrt forum mega threads and Ubiquity. WPA2+FT and forced MFP with a long password is a safe alternative.
802.11K/V is more suitable for campus and load balancing, tuning it based on RSSI and station metrics is very difficult, enterprise hardware rely on network traffic and air time.
To be fair, I don't require my 85" TV to roam, as it's not as portable as my iPhone.
Until it gets stuck on a far away AP because it was the first AP to come online the last time the network rebooted.
Not sure if roaming is actually the fix for this problem. For whatever reason my Ring cameras just love connecting to the worst and most far away AP in my house.
Not sure how widely available this feature is, but the unifi controller software for the popular Ubiquiti APs lets you bind individual client devices to specific APs such that they can only connect to the ones you choose.
I had to solve a similar issue for some crap IoT lights that would join the incorrect AP after a power cut every time.
> https://community.ui.com/questions/Lock-Client-to-Specific-A...
Glad it works for you.
I need my TV to rapidly switch APs in very heavy load wide area networks with thousands of devices while I'm cruising through the venue with my motorized couch and entertainment system.
Now I want to actually build that for GPN24 next week. Wouldn't use AndroidTV for that though.
Good luck watching the office when your cat pushed your upstairs AP off the balcony. Your tv won't auto switch to the downstairs AP which is now closer than the one that's suddenly in the driveway.
> The obvious advice for roaming is “use one SSID everywhere”, and that is often correct if you’re running Wi-Fi in an office, a public venue, or generally somewhere where you don’t have (or care about) legacy devices.
What difference does the presence of legacy devices make? Is the intent to isolate them from modern devices from a network perspective? Then create a separate SSID on both 2.4 and 5 GHz for modern devices.
I can't think of any legitimate reason for split SSIDs anymore. Linux clients used to be pretty bad at preferring 5 over 2.4 GHz if RSSIs were both excellent but 2.4 was slightly better, but I haven't seen that in years.
I don't quite understand the benefit of the setup. If there are legacy IoT devices that need unique named 2.4G network, just broadcast another SSID for them. So each router broadcasts main 5G (common name, fast roam etc), main 2.4G (same as above) and legacy IoT 2.4G (with a different name for each AP, and possibly worse encryption and maybe even TKIP). That wouldn't hold back the network for legacy devices.
I run a single ssid dual band network ... what tends to happen is 5Ghz is effectively ignored. 2.4Ghz has better coverage, so everything wants to live there. At least wifi 6 brought improved encoding to 2.4Ghz.
I haven't had luck with the roaming extensions; when I run them, some of my devices won't connect or won't stay connected and it's a pain to monitor. I guess I could run a different SSID with roaming enhancement, but effort.
This used to be pretty common on at least Linux and Android clients some years ago.
Not sure if they finally got around to making the BSSID selection algorithm a bit smarter or whether all my access points just support active steering at this point, but I haven't seen this in the past couple of years.
You can turn down the power on the 2.4GHz radio so it's not as overpowering.
When I move from Europe to the US I realized that roaming is not as prevalent here as it is back home. The (mostly) wooden houses enable me to just use one really powerful AP for most of my needs.
I need to spend some time on it but I purchased two Omada APs to pair with my OpenWRT router thinking roaming would just work with mostly Apple devices. That didn’t happen. I’m hoping some of this article applies and I can improve the situation a bit.
For Omada devices, you need a "Controller". You can run the Omada Controller software on an existing computer, get one of their controller devices, or use their cloud-based service, which should be free at your scale.
The Omada device* I researched also supports standalone mode and hosts the web UI like any other consumer router.
* https://www.omadanetworks.com/us/business-networking/omada-r...
Having the controller is still nice. It's relatively user friendly, and consolidates all the devices and their interfaces under a single UI.
You can also "just" set the 802.11k entries manually. Add 802.11r and you should be mostly good. Usteer makes it slightly better by moving clients to the best AP when they stay stationary for longer whiles.
Cool! I dont need this anymore since im broke and moved to a 1 room apt. but yeah the ‘set the same ssid’ “trick” def. is not enough and often achieves the opposite effect.
I'd used DAWN for band steering/roaming at my last place, which worked ok. uSteer is a little newer & is an official openwrt project. https://github.com/berlin-open-wireless-lab/DAWN https://openwrt.org/docs/guide-user/network/wifi/dawn DAWN has a wild amount of knobs to tune, which aren't super well described. I haven't been running it since a single AP covers my current place very well. But it would be interesting to go evaluate DAWN & it's config with an LLM, to dice in & see more. uSteer too.
Great write up, good information to share. This really is such an important next step for many people's wifi and it's documentation is pretty so-so.
Using only 6ghz, turned off 2.4 & 5. Problem solved.