Comments URL: https://news.ycombinator.com/item?id=48109224

Points: 1309

# Comments: 406

Comments URL: https://news.ycombinator.com/item?id=47341094

Points: 4

# Comments: 0

https://github.com/rubenbe/opensoho/

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!)

While we're discussing: someone did an attempt in the OpenSOHO discussions to have a freshly flashed AP register automatically with OpenSOHO:

https://github.com/rubenbe/opensoho/discussions/1#discussion...

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 ;)

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.

https://github.com/rubenbe/opensoho

It is still a work in progress, but it is easy to deploy (one golang binary based on pocketbase)

Comments URL: https://news.ycombinator.com/item?id=44692912

Points: 16

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=44662353

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44425253

Points: 98

# Comments: 110