Recent submissions

Comment · 5 months ago
Comment · 11 months ago
Comment · 11 months ago
Comment · 1 year ago
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.
Comment · 1 year ago
Thanks!

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

Comment · 1 year ago
Comment · 1 year ago
OpenSOHO and OpenWisp do both send parts of /etc/config files to the AP.

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)

Comment · 1 year ago
Nice idea!

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

Comment · 1 year ago
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.

Comment · 1 year ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton