Your message dated Wed, 25 Aug 2021 12:24:07 +0200 with message-id <[email protected]> and subject line Re: Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface has caused the Debian Bug report #992158, regarding Race in ifup maybe related to brctl failure in pre-up of network interface to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 992158: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992158 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: bridge-utils Version: 1.7-1 Severity: serious When running "brctl addbr" and "ip link set [if] address" immediately afterwards, the second command will fail to apply the address change. This is somehow annoying as the MAC would be used in security related filtering and monitoring of the network traffic, which then fails. The configuration from "/etc/network/interfaces" reliably triggering the bug is: auto virtbr0 iface virtbr0 inet static address 192.168.1.1 netmask 255.255.255.0 pre-up brctl addbr virtbr0 pre-up ip link set virtbr0 address 86:aa:aa:aa:aa:aa pre-up ip link set virtbr0 up post-down ip link set virtbr0 down post-down brctl delbr virtbr0 Running "ifdown virtbr0; ifup virtbr0; ip link show" will report link/ether 86:8a:6a:ee:5e:a2 brd ff:ff:ff:ff:ff:ff so the setting to "86:aa:aa:aa:aa:aa" does not take effect. The reason I expect the race to be in brctl itself or related a race in the kernel just exposed by brctl is, that following changes will produce correct results: * "strace -o dump ifup virtbr0" eliminates the behavior. * Using " pre-up brctl addbr virtbr0 && sleep 1" will make "ifup" wait for one second, correct MAC is set. Instead when changing the initial interfaces configuration to include pre-up ip link set virtbr0 address 86:aa:aa:aa:aa:aa || touch /root/fail "ifup" will still expose the bug but /root/fail is not created. So if "ip link" fails to react correctly on any intermediate state when the bridge is coming up, then at least it does not detect it correctly and report it via an error code. As attaching a debugger eliminates the bug I have no idea how to quickly rule out such an effect. Weirdly this bug does not occur on a multicore real-hardware machine (I have no single core hardware or tried to run Linux single core via boot options) but till now only in single core qemu machines (I did not test multi-core qemu yet). But the core count, kernel behaviour might be just a red herring. Any ideas how that could happen? Maybe would "brctl add" need to wait for a confirmation from kernel, that the bridge setup is completed before exiting?
--- End Message ---
--- Begin Message ---> Thank you for your assistance. With hint for the relevant man > page "bridge-utils-interfaces" I found the bridge setup working > using the configuration > > auto br0 > iface br0 inet static > address 192.168.1.1 > network 192.168.1.0 > netmask 255.255.255.0 > bridge_ports none > bridge_hw 86:aa:aa:aa:aa:aa > > With that there is no race observed, I deem this bug report as > invalid. Yes, that looks ok for a setup where you don't want to add any ports to a bridge. > I tested without the legacy stuff, worked, making this bug report > irrelevant. Testing how far the change can be backported is > done on demand later, not relevant here (Bullseye). I don't remember any reason why current bullseye package can't be used at buster or prior versions. Regards. -- Manty/BestiaTester -> http://manty.net
--- End Message ---
