Hi Julien Am 18.03.22 um 16:46 schrieb Julien Cristau:
Control: tag -1 moreinfo Hi Michael, Sorry it took so long to get to this. I've got a couple of questions from the NEWS file; will keep looking at the actual diff though. On Mon, Sep 20, 2021 at 01:09:00PM +0200, Michael Biebl wrote:=============================================== NetworkManager-1.30.6 Overview of changes since NetworkManager-1.30.4 =============================================== * By default, don't touch existing traffic control (TC) configuration on devices.This sounds like it could cause unexpected changes. Unsure about the risk here.
The relevant bug report is
https://bugzilla.redhat.com/show_bug.cgi?id=1928078
From the git commit
"
core,libnm: don't touch device TC configuration by default
NetworkManager supports a very limited set of qdiscs. If users want to
configure a unsupported qdisc, they need to do it outside of
NetworkManager using tc.
The problem is that NM also removes all qdiscs and filters during
activation if the connection doesn't contain a TC setting. Therefore,
setting TC configuration outside of NM is hard because users need to
do it *after* the connection is up (for example through a dispatcher
script).
Let NM consider the presence (or absence) of a TC setting in the
connection to determine whether NM should configure (or not) qdiscs
and filters on the interface. We already do something similar for
SR-IOV configuration.
Since new connections don't have the TC setting, the new behavior
(ignore existing configuration) will be the default. The impact of
this change in different scenarios is:
- the user previously configured TC settings via NM. This continues
to work as before;
- the user didn't set any qdiscs or filters in the connection, and
expected NM to clear them from the interface during activation.
Here there is a change in behavior, but it seems unlikely that
anybody relied on the old one;
- the user didn't care about qdiscs and filters; NM removed all
qdiscs upon activation, and so the default qdisc from kernel was
used. After this change, NM will not touch qdiscs and the default
qdisc will be used, as before;
- the user set a different qdisc via tc and NM cleared it during
activation. Now this will work as expected.
So, the new default behavior seems better than the previous one.
"
I'd say the above reasoning makes sense to me.
* Prefer the IPv4 address to determine the system hostname via address lookup.Likewise. What's the reasoning to do this in a stable update?
From the relevant git commit
"
policy: prefer IPv4 to determine the hostname
When determining the hostname, it is preferable to evaluate devices in
a predictable order to avoid that the hostname changes between
different boots.
The current order is based first on hostname priority, then on the
presence of a best default route, and then on activation order.
The activation order is not a very strong condition, as it is
basically useless for devices that are autoactivated at boot.
As we already prefer IPv4 over IPv6 within the same connection, also
prefer it when 2 connections have the same priority and the same
default route status, to achieve better predictability.
https://bugzilla.redhat.com/show_bug.cgi?id=1970335
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/895
"
Makes sense to me as well.
* Enable WPA3 for Wi-Fi connections with key_mgmt=WPA-PSKWhat's the regression risk here, of things working without WPA3 but not with it enabled?
That one I indeed missed. Thanks for spotting it. It has indeed the potential to break existing setups (as evidenced by [1]), although I think that would also need a newer wpasupplicant in stable.
The relevant upstream issue is https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638 I think reverting these commits for stable would make sense.Julien, if I revert the three commits from this MR, would you be ok with the upload?
Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907[2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature