Don't write documentation tired, kids! I thought I was missing this, so
I had added it…to the wrong file, while similar notes were already
present in the file where they belonged!
It looks like this was CLOSED WONTFIX: How can we _possibly_ know that
upon an error, the developer might want us to send an indication of that
error??!!1! Snark aside (mine and his): it looks like there's not a
great way to enable sane error behavior globally :/
https://caddy.community/t/handling-errors-globally/17174/2
In the future, I should probably make this a snippet or something.
When `ip=dhcp` is passed as a kernel param (which I assume, but don't
know for sure, just gets passed to systemd and probably then to
systemd-networkd or NetworkManager or whatever does the networking in
the initrd?), IPv6 doesn't come up. With the param, bad IPv6:
```text
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 3c:52:82:00:46:d6 brd ff:ff:ff:ff:ff:ff
altname enp0s31f6
inet 192.168.1.20/24 brd 192.168.1.255 scope global eno1
valid_lft forever preferred_lft forever
inet6 2601:441:8301:8af7:94e1:4d4c:73c2:ac31/64 scope global temporary dynamic
valid_lft 322763sec preferred_lft 86330sec
inet6 fd0a:8f9f:6f83:0:3e52:82ff:fe00:46d6/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft forever preferred_lft forever
inet6 2601:441:8301:8af7:3e52:82ff:fe00:46d6/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 322763sec preferred_lft 322763sec
inet6 fe80::3e52:82ff:fe00:46d6/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
```
whereas without the param I get good (whatever that means) addresses:
```text
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 3c:52:82:00:46:d6 brd ff:ff:ff:ff:ff:ff
altname enp0s31f6
inet 192.168.1.20/24 brd 192.168.1.255 scope global dynamic noprefixroute eno1
valid_lft 43188sec preferred_lft 43188sec
inet6 fd0a:8f9f:6f83::33b/128 scope global dynamic noprefixroute
valid_lft 43190sec preferred_lft 43190sec
inet6 2601:441:8301:8af7::33b/128 scope global dynamic noprefixroute
valid_lft 43190sec preferred_lft 43190sec
inet6 2601:441:8301:8af7:b572:fc6c:ba27:dcdb/64 scope global temporary dynamic
valid_lft 322965sec preferred_lft 86235sec
inet6 2601:441:8301:8af7:f3f0:df23:a6bb:7d25/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 322965sec preferred_lft 322965sec
inet6 fd0a:8f9f:6f83:0:485e:f55d:fa1d:cef4/64 scope global temporary dynamic
valid_lft 604790sec preferred_lft 86235sec
inet6 fd0a:8f9f:6f83:0:7851:1417:807:f017/64 scope global mngtmpaddr noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::eb0c:1983:24a5:3e42/64 scope link noprefixroute
valid_lft forever preferred_lft forever
```
I'm honestly not entirely sure what this _should_ look like, but what I
_do_ know is that in the "bad" configuration, SSH takes an extra ~10s to
connect as it has to wait for two ~5s `No route to host` timeouts:
```console
[chandler@oscar:~]$ ssh -v root@bert
OpenSSH_9.8p1, OpenSSL 3.0.14 4 Jun 2024
debug1: Reading configuration data /home/chandler/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 5: Applying options for *
debug1: Connecting to bert [fd0a:8f9f:6f83::33b] port 22.
debug1: connect to address fd0a:8f9f:6f83::33b port 22: No route to host
debug1: Connecting to bert [2601:441:8301:8af7::33b] port 22.
debug1: connect to address 2601:441:8301:8af7::33b port 22: No route to host
debug1: Connecting to bert [192.168.1.20] port 22.
debug1: Connection established.
```
Future work: What _should_ my IPv6 config look like? Is there any way I
can keep network config stable between the initrd and the booted system?
Why is this recommended against?
> The default is false when systemd is enabled in initrd, because the
> systemd-networkd documentation suggests it.
This approach was recommended by nixos.wiki, and formerly by
wiki.nixos.org, which has since switched to instead mentioning
`boot.initrd.network.udhcpc.enable = true;`. It's not entirely clear to
me which has an advantage over the other.
This kernel parameter means that the kernel itself does the DHCP
request, which is pretty neat! That seems to get set up in this file,
though I haven't tracked down the exact details:
https://github.com/torvalds/linux/blob/master/net/ipv4/ipconfig.c
It seems like udhcpc may _also_ be enabled (since networking.useDHCP is
set for the main system?), so maybe that could be disabled, but this
appears to work so I'm rolling with it for the time being!
Without the kernel param set, udhcpc tries and fails with errors like
this:
```
<<< NixOS Stage 1 >>>
loading module dm_mod...
loading module af_packet...
running udev...
Starting systemd-udevd version 255.9
bringing up network interface eno1...
acquiring IP address via DHCP on eno1...
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: no lease, failing
Passphrase for /dev/disk/by-uuid/00000000-0000-0000-0000-000000000000: _
```
Compare with a working output:
```
<<< NixOS Stage 1 >>>
loading module dm_mod...
loading module af_packet...
running udev...
Starting systemd-udevd version 255.9
bringing up network interface eno1...
acquiring IP address via DHCP on eno1...
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting select for 192.168.1.20, server 192.168.1.1
udhcpc: lease of 192.168.1.20 obtained from 192.168.1.1, lease time 43200
Passphrase for /dev/disk/by-uuid/00000000-0000-0000-0000-000000000000: _
```
Chandler Swift