This fixes a race where dhcp4 started before netconfigd had a chance to change
the hardware address on the uplink0 interface.
fiber7’s port security feature may result in an about hour-long internet outage
without this commit.
There is not much of a difference between IPv4 and IPv6 on my fiber7 link, but
in other networks, there might well be.
For my connection, this commit results in hitting different upstreams all the
time because the list isn’t stable. But, this is the opposite of a problem: we
are spreading the DNS query load over all configured IPs, as good netizen do.
The HTTP API is easy to use from the command line or from Go:
% curl --data "host=sub&ip=192.168.33.44" -4 http://router7:8053/dyndns
ok
% host sub.$(hostname)
sub.midna has address 192.168.33.44
This can be used in combination with https://github.com/gokrazy/gdns
Turns out a5d9e03dd3212f7f0c11dd856b308a16a58a3cdf was not entirely sufficient:
even though reused addresses would not be handed out anymore, they would still
be offered, which results in the client not being able to obtain an address.
To set up a tunnel, create a /perm/wireguard.json as illustrated in
netconfig_test.go, and don’t forget to adjust your /perm/interfaces.json with
the address configuration for the WireGuard tunnel.
Note that static routes cannot currently be configured, so the usefulness is
limited. If you have a use-case you’d like to see covered, please explain it in
https://github.com/rtr7/router7/issues/14
All existing DHCPv4 packages I looked at were unappealing for one reason or
another, so we’re now using a little helper to glue github.com/google/gopacket
and github.com/mdlayher/raw together, which suffices for our use-case and gives
us more control.
Using Packets() spawns off a separate goroutine which calls NextPacket in a loop
until io.EOF is returned. This goroutine will stick around after Close()
returned, resulting in only the first wireshark connection working.
We didn’t have a need to clamp the TCP Maximum Segment Size (MSS) up until now,
because fiber7 uses an MTU of 1500.
Because Path MTU discovery is often broken on the internet, it’s best practice
to limit the Maximum Segment Size (MSS) of each TCP connection, achieving the
same effect (but only for TCP connections).
This change is beneficial when running router7 behind a non-ethernet uplink,
such as a Fritz!Box cable modem.
This has no adverse effect on fiber7: after clamping, the MSS is still 1440, as
without clamping.
