Bug#945466: bridge_hw sometimes appears to be ignored or overridden
On a hunch I've added a delay in /etc/network/if-pre-up.d/bridge. Specifically, in the following fragment: brctl addbr $IFACE || exit 1 if [ "$IF_BRIDGE_HW" ]; then ip link set dev $IFACE address $IF_BRIDGE_HW fi So that now it reads: brctl addbr $IFACE || exit 1 if [ "$IF_BRIDGE_HW" ]; then sleep 1 ip link set dev $IFACE address $IF_BRIDGE_HW fi This appears to fix the issue. At least I was no longer able to reproduce it while commenting out sleep immediately results in the wrong address. In fact, even echo instead of sleep appears to be sufficient. Let me know if you need me to try anything else.
Bug#945466: bridge_hw sometimes appears to be ignored or overridden
Santiago Garcia Mantinan writes: > I'm reading that this did not happen before, what was the status before, > pure buster? No, it was a snapshot of testing on 2019-06-19. > Wha packages related to networking do you have installed and got upgraded? I am not really upgrading, I just build a new snapshot, so now I have a snapshot of testing as of yesterday (2019-11-25). Here is /var/lib/dpkg/status for the previous snapshot (2019-06-19): https://codesynthesis.com/~boris/tmp/dpkg-status-0.12.0.gz And for the latest (2019-11-25): https://codesynthesis.com/~boris/tmp/dpkg-status-0.13.0.gz
Bug#945466: bridge_hw sometimes appears to be ignored or overridden
Hi! On Nov 25 2019, Boris Kolpackov wrote: > After upgrading to the latest testing version of all the packages, I now > observe what appears to be the bridge_hw address most of the time being > ignored and some random address being used instead (76:95:e6:8c:c3:9e). I have some questions, let's see if you can answer them. I'm reading that this did not happen before, what was the status before, pure buster? Wha packages related to networking do you have installed and got upgraded? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#945466: bridge_hw sometimes appears to be ignored or overridden
Package: bridge-utils Version: 1.6-2 I have the following bridge configuration: auto br0 iface br0 inet dhcp bridge_ports eno1 bridge_stp off bridge_maxwait 0 bridge_fd 0 bridge_hw 0c:c4:7a:33:46:a6 post-up ip link set eno1 txqueuelen 4000 post-up ip link set br0 txqueuelen 4000 Where 0c:c4:7a:33:46:a6 is the (real) MAC address of my eno1 interface. After upgrading to the latest testing version of all the packages, I now observe what appears to be the bridge_hw address most of the time being ignored and some random address being used instead (76:95:e6:8c:c3:9e). Here is a sample transcript: $ ifup br0 Listening on LPF/br0/76:95:e6:8c:c3:9e Sending on LPF/br0/76:95:e6:8c:c3:9e Sending on Socket/fallback DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 15 DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 21 DHCPOFFER of 10.0.253.96 from 10.0.0.1 DHCPREQUEST for 10.0.253.96 on br0 to 255.255.255.255 port 67 DHCPACK of 10.0.253.96 from 10.0.0.1 bound to 10.0.253.96 -- renewal in 3159 seconds. $ ip add show 2: eno1: mtu 1500 qdisc mq master br0 state UP group default qlen 4000 link/ether 0c:c4:7a:33:46:a6 brd ff:ff:ff:ff:ff:ff 17: br0: mtu 1500 qdisc noqueue state UP group default qlen 4000 link/ether 76:95:e6:8c:c3:9e brd ff:ff:ff:ff:ff:ff inet 10.0.253.96/8 brd 10.255.255.255 scope global dynamic br0 valid_lft 6644sec preferred_lft 6644sec inet6 fe80::7495:e6ff:fe8c:c39e/64 scope link valid_lft forever preferred_lft forever Sometimes, however, I do get the correct MAC assigned. So to me this feels like some kind of a race. Based on the discussion in bug #725786 I was able to come up with the following workaround which appears to work reliably: auto br0 iface br0 inet dhcp bridge_ports eno1 bridge_stp off bridge_maxwait 0 bridge_fd 0 bridge_hw 0c:c4:7a:33:46:a6 hwaddress 0c:c4:7a:33:46:a6 post-up ip link set br0 address 0c:c4:7a:33:46:a6 post-up ip link set eno1 txqueuelen 4000 post-up ip link set br0 txqueuelen 4000 Let me know if you need any additional information from my side or need me to try anything.
