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
