Package: bridge-utils
Version: 1.6-5+b1
Severity: important
X-Debbugs-Cc: [email protected], [email protected]
I’m shocked to read this in apt-listchanges so shortly before a release:
bridge-utils (1.6-4) unstable; urgency=low
Linux kernel has changed bridge MAC address selection.
In older Linux kernels the MAC of the bridge was the lower mac of the
devices attached to it, this is no longer the case now at Bullseye. The
kernel now makes up a completely new MAC address.
This means that if you rely on your bridge's MAC address for something
like DHCP leases or similar stuff you'll loose this feature. The only way
to go back to your old macc address is to assign it to the bridge
explicitly using bridge_hw followed by the wanted MAC address on your
bridge definition.
The bridge_hw documentation does *not* endear me to using that option:
bridge_hw MAC_address|interface
set the Ethernet MAC address of the bridge to the specified one
or to the address of the specified interface. There were some
concerns of how this was done in the past, see: http://bugs.de‐
bian.org/271406 but we are doing it on a new way now that
shouldn't be as bad, see: http://bugs.debian.org/725786 however
you should know what you are doing before using this option.
Reading #725786 also doesn’t make it better. Plus there’s…
7) #980856 bridge-utils: ignores bridge_hw
… which is also not very trust-inducing.
And indeed, I believe bridge_hw didn’t work right for me ever; on a
virtualisation host, I’m using this:
# The primary network interface
auto br0
iface br0 inet static
bridge_ports em0 rl0
bridge_stp off
bridge_waitport 5
bridge_fd 0
post-up echo 2048 >/sys/class/net/br0/bridge/hash_max
post-up ifconfig br0 hw ether xx:xx:xx:xx:xx:xx
address 172.2x.xxx.xxx
netmask 255.255.0.0
broadcast 172.2x.255.255
gateway 172.2x.0.1
I believe the reason I needed that ifconfig invocation was
because when adding a device (VM) the bridge address changed
(even if bridge_hw was used!), but I can’t remember whether
that predated the changes mentioned in #725786… nobody in
the bug uses ifconfig, and I’m not used to the ip command still
with some small exceptions.
All in all, I’m…
• not sure this is wise so shortly before the freeze
• unimpressed by bridge_hw, especially given the remarks
in its documentation
• not sure whether “ifconfig br0 hw ether” is still the best option
• if so, why this is not documented… or even mentioned anywhere…
• which of the various ip commands in that bugreport would work
(if at all) and in which situations… or when I’d choose that
instead of ifconfig…
Please clarify, and consider reverting this until after the
bullseye release, so there will be enough time for a *proper*
working solution to be both implemented and documented.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500,
'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
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
-- no debconf information
