What's new

Wi-Fi Roaming Secrets Revealed - Part 3

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

thiggins

Mr. Easy
Staff member
roaming_pt3_teaser.png
In the last part of our Wi-Fi Roaming exploration, we look at Windows and Android roams.

Read on SmallNetBuilder
 
anecdotally the behavior of the Galaxy Tab A seems to match the roaming experience of my Galaxy S8... it just doesn't like to roam until connection is nearly or completely lost.

There are a variety of android apps that try to "fix" this behavior by specifying an RSSI level to trigger roaming to another SSID, or just to switch to a different channel in the same SSID.
 
In the end, the conclusion we can draw is that WiFi roaming (mesh) products in the market are just scam based on unreliable hacks to WiFi standards, hacks that mostly are not supported by clients.

We will only have real WiFi roaming (mesh) after having a industry wide standard, when it is widely supported by client and access point hardware. Everything else is just simply gimmicks that won’t really give the expected results to users.

Don’t forget you need two to start a dance. If one doesn’t want, there won’t be a ball. And one of the dancers in this ball are the clients who seem to not willing dance until the definitive rules are set out.

Caveat Emptor.
 
In the end, the conclusion we can draw is that WiFi roaming (mesh) products in the market are just scam based on unreliable hacks to WiFi standards, hacks that mostly are not supported by clients.

We will only have real WiFi roaming (mesh) after having a industry wide standard, when it is widely supported by client and access point hardware. Everything else is just simply gimmicks that won’t really give the expected results to users.

Don’t forget you need two to start a dance. If one doesn’t want, there won’t be a ball. And one of the dancers in this ball are the clients who seem to not willing dance until the definitive rules are set out.

Caveat Emptor.
I would not say it is a scam. You are seeing the difficulty of trying to add significant new functions to a standard that was never designed with them in mind.
 
I would not say it is a scam. You are seeing the difficulty of trying to add significant new functions to a standard that was never designed with them in mind.

Call it marketing mumbo jumbo or over promising when they actually know the limitations of their solutions, unable to deliver until there’s a industrywide standard that’s is implemented on the client side too.

A standard is in fact possible as CISCO have proven using its own access point and clients, also the telecom division of Siemens have done a long time ago with its roaming protocol to seamlessly move voice calls among their own antennas using its own series Gigaset (digital compatible DEC - 2,4 MHz) wireless phones and before all of them by Ericsson in its MD110 series of PBXs that could be extended with wireless antennas that supported seamless roaming, first over analog and then over their own DEC compatible 2,4 MHz handsets.

Roaming does not depend directly on the lowest level protocol of the underlying technology but on upper lalevel protocols that need to support how it behaves. And the power of the hub (could be every client in a mesh network, an overkill) to support the control of the whole mesh and the seamlessly handing off of the devices from one access point to another..
 
Is it mandated that companies making access points follow the standards? Why can't one company say "forget the standards", and find a workaround to take more control over roaming?
If the standards are not doing what is needed to provide the best user experience, then wouldn't it become a selling point for a company to deviate from it, as long as the user devices can still connect to the AP without trouble?

Many other parts of the tech industry have done this, for example, motherboard makers using certain chipsets in undocumented and to enable overclocking on chipsets that otherwise would not support it.
 
Standards are not mandatory. Government rules like Tx power and operating frequencies are.

No one has a magic wand they can wave to quickly fix the problem.
 
These articles are timely from some recent issues I have experienced. I recently installed an Asus AC86U at a friends house that also serves as a B&B. The primary purpose for the AC86U was to setup OpenVPN client to get circumvent Geo-restrictions for some streaming media.

He has two Ubiquity APs outside. The APs had different SSID names from the main router. So while I was onsite, I suggested they rename the APs SSIDs and make them the same name as the SSID on the Asus Router. All SSIDs are using different channels. The goal was to make their roaming experience more seamless by having their device automatically connect to the Router or AP SSID with the strongest signal. It does not appear to work for them. I now regret suggesting this as I have had several calls since then complaining about connectivity issues.

They are primarily an iOS household. When they are inside the main room where the Asus router is located, all is good. But when they go outside, they have connectivity issues. I first thought it was an iOS issue. I did not have any issues with my Android phone. On Wednesday, I unchecked the SmartConnect feature on the Asus Router and renamed renamed the SSIDs on the Asus router so they differ from the Ubiquity APs. They now see a separate 2.4 Ghz and 5 Ghz channel. Similar to how it was setup prior to me making the change. I also did this to help me determine where the problem is.

So yesterday, I went to the school I support. I also have SmartConnect enabled on the AC88U. There is a D-Link AP at the end of the building. The AC88U is in the middle of the building. I was working at the end of the building where the D-Link AP is located. I have some WiFi Analyzer Apps installed on my Android phone. As I moved away from the D-Link and moved to the other end of the building, my Android persisted on using the signal from the D-Link and not the AC88U. I would have expected my Android to see the stronger signal from the AC88U and switch to that source. But it did not. I also unchecked the SmartConnect feature on the Asus to have separate 2.5 Ghz and 5 Ghz SSIDs and restested. No change.

I can relate to @abetancort posts after this experience. And after reading the articles, I am not sure there are any settings on the Asus or APs I can change to make roaming work as one would hope. The D-Link AP is old and perhaps an updated one may help? From reading the articles, it appears roaming behavior is controlled by the device and not so much the settings on the AP or Router. It would also be interested in updating the article to include iOS devices.

Thank you @thiggins for this website and the great articles you have produced. They have really helped me the past few years. I hope you also launch a YouTube Channel in the future!

Update: The Asus 86U and Ubiquity AP issue is hopefully solved now. I called in the Network Engineer who installed the devices. The Pico Station used by the Ubiquity devices had a problem. Because of the language barrier, I am not sure what the issue was. But it appears to be fixed now. Whew.
 
Last edited:
Xentrk: Look at your signal levels. iOS devices won't switch until signals fall below -70 dBm. Make sure the OS is up to date.

Smart connect is useful for band steering IN THE AP, not for roaming.
 
@thiggins

I am currently making use of the TP-Link Deco M9 Plus system. I've been kind of disappointed with the raw performance and configurability relative to the Netgear Orbi RBK50 kit that I've been testing in my parents' home. However, the one thing I love about the Deco and the Orbi systems is that they both support 802.11k+v with the option to turn on 802.11r.

While shopping for this system, I did some research on client devices and their support of these protocols. It's a mixed bag on the Android side of things, with Samsung devices basically having a much higher likelihood of supporting them.

However, what I found for Windows 10 specifically was intriguing, and it may shed some light on why there were issues with the Lenovo making use of Fast BSS Transition (802.11r) in these tests.

The Intel Wireless-AC cards have had support for 802.11r/k/v for a fair while, with 802.11r being the most recent addition. However, it's important to recognize that while Intel may fully implement these protocols in the driver, Microsoft does not completely implement them in Windows. 802.11k+v are fully implemented, but 802.11r is not:

https://docs.microsoft.com/en-us/wi...st-roaming-with-802-11k--802-11v--and-802-11r

  • "Windows 10 supports Fast BSS Transitions over networks using 802.1X as the authentication method. Pre-Shared Key (PSK) and Open Networks are currently not supported."
This may explain why there wasn't a fast transition in the tests. The argument is that the WPA2 handshake isn't as costly from a time perspective when a PSK is in use (I call B.S. when on WiFi Calling, but hey, who am I?). The real time sink comes from the processing of authentication against a back-end server like RADIUS. Therefore, Microsoft chose to only implement 802.11r where it is most necessary. Although if you ask me, this just sounds like pure laziness. However, with support for 802.11r coming out in more and more consumer equipment, I expect we will see a full 802.11r implementation in Windows in the coming years, especially with the dawn of 802.11ax.
 
The 802.1x limitation isn't surprising. 11k,v and r all incorporate many optional methods. There's a lot of stuff packed in there.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top