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
