Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye
PS: Additionally, I forgot to mention that adding dad-attempts 0 to the br0 inet6 config also solves the issues of networking failing. On 06/09/2021 14:17, Pieter Hollander wrote: Hi all, I tried the fixes proposed here. Unfortunately, adding bridge_ports or bridge_hw did not solve the issue. The workaround of changing exit 1 to exit 0 in the /lib/ifupdown/settle-dad.sh "DAD timed out: section did cause networking to start up successfully, although it still logs the timeout. systemd[1]: Starting Raise network interfaces... ifup[1463]: Waiting for DAD... Done ifup[1606]: Waiting for DAD... Timed out systemd[1]: Finished Raise network interfaces. Using a dummy port to perform DAD sounds like the best solution to me. Back to the workaround: It also solves the problems I encountered with Unbound & PostgreSQL being unable to bind to the IPv6 interface address specified. Thank you all for the swift replies. This is my first Debian bug report and it's great to be met with this amount of responses. Feel free to move it to ifupdown if that's more applicable. It sounds good to fix it with a long-term solution in Bookworm, but as I know multiple people depending on a configuration similar to the one I described earlier, it might be wise to fix in Bullseye as well. Best regards, Pieter On 06/09/2021 11:04, Santiago Garcia Mantinan wrote: Hi! I'm CCing Josué because this seems to be more on ifupdown's side than on bridge-utils. auto br0 iface br0 inet static address 10.10.10.1 netmask 255.255.255.0 bridge_ports none bridge_stp off bridge_fd 0 iface br0 inet6 static address 2001:db8::2 netmask 64 These stanzas are missing the "bridge_hw" entry which can be a MAC address or the name of the interface whose MAC to take. Thus your bridge ends up being connected to nothing. I know we are having quite some trouble with the random bridge mac address, but this doesn't seem to be one of those cases. For what I see this is a problem with DAD, the bridge is created without any port attached to it, so the kernel doesn't allow it to transition from: 18: br0 inet6 X/64 scope link tentative \ valid_lft forever preferred_lft forever to: 18: br0 inet6 X/64 scope link \ valid_lft forever preferred_lft forever This is because without any port on the bridge the kernel cannot do any DAD. So, without trasitioning it remains on tentative all the time, and thus the script /lib/ifupdown/settle-dad.sh from the package ifupdown exits with a timeout message, like the one you are seing and an error status of 1, thus breaking the network setup. I have thanged the exit 1 to an exit 0 on that script and everything works like expected, this is a nasty workaround while we don't arrive to a better solution, the other solution would be to attach something to the bridge, maybe even a dummy port or similar. Josué, we've had the idea of integrating bridge setup (now on bridge-utils) into ifupdown, I wouldn't mind doing this for Bookworm, I would continue to take care of this part to the best of my knowledte even if it is on ifupdown. Maybe it it is the time to do that. As for this bug, the workaround I describe is not a valid solution, but maybe we can check on the settle-dad script to see if the device is a bridge without any interface added to it, and thus not transitioning, and return with a 0 on the timeout in that case? About integration... we have talked about that on some bugs that are somehow half way between bridge-utils and ifupdown, last one may be #939713, I would try to rewrite everything on the ifupdown scripts to depend on ip and not brctl, so that ifupdown wouldn't depend on bridge-utils. We can start some other thread on this if you want or we can talk about this on irc or mail, whatever. As for this bug... I believe it is on the ifupdown side, so I think we should reasign it, unless you see a way to fix this problem on the bridge-utils side, but I can't think about any fix on bridge-utils side right now. Regards.
Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye
Hi all, I tried the fixes proposed here. Unfortunately, adding bridge_ports or bridge_hw did not solve the issue. The workaround of changing exit 1 to exit 0 in the /lib/ifupdown/settle-dad.sh "DAD timed out: section did cause networking to start up successfully, although it still logs the timeout. systemd[1]: Starting Raise network interfaces... ifup[1463]: Waiting for DAD... Done ifup[1606]: Waiting for DAD... Timed out systemd[1]: Finished Raise network interfaces. Using a dummy port to perform DAD sounds like the best solution to me. Back to the workaround: It also solves the problems I encountered with Unbound & PostgreSQL being unable to bind to the IPv6 interface address specified. Thank you all for the swift replies. This is my first Debian bug report and it's great to be met with this amount of responses. Feel free to move it to ifupdown if that's more applicable. It sounds good to fix it with a long-term solution in Bookworm, but as I know multiple people depending on a configuration similar to the one I described earlier, it might be wise to fix in Bullseye as well. Best regards, Pieter On 06/09/2021 11:04, Santiago Garcia Mantinan wrote: Hi! I'm CCing Josué because this seems to be more on ifupdown's side than on bridge-utils. auto br0 iface br0 inet static address 10.10.10.1 netmask 255.255.255.0 bridge_ports none bridge_stp off bridge_fd 0 iface br0 inet6 static address 2001:db8::2 netmask 64 These stanzas are missing the "bridge_hw" entry which can be a MAC address or the name of the interface whose MAC to take. Thus your bridge ends up being connected to nothing. I know we are having quite some trouble with the random bridge mac address, but this doesn't seem to be one of those cases. For what I see this is a problem with DAD, the bridge is created without any port attached to it, so the kernel doesn't allow it to transition from: 18: br0inet6 X/64 scope link tentative \ valid_lft forever preferred_lft forever to: 18: br0inet6 X/64 scope link \ valid_lft forever preferred_lft forever This is because without any port on the bridge the kernel cannot do any DAD. So, without trasitioning it remains on tentative all the time, and thus the script /lib/ifupdown/settle-dad.sh from the package ifupdown exits with a timeout message, like the one you are seing and an error status of 1, thus breaking the network setup. I have thanged the exit 1 to an exit 0 on that script and everything works like expected, this is a nasty workaround while we don't arrive to a better solution, the other solution would be to attach something to the bridge, maybe even a dummy port or similar. Josué, we've had the idea of integrating bridge setup (now on bridge-utils) into ifupdown, I wouldn't mind doing this for Bookworm, I would continue to take care of this part to the best of my knowledte even if it is on ifupdown. Maybe it it is the time to do that. As for this bug, the workaround I describe is not a valid solution, but maybe we can check on the settle-dad script to see if the device is a bridge without any interface added to it, and thus not transitioning, and return with a 0 on the timeout in that case? About integration... we have talked about that on some bugs that are somehow half way between bridge-utils and ifupdown, last one may be #939713, I would try to rewrite everything on the ifupdown scripts to depend on ip and not brctl, so that ifupdown wouldn't depend on bridge-utils. We can start some other thread on this if you want or we can talk about this on irc or mail, whatever. As for this bug... I believe it is on the ifupdown side, so I think we should reasign it, unless you see a way to fix this problem on the bridge-utils side, but I can't think about any fix on bridge-utils side right now. Regards.
Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye
Package: bridge-utils
Version: 1.7-1
Severity: critical
Tags: ipv6
Justification: breaks unrelated software
After upgrading from Buster to Bullseye, bridge-utils no longer
configures my IPv6 network bridge correctly.
It fails to bring up br0 and therefore also breaks Unbound on my system,
as the IPv6 interface address Unbound needs to bind to remains in
"tentative" state.
Looking at the bridge-utils changelog, I thought it might be related to
the fixes for #980752, but I am unsure about this.
I have personally not been able to fix the problem yet and cannot find
documentation explaining the change in bridge-utils behaviour.
The following setup works correctly on buster but fails on bullseye.
"sudo journalctl -u networking -f" shows the following message:
Starting Raise network interfaces...
Sep 02 12:10:30 x ifup[849]: Waiting for DAD... Done
Sep 02 12:10:37 x ifup[1042]: Waiting for DAD... Timed out
Sep 02 12:10:37 x ifup[712]: ifup: failed to bring up br0
Sep 02 12:10:37 x systemd[1]: networking.service: Main process exited,
code=exited, status=1/FAILURE
Sep 02 12:10:37 x systemd[1]: networking.service: Failed with result
'exit-code'.
Sep 02 12:10:37 x systemd[1]: Failed to start Raise network interfaces.
Overview of configuration:
/etc/network/interfaces:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto ens3
iface ens3 inet static
address 203.0.113.0.118
netmask 255.255.255.0
gateway 203.0.113.0.1
dns-nameservers 127.0.0.1
iface ens3 inet6 static
address 2001:db8::1
netmask 128
gateway fe80::1
dns-nameservers ::1
auto br0
iface br0 inet static
address 10.10.10.1
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
iface br0 inet6 static
address 2001:db8::2
netmask 64
/etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.ens3.proxy_ndp=1
/etc/ndppd.conf
route-ttl 3
proxy ens3 {
router no
timeout 500
ttl 3
rule 2001:db8::/64 {
auto
}
}
/etc/unbound/unbound.conf:
include: "/etc/unbound/unbound.conf.d/*.conf"
server:
interface: 127.0.0.1
interface: ::1
access-control: 127.0.0.0/8 allow
access-control: ::1/128 allow
# Listen on the LXC bridge IPv4 & IPv6 network
interface: 10.10.10.1
interface: 2001:db8::2
# Allow access to Unbound from containers
access-control: 10.10.10.1/24 allow
access-control: 2001:db8::1/64 allow
-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bridge-utils depends on:
ii libc6 2.31-13
bridge-utils recommends no packages.
Versions of packages bridge-utils suggests:
ii ifupdown 0.8.36
-- no debconf information
Bug#783228: clamav-unofficial-sigs: Could not resolve host: clamav.securiteinfo.com bug not resolved on Debian Buster.
Package: clamav-unofficial-sigs Version: 3.7.2-2 Followup-For: Bug #783228 Debian Buster still has this bug. I think the best solution would be to update the package from upstream sources. Upstream it has been fixed. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (150, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clamav-unofficial-sigs depends on: ii bind9-host [host] 1:9.11.5.P4+dfsg-5.1 ii clamav 0.101.4+dfsg-0+deb10u1 ii curl 7.64.0-4 ii dnsutils 1:9.11.5.P4+dfsg-5.1 ii gnupg 2.2.12-1+deb10u1 ii rsync 3.1.3-6 clamav-unofficial-sigs recommends no packages. Versions of packages clamav-unofficial-sigs suggests: ii clamav-daemon 0.101.4+dfsg-0+deb10u1 -- no debconf information
