Is it possible to raise a single Wi-Fi network with seamless roaming on access points with OpenWRT?

Question

linux

At the moment, there are several TP-Link access points with OpenWRT firmware installed. All of them are set to the same SSID and connected via a wired connection to the same network, which has a router and a DHCP server. This approach has shown itself only from the bad side for the entire time of its existence: laptops constantly lose connection while in one place, and mobile devices very rarely decide to switch to a nearby access point with a better signal and instead remain at the most distant one.
I perfectly understand that there are solutions from the same D-Link or Ubiquiti that will solve this problem, but such a pleasure is too expensive. After all, nothing is impossible with Linux.

Answer 1

It seems like you managed to find what you wanted . Unfortunately, in OpenWRT this section cannot yet be configured via UCI, but manually adjusting the hostapd settings is not difficult.
UPD: Now it's still possible. The developers have added the ability to configure 802.11r Fast Roaming via UCI .

Answer 2

I studied this topic for a long time and painfully (starting my journey with about the same question as you), but I am not a professional. I will be glad to remarks and criticism.
In short - the problems described in the body of the question do not correlate with the title and the direction of digging towards, to put it mildly, the ambiguous and blurry term "roaming". For a quick understanding of the topic, it is better to temporarily remove this word from the vocabulary. Note, by the way, that in serious articles they write at least fast roaming, and not just roaming or seamless roaming.
There are also two controversial prepositions, I'll start with them.
one.

Unified Wi-Fi network

If you have WPA2-PSK, and if you don’t consider exotic things that are of little use in our life, like the same MAC address on different APs and mesh networks of different levels, then you already have a “single” Wi-Fi network. No less common than very rich uncles with Cisco and Juniper, and less rich with D-Link and Ubiquiti. This is me to the fact that there is no silver bullet that solves the problems you describe. An AP group with any feature whose description contains the word "roaming" will still remain an AP group.
2.

There are solutions from the same D-Link or Ubiquiti that will solve this problem.

PMKID caching - what vendors used to call seamless roaming (more honestly - Ubiquiti's zero handoff), solves another problem - long authentication "from scratch" when switching the client to another AP, if not PSK is used (there is no such problem there ), and EAP is the authentication method. By caching part of the key and accessing the cache from all APs. At the same time, such a solution may not have 802.11k/802.11r.
3. 802.11k/802.11r may already be in OpenWRT (more precisely, hostapd), but this will not help us much. Firstly, there is no clear description of what kind of hardware is needed for this, there are no instructions on how to set it up, it is not even clear whether it needs to be set up. Secondly, there are still very few wireless clients on the market that support 802.11k/802.11r. Thirdly, it’s not a fact that if all this takes off, there will be a lot of sense.
4. The fact is that, with the exception of special rare expensive vendor-locked wireless clients, the client always voluntarily decides to change the AP , and not the AP or some controller. The AP can only advise the client about its 802.11k neighbors.
5. As far as I understand, 802.11r is an advanced standardized version of PMKID caching, which speeds up the authentication process when switching to another AP. No connection to the search function for the AP with the best signal.
6. Scripts specially written for TD (sometimes dressed in beautiful marketing words) can deassociate (kick) a client from their network once (plus sometimes block the connection for a period of time) when the signal quality threshold is overcome. All this - in the hope that the client will change his mind and connect to a neighbor with a better signal. The AP does not know what is going on "in the head" of the client, so there is no guarantee that the client, for example, will first look for the best AP in all bands, and not connect to an even more distant AP on the same channel. This is not described in the standards, there is no question of any predictability and seamlessness, but probably in some cases playing with such scripts can help kill time .
7.

laptops constantly lose connection when in one place, and mobile devices very rarely decide to switch to a nearby access point with a better signal and instead remain at the most distant one.

As a result, perhaps someday 802.11k will be able to help with something, and the solution to the described problem is more likely to be found in banal actions:
PS: About controllers. As far as I understand it, all these vendor wireless controllers should not be taken as something unique, adding super-features inaccessible to mere mortals. Usually this is just a set of software services, taken out of access points for solidity, redundancy and convenience (single point of control, PoE, etc.). Roughly speaking, this is a box where, in addition to the obvious things, there can be: a proprietary protocol for the mass distribution of settings, a PMKID or equivalent cache, RADIUS or an equivalent, quite banal DHCP, BOOTP, TFTP, etc., hidden under a thick layer of beautiful names.
First the specified comment thread, then the article. so that there is a correct correction for the "vendor" wind.
Mostly about authentication and its acceleration .
An example of a clear presentation of information from a manufacturer of client devices .

Answer 3

Not at the moment. For seamless roaming, you need a controller that tells the points when one point should release a particular client and take another, you can only put a single SSID and the same access parameters on the controller, users will jump from point to point, but not so smoothly.

Answer 4

In general, the issue is organizational, here you can do it in 2 ways:
1. To score on such clients who cannot raise the mouse to manually transfer themselves to a network with a higher signal level. I want to eat a cactus let them eat.
2. You can implement all this at the client level, that is, the application on the laptop will constantly (every few seconds) check the surrounding networks and watch the signal level on the current network, and if the signal quality on the current one is worse than 1 from the environment, it will switch the network automatically.
There will be no "seamlessness" at 100%, and if you play Quake on Wifi while cycling with a laptop between offices, this will not help, but in any adequate situation this will be more than enough.
Whether there is such software or not, I won’t say for sure, but I don’t think it’s difficult to write it if the need arises.

Answer 5

Samsung has a ready-made solution on the topic of api telephony over Wi-Fi "SAMSUNG OfficeServ", one global drawback, you immediately get stuck on only Samsung products.