Your message dated Tue, 27 Jul 2021 10:53:40 +0200
with message-id <YP/[email protected]>
and subject line Re: Bug#991416: bridge-utils: broken IPv4 connection after
upgrading to Debian Bullseye, setting old MAC with bridge_hw fixes the issue
has caused the Debian Bug report #991416,
regarding bridge-utils: broken IPv4 connection after upgrading to Debian
Bullseye, setting old MAC with bridge_hw fixes the issue
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.)
--
991416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991416
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: bridge-utils
Version: 1.7-1
Severity: serious
Dear Maintainer,
I’ve upgraded yesterday my server running Debian 10 (Buster) to Debian 11
(Bullseye). The server is hosted by OVH and has both IPv4 and IPv6 connection.
Everything ran seamlessly excepted until I rebooted the server: I lost the IPv4
connection on my bridge interface (IPv6 was still OK).
To clarify my network set-up in /etc/network/interfaces (I don’t have anything
else configured):
auto eno3
iface eno3 inet manual
auto br0
iface br0 inet static
bridge_ports eno3
address XX.XX.XX.XXX0/24
gateway XX.XX.XX.XXX
iface br0 inet6 static
address IPV6_ADDRESS/64
[…] (route related)
After a long time trying to figure out why the server wasn’t answering ping
from outside and couldn’t reach internet through IPv4 while the interface was
up and well configured, it *seems* that some behaviour has changed.
I suspected that the network was blocked because of the different MAC address
between eno3 and br0 (I was able to ping my gateway).
Setting the eno3 MAC address on the br0 interface (with bridge_hw) fixed the
issue.
I haven’t the hardware to reproduce the previous behaviour (how the MAC address
was previously assigned to the bridged interface), and to migrate again from 10
to 11,
but in case this new behaviour effectively come from a change in the Bullseye
package, it could lead to some problems while upgrading.
Hope this helps,
Matthias
-----------------------
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bridge-utils depends on:
ii libc6 2.31-12
bridge-utils recommends no packages.
Versions of packages bridge-utils suggests:
ii ifupdown 0.8.36
-- no debconf information
Thank you for using reportbug
--- End Message ---
--- Begin Message ---
Hi!
Thanks Martin-Éric and Dennis for your explanations and contributions, I'll
try to summarize this and I'm closing the bug as this has been dealt with.
This has been treated already on #966244 and #980505, the kernel developers
seem to have followed what seems to be a trend (not to expose the user's MAC
address, to disallow easy tracking and thus better privacy) and I don't
think we should override that, we have provided an easy method for the user
to continue using a local MAC on the bridge, but he must do so explicitly, I
really think this is the good way to cope with this.
As a result of those bugs, the mod of bridge_hw parameter, overloading it to
allow to specify an interface as well as the MAC address was made, and also
a note on NEWS explaining it all was written.
I believe this should be enough, the other thing we could do is add a note
on the release notes if you feel it is needed, I suppose for that, the
release team should be contacted, but I don't really now the way for this.
If anybody wants to go that way, I won't oppose that, but as far as
bridge-utils is concerned, I feel like it is ok like it is now.
> @Santiago: Feel free to remove the patch tag if you have doubts about
> its quality.
Like I said, I like it like it is, I don't think It makes sense to continue
with the old algorithm, the kernel has changed, and we shouldn't hide that.
Besides, I don't think the release guys would allow this change to enter
Bullseye this late.
Thanks again for your contributions.
Regards.
--
Manty/BestiaTester -> http://manty.net
--- End Message ---
