NixWRT Nics#

Sun, 21 Nov 2021 19:17:29 +0000

According to Git history I've been back on hacking NixWRT fairly regularly for a couple of months, and am pleased to be able to write that by dint of saying "screw it" to every previous attempt to write a replacement init system, I have got to the point that I can create an image that runs in Qemu which actually routes packets.

It runs ppp-over-l2tp on the qemu default "user" network device to connect to the internet and then it gets some proper address space by running a DHCP6 client to do a "prefix delegation" on that link.
It brings up a second ethernet device and assigns it an RFC1918 address, and also a network based on the address prefix that came back from DHCP6
It starts dnsmasq on eth1, and turns on IP forwarding

Given that it's qemu, we don't even have to attach eth1 to any real hardware. The nixwrt vm is started with options including

  -netdev socket,id=mynet1,listen=:5133 \
  -device virtio-net-pci,netdev=mynet1

and then I start a second VM with

qemu-system-x86_64 -enable-kvm \
 -netdev socket,id=mynet0,connect=:5133 \
 -device virtio-net-pci,netdev=mynet0 \
 -cdrom sysrescue.iso   -m 2048

whose eth0 can see nixwrt's eth1, and which successfully gets a (real! globally routable!) IPV6 address from it.

At some point I should try it on some real hardware,but there are a few other things to do first. DNS would be nice, for one. So would NAT (so I can have IPv4 as well as v6) and some kind of firewalling.

In replacement init system news, I am now using shell scripts to start services where I was previously implementing them as Monit services. The codebase is in a very transitional state right now: existing services (anything defined with services.foo - q.v.) continue to be started using Monit, for the moment, but new services go into the config under the svcs key - see this dnsmasq example. Most likely I will rename this back to services once I've moved everything over.

New-style service definitions can also specify changes to the config, meaning they can require busybox applets or kernel config. This means that if service B depends on service A it doesn't have to also know what A's system requirements are.