Your message dated Thu, 6 Oct 2022 23:26:34 +0200 with message-id <[email protected]> and subject line Re: Bug#998516: bridge-utils: Kernel assigns same MAC-address to the bridge on 2 similar network devices has caused the Debian Bug report #998516, regarding bridge-utils: Kernel assigns same MAC-address to the bridge on 2 similar network devices 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.) -- 998516: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998516 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---Hi! > Could it be, that the two systems use the same machine ID? > (See e.g. https://github.com/systemd/systemd/issues/21185) What Mika says has sense, I'm closing the bug as we cannot reproduce it (other than the way this systemd issue exposes) and anyway, this is not related to bridge-utils, as we don't assign addresses unless the user asks us to. Regards. -- Manty/BestiaTester -> http://manty.net
--- End Message ---
