Can I speak to your supervisor?#

Fri, 30 Oct 2020 17:22:36 +0000

When we left off last time I was teasing some words abut L2TP ("PPP over the internet") and how it would let me test the actual routing/gatewaying/firewalling etc in NixWRT without breaking the internet access for everyone else in the house.

That's part of what I've been doing since though not exactly all of it. Mostly I have been drowing in alphabet soup.

• L2TP in Linux is implemented with a piece of software called xl2tpd, which creates a udp tunnel between your device (the LAC) and a computer in an ISP somewhere (the LNS). It listens to a unix socket, and once the tunnel is up, you can send some string like c aaisp - supposing you have configured it to know about a LAC called aaisp - to cause it to exchange some L2TP packets on the tunnel and then spawn pppd.

• once pppd is running and has done its own negotiation (PAP! CHAP! BAM! WHIZZ! POW!) then it creates a point-to-point network interface traditionally called ppp0 that allows you to ping the machine at the other end

• now you can run a DHCP and/or DHCP6 client on that interface to get other important details like the routes it provides, networks it has delegated to you, DNS servers, NTP (maybe) and that kind of stuff. OpenWrt have a daemon called odhcp6c which deals with most of this: it runs for the lifetime of the session, and when it gets responses from the servers it is talking to, it calls a script (which you provide) passing the data in environment variables, so that you can run the appropriate commands to confgure your local device.

• the said configuration likely involves yet other services (ntpd, or the dnsmasq you probably run as a dns proxy, or maybe a wireguard vpn, or ...) which need to be configured or reconfigured and started and/or restarted.

Clearly, there are a number of dependencies here (and not forgetting you can't even start the process until you have a transport interface configured for the l2tp to be tunneled over), and modeling these dependencies in Monit was becoming a bit unwieldy. I'm not 100% sure that writing a whole new service supervision system in Lua will be net better, but that's what I've set out to do and early signs are promising. Two sentence summary:

• each service is monitored by a Lua script which starts it and does service-specific health checks on it

• a service publishes its state by writing files into a subdirectory of /run/swarm/services wich it owns, and subscribes to updates from other services using inotify watches on the directories owned by those other services.

It's very much WIP. If I can arrive at a general design that will let me cleanly address (1) the case above; (2) l2tp over lte modem as backup for pppoe; (3) automatically recovering from a buggy ethernet driver/device that panics under heavy load, I will tentatively conclude that it is a good piece of software.

In other news, I have revived (more accurately, rewritten) the QEMU target for NixWRT so now you (and I) can build and run it without access to real hardware. I am only mildly infuriated that QEMU doesn't appear to support device trees on MIPS (or perhaps it does but the Malta MIPS subarch init code doesn't know how to load the dtb that QEMU passes) but it hasn't added a whole lot of complexity to the build to have one target without. See the instructions in the README

If I get much more fed up of having to build a new image and reboot qemu every time I move the bugs around in my Lua scripts, I may also look into adding 9p support so that the emulator can read its root fs direct from the host.