We didn't start the fire(wall)#

Mon 26 Jun 2023 10:25:12 AM UTC

tl;dr:

• Liminix now works with Nixpkgs 23.05
• We almost route packets
• Docs have been tested and found wanting

First news for this week is that Liminix builds green in CI for all targets, and boots successfully on the GL-AR750. The only thing left to do on that score since last week was fix a bug in the preinit code that was not NULL-terminating an array correctly. It's presumed to boot also on the other hardware but I haven't tested it in prod yet.

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. And I think we're nearly there.

• The IPv6 firewall is loosely based on the requirements in RFC 6092 and "works in principle" (I realised late last night that I was blocking DHCP client support on the WAN and therefore not getting a network allocated from the ISP: fixed this but it does suggest that the rules need review at a time I'm actually awake). What we don't have is a default route, because ... I don't know why not. Something I'm getting wrong with ip route add syntax or semantics, and the rather opaque error reporting is not helping. ip: RTNETLINK answers: Invalid argument. Quite.

• For IPv4 we have basic connectivity using NAT. It works but it's not fancy and it probably needs checking to make sure we're dropping bogons and generally being a good netizen.

To shorten the ntables development feedback loop, which often involves finding out that something doesn't work because it's missing from the kernel, I've added some code for building kernel modules without having to rebuild the kernel. This means we can add kernel modules as service dependencies and they will be loaded/unloaded as required by the service. It also means we can liminix-update to test new versions without having to reflash the kernel.

liminix-update could still be faster if it didn't have to reboot: resetting the board seems to take an age. I can see two avenues of investigation here:

• for changes to services, some mode of operation that would stop all running services, run the new config's activate command and then restart them.

• for changes that only add/remove packages, there is no need to restart anything, but to make the package accessible to the user (on their PATH) we do at least need to rewrite their profile. So, something that would do that.

The former of those would be more use to me currently: the only need I've had yet to install packages that aren't used by services is "oh, I'm missing tcpdump and strace".

....

The other area that needs some love is the new user/onboarding experience: the User Manual describes some things as they were in March, some things as they will be in The Future, and some things not at all. Going to give that some proper thought as soon as I have a router sufficiently functional that I can use it as I write.