I'm developing opensoho as a central controller for SOHO OpenWrt setups. I've recently added support for usteer and I did notice a significant drop in wireless clients with a bad connection.
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.
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.
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!)
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.
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)
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 ;)
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.
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).
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.
For me the killer feature of btrfs is "RAID 1 with different sized disks".
For a small and cheap setup, this is perfect since a broken disk can be replaced with a bigger one and immediately (part of) the extra new disk space can be used. Other filesystems seem to only increase the size once all disks have been replaced with a bigger capacity one (last time I checked this was still the case for ZFS)
I agree, the dialogs are getting increasingly frequent and harder to "click" away.
I'm open for suggestions for an open-source Android image gallery app.
I've keep running Fedora coreos on my home server. My biggest issue with it, is that it is very cloud oriented and doesn't seem to allow to rerun the provisioning config on an already existing machine. This turns the thing again into a stateful pet instead of a "one cow cattle". Although I do very much like the rollback feature which has allowed me temporarily roll back an update a couple of times
https://github.com/rubenbe/opensoho