Last week I wrote:

The focus of development this week has been “CPE wifi router by any means possible”, with the intention that we will extract modules and services from the running system once we have … a running system.

Well, good news is that we have a CPE wifi router. I’m not writing this while connected to it, but I could be if I weren’t sitting at the other end of the garden. It has PPPoE to its upstream, IPv4 connectivity through NAT and an IPv6 /64 network. Packet routing, DHCP (v4 and stateless v6), DNS service and accurate time. Not good but also not news is that “any means possible” has meant that overall it’s less than polished.

  • set default route for IPv6 packets (required no end of swearing to get the syntax right)

  • add an IPV6 WAN address if and when DHCP6 provides us with one

  • change the “locking” convention used by the odhcp script (and by extension, other services which may periodically change state) when writing its state to /run/service-state/dhcp.ifname so that dependent services can reliably watch it using inotify without risk of reading partially-written state

  • buld our own Fennel from upstream instead of using the Nixpkgs one. Because we’re already building our own Lua (to make it teeny tiny small) and there are surprising interactions between the Nixpkgs Lua infrastructure and our custom code. We don’t need the Nixpkgs Lua infrastructure on the target device, so this is currently the simplest fix. As a side bonus, we get a slightly newer Fennel than is provided in Nixpkgs.

  • fennelrepl can be built for the build system and spawns fennel with the path already set up to find all our libraries. This makes it a lot simpler to test - or to experiment with - Fennel code.

  • create a “miscellaneous stuff” library for the Fennel code that I would otherwise be copying from one script to the next

So, victory of sorts. The next step is to make it look less like a horrible mess - I have some ideas about how that can be done but they will have to wait until daylight.