Package: bridge-utils Version: 1.5-10 Severity: important Tags: patch Hi!
When we tried to fix bug #779348 what we did was broke the code. The since version 1.5-10 reads... unset BREADY unset TRANSITIONED COUNT=0 # Use 0.1 delay if available sleep 0.1 2>/dev/null && MAXWAIT=$((MAXWAIT * 10)) while [ -n "$BREADY" -a $COUNT -lt $MAXWAIT ] do WAIT AND OTHER STUFF done As BREADY is unset (bridge is not ready) it is empty and thus it won't enter the while, so it won't wait for the bridge to be ready. Whis results in a failure to set up the interface if we use IPv6 on it. Maybe this is what is happening on #980507: # time ifup br0 Waiting for br0 to get ready (MAXWAIT is 22 seconds). Waiting for br0 to get ready (MAXWAIT is 22 seconds). Waiting for DAD... Timed out ifup: failed to bring up br0 real 0m8,045s The time expent waiting was all done at the DAD, the waiting for br0 didn't take any time as it didn't get to the while loop. The configuration used for testing this was: auto br0 iface br0 inet static bridge_ports eth0 wlan0 bridge_stp on bridge_fd 10 bridge_hw wlan0 address 192.168.X.X netmask 255.255.255.0 iface br0 inet6 static bridge_ports eth0 wlan0 address 2001:XXXX:XXXX:XXXX::1 netmask 64 While, if we invert the logic of the -n of the while loop to a ! like it was before, like this: --- /lib/bridge-utils/ifupdown.sh~ 2021-01-22 11:06:45.000000000 +0100 +++ /lib/bridge-utils/ifupdown.sh 2021-02-17 03:41:50.114247593 +0100 @@ -203,7 +203,7 @@ # Use 0.1 delay if available sleep 0.1 2>/dev/null && MAXWAIT=$((MAXWAIT * 10)) - while [ -n "$BREADY" -a $COUNT -lt $MAXWAIT ] + while [ ! "$BREADY" -a $COUNT -lt $MAXWAIT ] do sleep 0.1 2>/dev/null || sleep 1 COUNT=$(($COUNT+1)) We get it to work and the while loop takes what it needs to get the bridge forwarding: # time ifup br0 Waiting for br0 to get ready (MAXWAIT is 22 seconds). Waiting for br0 to get ready (MAXWAIT is 6 seconds). Waiting for DAD... Done real 0m16,723s user 0m0,891s sys 0m1,261s If people finds that it takes always MAXWAIT seconds it is because there is no other bridge speaking STP on the net or our bridge will be the Root of the topology. If that is not the case, like in this example, where the neighbour has a FD of 2, the timing will be shorter and if one wants to make it shorter he can always play with bridge_fd I don't recommend to lower it under 2 anyway. So, the code was ok like it was before and we should try to get this fix in Bullseye. I have a better fix for this which also addresses bug #319832, I've posted it there, it addresses the two "Waiting for br0..." messages, now it is only shown once, and solves the ifdown errors that you get with current implementation, but maybe that's too late for Bullseye. Regards. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.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-9 bridge-utils recommends no packages. Versions of packages bridge-utils suggests: ii ifupdown 0.8.36 -- Configuration Files: /etc/default/bridge-utils changed [not included] -- no debconf information