Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye

[Pieter Hollander]

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 30000
proxy ens3 {
    router no
    timeout 500
    ttl 30000
    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

[Rob Leslie]

I also encountered this.

My working hypothesis is that it may be related to this (from README.Debian):

> Since version 1.6-6 we support multiple stanzas of the interface usefull,
> for example, to describe the IPv4 and IPv6 addresses of an interface. The
> only requirement for this is that all of them need to have bridge_ports
> specified.

Could you try duplicating the bridge_ports in the inet6 stanza and see if that eliminates the problem?

Alternatively, perhaps adding dad-attempts 0 would work.

I have not yet been able to try either remedy. Please let me know if one of them helps.

--
Rob Leslie
r...@mars.org

[Santiago Garcia Mantinan]

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.
--
Manty/BestiaTester -> http://manty.net

[Pieter Hollander]

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

[Thomas Goirand]

Hi,

I have lowered the severity of this bug to allow the package to migrate
back to testing.

The reasoning is that, yes, there's an important issue to fix, as
upgrade is broken. However, having no bridgeutils in testing is more
harmful than this bug.

Cheers,

Thomas Goirand (zigo)

[Santiago Garcia Mantinan]

Hi!

On Set 06 2021, Pieter Hollander wrote:
> PS: Additionally, I forgot to mention that adding dad-attempts 0 to the br0
> inet6 config also solves the issues of networking failing.

> > 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.

Sorry for coming back to this so late... going over it now I see that I
didn't get which of the workarounds worked for you.

Did you add a dummy port? if so... can you send a config example?

If not... how did you fixed this?

[Santiago Garcia Mantinan]

Hi!

I'd like to sum this up.

The problem comes when we create a bridge with an IPv6 but without assigning
any ports to it.

What happens then is that DAD is triggered and ifupdown fails to bring the
interface up as DAD times out.

Waiting for DAD... Timed out

ifup: failed to bring up br1

We can just sugest to set dad-attempts to 0 when using bridges without
ports, but maybe that's not a good thing as the bridge can have the ports
attached later and DAD would be needed then.

Other than that, all I can think of is fixing it on ifupdown by not failing
on DAD timeout or even not doing DAD at all if the interface is a bridge
without ports, but maybe that is too complicated.

I'll be around with an eye on the bug, in case you need help or want to
discuss anything just cc me.

Regards...