Comment by pseudosavant | Hacker News Reader

Comment by pseudosavant | Hacker News Reader

Parent Full thread

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.

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

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.

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)

Reply on news.ycombinator.com