Package: bridge-utils
Version: 1.7-1
Severity: serious
Dear Maintainer,
* What led up to the situation?
Having 2 tiny servers (APU2.C4 and APU.2D4) in my local net each having
3 ethernet interfaces assigned to a bridge "br0" (configured in
/etc/network/interfaces).
Upgrading from Bustser to Bullseye worked fine for the first box, the bridge
received a new MAC assigned by the kernel as described in the listchanges.
After reconfiguring that in the roter everything was working as before.
Upgrading the second box in the same network segment lead to almost complete
blocking of traffic in my local network and the 2nd box was not detected by the
router.
Connecting via serial console and checking network setup revealed:
The second box got precisely the SAME MAC address as the first box!
After using bridge_hw to assign the old MAC based on the MAC of one interface
solved the problem.
Conclusion is that hardware addresses should be unique in general, but the
current way generates same address also if the MAC's of involved interfaces
differs - see here:
apu enp1s0 00:0d:b9:47:83:e8 - (Eth1)
enp2s0 00:0d:b9:47:83:e9 - (Eth2)
enp3s0 00:0d:b9:47:83:ea - (Eth3)
br0 00:0d:b9:47:83:e8 => 4a:0f:ba:96:49:a5
apu2 enp1s0 00:0d:b9:4e:76:a0 - (Eth1)
enp2s0 00:0d:b9:4e:76:a1 - (Eth2)
enp3s0 00:0d:b9:4e:76:a2 - (Eth3)
br0 00:0d:b9:4e:76:a0 => 4a:0f:ba:96:49:a5
-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bridge-utils depends on:
ii libc6 2.31-13+deb11u2
bridge-utils recommends no packages.
Versions of packages bridge-utils suggests:
ii ifupdown 0.8.36
-- no debconf information
