On one of my router7 installations, I’m using a bridge for uplink0
(so that I can use the built-in SFP interface, or fall back
to an external media converter in case of trouble without reconfig).
On that installation, I have observed the following bug:
1. System boots, netconfig creates uplink0.
2. The Linux kernel assigns a MAC address (e.g. ce:fa:ba:3c:66:84).
3. Netconfig cannot add the interfaces to the bridge yet,
presumably because they are not created yet.
4. The dhcp4 program starts and reads the MAC address.
5. Netconfig adds the interfaces to the bridge, the MAC changes.
6. dhcp4 still has the old (incorrect) MAC address.
7. dhcp4 never obtains a lease, the router never becomes healthy,
you’re stuck in this state.
This will be prevented by not letting the kernel assign a MAC address,
but instead determining the future MAC address (in our case:
we just use the first configured MAC address) and creating the bridge
interface correctly configured to begin with, thereby eliminating
the race condition entirely.
The current behavior stomps on the rules that programs like
podman or tailscale set up for port forwarding.
With this change, we split port forwardings into a separate chain,
which allows us to create the ruleset once at startup and then only
update the port forwardings specifically (the only dynamic part
of router7’s nftables ruleset).
Thus far, we have only had forwarded bytes metrics.
Notably, forwarded bytes does not include bytes that were sent by the router
itself, e.g. by the webserver or rsync server running on the machine.
fixes https://github.com/rtr7/router7/issues/71
It is generally not a good idea to have multiple IP addresses on the same
interface unless managing their relative priorities via metrics etc.
During an outage, I noticed that with multiple IP addresses,
Linux was using the old obsolete one to send out packets,
which does not work with the ISP.
With this change,
we still hold on to IP addresses for as long as possible,
but no longer.
fixes issue #57
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.
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
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.
