I've built OpenSOHO using this, and it has been an amazing timesaver!
Even though I modified it a bit to reuse the backend. It's clearly not what it's made for, but it wasn't too hard either. If you have a look at the screenshot, you'll recognize the Pocketbase pedigree immediately.
OpenWRT does support 802.11r fast roaming for multiple APs.
The problem with OpenWRT is/was the configuration of multiple APs. There is OpenWISP, but they mostly target very large setups (>100 APs).
So I built OpenSOHO using the OpenWISP daemons on the AP and a pocketbase frontend. (https://github.com/rubenbe/opensoho).
No band steering yet unfortunately.
802.11k/v/r on its own is not always sufficient for roaming specially if you have old clients on the network(5 years or older).
Almost every wifi solution like Omada or UI comes with additional heuristics based mechanisms to trigger roaming.
There are also bugs/missing features in 802.11r in openwrt. For example, it does not work if you are using 802.11w or Wifi 6
Also, during roaming it's supposed to do a shortened version of handshake for auth but right now it does a full 4 way handshake afaik or atleast that's what I see in the logs when a client switches to a different ap
I've noticed that the 802.11k/v needs extra daemons to be configured (e.g usteer) and overall the documentation is very spotty. (for quite most "modern" features actually). You almost have to be lucky to find the correct forum post of a random person that actually figured things out.
WRT 802.11r, I've noticed handovers failing in my laptops dmesg when running different patch versions of 24.10 release in my network.
I'm not yet on Wifi6 so not there yet ;) If you have some more resources on that (forum post/bug that would be nice!)
802.11k/v works well enough but the problem is when you are roaming the device is likely to see 2.4ghz network before it sees 5ghz network. Unless the manufacturers considered this scenario, the device will connect to 2.4ghz and remain connected to that instead of upgrading to higher bands. You need usteer in these situations.
You can also kind of patch this problem by setting beacon interval for 5/6ghz networks shorter than beacon interval for 2.4ghz network.
Also the problem with usteer is, they took the easy way out and do broadcast for syncing with other usteer instances instead of multicast so it's a lot of wasted bandwidth and it'll hit all the devices in that l2 segment.
Thanks for the info!
I didn't know about the multicast "storm" in usteer. I had a look at dawn too, but that one doesn't seem to support limiting its functionality to a specified subset of wifi interfaces.
It's for exactly that reason I started with OpenSOHO.
It is targeted towards the typical home and small office network with less than 20 OpenWRT devices. (although there is no hard limit).
Initially I fiddled a bit with full Open wisp stack to try to make a smaller edition. But I quickly stopped that. But I know their two daemons well.
The config one is a neat little piece of software. It will merge UCI configs and check the connectivity. You can adjust virtually any file with it (although not always with merging). My main issue with it is that it can't be easily temporary disabled from the central controller (I currently implement it by not sending the config, but that triggers retries on the AP end)
The monitoring one spits out an amazing amount of data, although it needs some post processing to make it actually useful. Unfortunately that one can't be extented to add custom entries. I'm currently missing an easy way to see which MAC address is connected which LAN port since OpenWRT DSA puts everyone one the "br-lan".
The whole thing is polling based. So it is quite chatty on the network since I use lower polling rates to make the updates fast. (I suspect on a setup with 100+ you will have longer polling times). All in all the existence of these daemons saved me a ton of time handling networking corner cases. Kudos to the Openwisp team.
I had a GPT-5 agent help me think through a pull-only controller/agent model for OpenWRT. The controller keeps desired configs in git and serves the current version as a tiny tar/zip over HTTP(S), using the last commit ID as the ETag. Agents poll every ~5s with If-None-Match, so it’s usually a 304 and near-zero overhead; when the version changes they fetch the archive and apply it. The controller location is advertised via DHCP; no long-lived sockets or SSH push.
On the device side, the agent only activates if there’s no WAN (so the main router isn’t a client). A new AP gets a LAN IP via DHCP, discovers the controller, pulls its config, and if none exists the controller can hand back a default Wi-Fi setup to come online immediately. Start with Wi-Fi-only changes (reload instead of reboot), aim for a “plug into LAN + power and it just joins” UX, and avoid OpenWISP complexity. It’s built from boring, reliable primitives: DHCP, HTTPS, git, tar, Lua.
I think I'm going to have an agent start coding this up today and see where it gets.
I do notice quite some people focus the autodiscovery part where for me that's less of an issue (I do agree it would be VERY nice). The OpenWISP configuration on each AP is limited to: set IP address of controller & shared secret and click OK. The rest is all magically done for you by the controller.
I do like the 304 idea, in practice it uses the same conceptual idea as the OpenWISP system: check if the MD5 (instead of SHA1) for the current config and the controller config are still identical and download and apply if not.
An important reason I why chose the OpenWISP is that they "just work", are well tested and included in the OpenWRT package list. My main goal is to keep the OpenSOHO project as small as possible ;)
I've been weighing the pros/cons of using OpenWISP. I considered using DHCP to distribute the controller IP and shared secret.
For now, I like reasoning about /etc config files. I'm more familiar with those than OpenWISP. Adopting an abstraction like that offers some portability and possibly future proofing. But that is just the config format and how it is applied though really.
I think once the router is setup, most SOHO users only ever have to add/replace (provision) APs and manage the WiFi settings. I want to make that kind of provisioning and management automatic. Making the APs as stateless as possible - kind of like a Chromebook. The agent will only have basic dependencies (lua, curl, tar).
For this to really work it'll probably have to grow to support VLAN-backed SSIDs and wireless backhaul links. Wireless links would probably need to be wired for their first time setup. But I'd be happy even if it just solved managing my own APs and SSIDs.
The Openwisp agents running on the AP are surprisingly lightweight (they do use Lua, tar, curl and a bit of shell scripting)
VLAN backed SSIDs are one of main reason I started OpenSOHO (although support is not there yet) I don't want to log into each AP to set it up manually.
I do have a wired back haul, but support for wireless backhaul will probably arrive, since quite some people have one set up.
In case you would find an easy method of bootstrapping the setup via DHCP, certainly let me know! (Maybe that's easier to be discussed on GitHub)
No, that's the advantage is that the kernel/processes don't need to be trusted since your kernel guarantees the isolation.
So you can have a Linux kernel running next to some high security process with the guarantee that they will be isolated (with the exception of allowed IPC)
I've always found openwisp to be tailored to massive fleets of OpenWrt routers (100+). Not really for a home setup where you have a handful of devices (5-10). Alternatives are welcome since I haven't found anything yet.
This would be extremely useful, since phones typically add the correct accents automatically. But on my laptop I need to do this myself (using a deadkeys layout).
You actually don't need a shell script to mount the different pseudo filesystems. You can do that in your application. So all that remains is an initramfs with a statically linked binary.
https://github.com/rubenbe/opensoho/