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.
