With Linux 6.12, some of the iptables modules are no longer directly
selectable, leading to a failure to build the module loader. We don't
need them anyway as we use nftables, so remove them.
we no longer need to remove ipv6 routes from member interfaces when
adding to the bridge, because there will no longer be any ipv6 routes
on the member interfaces
DHCP6 and autoconfig work in tandem not in opposition! dhcp6 does not
provide a default gateway: it depends on router solicitation/router
adverts for that
Tl;dr the network/site admin will ensure that router adverts are being
sent periodically. The adverts will have either Autonomous or Managed
bits set and that is what tells the host to use SLAAC or to use DHCP6
This dosn't work as well as you might think if you didn't know that
the config semantics are weird. By setting 'default' we disable
autoconfig on interfaces that do not yet exist, but setting 'all' here
has no effect.
it is problematic to have dhcp signal readiness when a lease is
acquired, because it holds the s6 service lock while it's waiting
and that can lead to deadlock. Instead, start the dhcp client
"daemon" process and monitor its outputs, bringing up and down
a controlled "dhcp lease acquired" service that other services
(e.g. ntp, or resolvconf, or ...) can declare as a dependency
Adding an interface as a bridge member does not (by itself) remove the
routes which go via that interface, whioch makes them basically into
null routes. This isn't a problem for IPv4 because there were no
addresses anyway, but interfaces can acquire IPv6 addresses via
autodiscovery before they get added to the bridde
Possibly it would be better to disable autodiscovery on these
interfaces. More thought needed.
because there's an ugly deadlock. s6-rc won't start anything else
while waiting for int.link.dhcpc to announce it's ready, and the
-running service needs to call s6-rc to launch the scripts that add
members to the bridge. dhcpc won't work until the bridge has a member
ip-up and ipv6-up both attempt to write to fd 10, but only the
first writer will succeed because the peer closes the pipe as soon
as it gets anything. I can't see a way to make this race-proof, so
... here we are
* it's now a command not a service
* shipper is expected to open() the fifo passed as $LOG_FIFO instead of
getting logs on stdin
logtap determines that remote logs are getting sent when there's a
reader on the fifo it's writing, but opening the fifo as stdin of
s6-tcpclient is too early as it hasn't even connected to the remote
log server at that time
there was a race where ip-up could write ifname and then
ip6-up could write its outputs and then test ifname and
signal ready before ip-up had written the rest of its outputs
when the peer bounces ppp, s6 will restart the ppp process but not
restart the dependent services (because the service isn't considered
to have gone down)
so the dependent services need to notice when the outputs from ppp
have changed
because what happens if the service is restarted but the new ppp0 is
a different interface than the old one so that services which had
bound to it with the old name are now not getting new data
(I am not 100% that this actually happens but it seems like it would
be good to avoid it if it does)
Peter Collingbourne
dan