The @dracut_NM_vlan_over_team_no_boot sometimes fails, among other
things, because it fails to assume an indicated connection after a
restart.
That seems to happen because after the decision to activate the
indicated connection, the device does not move from DISCONNECTED state
quickly enough. Another assumption recheck runs in between and decides
to generate a connection, because the assume state was already reset
in between.
First start, creates and activates b3a61b68-f744-4a4c-a513-61399c154a67
on vlan0017:
NetworkManager (version 1.41.1-30921.55767cf5.el9) is starting...
(asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe)
...
settings: update[b3a61b68-f744-4a4c-a513-61399c154a67]: adding connection "vlan0017"
(45113870df0a4cfb/keyfile)
Second start:
NetworkManager (version 1.41.1-30921.55767cf5.el9) is starting...
(after a restart, asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe)
Assumption attempt successfully picks the right connection and thus
proceeds to reset the assume state:
manager: (vlan0017): assume: will attempt to assume matching connection 'vlan0017'
(b3a61b68-f744-4a4c-a513-61399c154a67) (indicated)
device[c7c5101cf0b73f5f] (vlan0017): assume-state: set guess-assume=0, connection=(null)
Everything great so far, activation of the right connection is enqueued
and the device moves away from unavailable state. However, the
activation can't proceed immediately:
device (vlan0017): state change: unmanaged -> unavailable
(reason 'connection-assumed', sys-iface-state: 'assume')
device (vlan0017): state change: unavailable -> disconnected
(reason 'connection-assumed', sys-iface-state: 'assume')
active-connection[0x55ba1162f1c0]: set device "vlan0017" [0x55ba1163c4f0]
device[c7c5101cf0b73f5f] (vlan0017): queue activation request waiting for carrier
Now another assumption attempt is done. The original assume state is
gone, so a connection is generated:
platform-linux: UDEV event: action 'add' subsys 'net' device 'vlan0017' (6); seqnum=1959
device[c7c5101cf0b73f5f] (vlan0017): queued link change for ifindex 6
manager: (vlan0017): assume: generated connection 'vlan0017' (57627119-8c20-4f9e-bf4d-4fc427b4a6a9)
keyfile: commit: 57627119-8c20-4f9e-bf4d-4fc427b4a6a9 (vlan0017) added as
"/run/NetworkManager/system-connections/vlan0017-57627119-8c20-4f9e-bf4d-4fc427b4a6a9.nmconnection"
(nm-generated,volatile,external)
I think this shouldn't have happened. We've picked the correct
connection already and it's enqueued for activation!
Change the check in nm_device_emit_recheck_assume() to also consider
any queued activation.
Fixes-test: @dracut_NM_vlan_over_team_no_boot
Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1351
(cherry picked from commit 9eb8cbca76)
ModuleNotFoundError was only introduced in later python 3 versions.
Use just "ImportError", which is the parent class anyway.
Fixes: f7e484c8ed ('tests: fix "test-client.py" ignoring missing "NM" module')
(cherry picked from commit 9902373c6d)
If the MAC changes there is the possibility that the DHCP client will
not be able to renew the address because it uses the old MAC as
CHADDR. Depending on the implementation, the DHCP server might use
CHADDR (so, the old address) as the destination MAC for DHCP replies,
and those packets will be lost.
To avoid this problem, restart the DHCP client when the MAC changes.
https://bugzilla.redhat.com/show_bug.cgi?id=2110000
(cherry picked from commit 905adabdba)
nm_utils_enum_to_str() can print flags, that is, combinations of
powers of two integers.
It also supports nicks, for certain flags.
When we have a nick for value zero, then that requires special
handling. Otherwise, that zero nick will always show up in the
string representation, although, it should only be used if the
enum value is exactly zero.
(cherry picked from commit eec9efd989)
1) The "enabled-on-global-iface" flag was odd. Instead, have only
and "enabled" flag and skip (by default) endpoints on interface
that have no default route. With the new flag "also-without-default-route",
this can be overruled. So previous "enabled-on-global-default" now is
the same as "enabled", and "enabled" from before behaves now like
"enabled,also-without-default-route".
2) What was also odd, as that the fallback default value for the flags
depends on "/proc/sys/net/mptcp/enabled". There was not one fixed
fallback default, instead the used fallback value was either
"enabled-on-global-iface,subflow" or "disabled".
Usually that is not a problem (e.g. the default value for
"ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case
it is a problem, because the mptcp-flags (for better or worse) encode
different things at the same time.
Consider that the mptcp-flags can also have their default configured in
"NetworkManager.conf", a user who wants to switch the address flags
could previously do:
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled-on-global-iface,signal,subflow
but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer
honored. That means, MPTCP handling was always on, even if the sysctl was
disabled. Now, "enabled" means that it's only enabled if the sysctl
is enabled too. Now the user could write to "NetworkManager.conf"
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled,signal,subflow
and MPTCP handling would still be disabled unless the sysctl
is enabled.
There is now also a new flag "also-without-sysctl", so if you want
to really enable MPTCP handling regardless of the sysctl, you can.
The point of that might be, that we still can configure endpoints,
even if kernel won't do anything with them. Then you could just flip
the sysctl, and it would start working (as NetworkManager configured
the endpoints already).
Fixes: eb083eece5 ('all: add NMMptcpFlags and connection.mptcp-flags property')
(cherry picked from commit c00873e08f)
Various synchronous methods (D-Bus calls) in libnm's NMClient API were
deprecated. The problem is that NMClient contains a cache of D-Bus
objects, and it gets updated by asynchronous events (D-Bus signals).
Those events get only processed when iterating the GMainContext, but
they are ordered.
When we perform a pseudo blocking D-Bus call with
g_dbus_connection_call_sync(), then GDBus creates a temporary
GMainContext, sends the request and iterates the internal context
blocking for the response. That is, this reply is not synchrounized with
the events that update the NMClient cache.
That is a problem for methods like nm_remote_connection_delete(),
because you call blocking delete, but afterwards the object is still in
the NMClient cache. That's why most blocking methods are deprecated.
While such blocking calls are therefore problematic, they can still be
very convenient to call from a simple script, a test tool or the python
REPL. See "examples/python/gi/nm-wg-set" which calls
nm_remote_connection_get_secrets(), and it would be (unnecessarily)
cumbersome to do the correct thing or using async API.
In particular, nm_remote_connection_get_secrets() doesn't retrieve an object
that is in the NMClient cache in the first place. Sure, the result is
out of order with the cache, but it's not obviously related and in most
cases it wouldn't matter to the user. So undeprecate this function again.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1345
(cherry picked from commit b46d0dcb6f)
Without it, the build artifacts were deleted before getting archived.
It means, the tarball and the docs were no longer archived and no
pages on gitlab no longer updated.
Fixes: e118276296 ('gitlab-ci: run unit tests for git subtree subprojects')
(cherry picked from commit cfe44c8832)
We used
COMPILER_FLAG(LIBSYSTEMD_NM_CFLAGS, "-Wno-gnu-variable-sized-type-not-at-end")
to detect whether the flag is supported. However, that does not work with GCC since
version 4.4 due to https://gcc.gnu.org/wiki/FAQ#wnowarning.
Note that we already had NM_COMPILER_WARNING(), but that again does
something rather different.
The removed signal did not log the interface name.
That's because _LOG3D() takes the ifindex and looks into the platform
cache to find the interface name. However, if the link is already
removed, it won't find it.
Fix that by explicitly using the right name.
Before:
<debug> [1660070838.2976] platform: signal: link removed: 602: testX6 <DOWN;broadcast,multicast> mtu 1500
Now:
<debug> [1660070838.2976] platform: (testX6) signal: link removed: 602: testX6 <DOWN;broadcast,multicast> mtu 1500
- drop unused "keep_deleted" parameter. It just doesn't make sense.
Even less sense than for rules/routes, where this was taken from.
- fix nmp_global_tracker_sync_mptcp_addrs() to delete addresses
with conflicting flags. We did not correctly delete existing
addresses, that were to be reconfigured with different flags.
Fixes: 5374c403d2 ('platfrom: handle MPTCP addresses with NMPGlobalTracker')
This affects parsing global connection defaults from
"NetworkManager.conf".
Let's use a zero base for strtoll(), which honors the prefixes
"0x" and "0" to use hex and octal numbers, respectively. Otherwise
it uses decimal (base 10).
This causes very little ambiguity, but it makes certain numbers
just work.
Also, we have flags properties, where it makes much more sense
to write them in hex, like `connection.mptcp-flags=0x52`.
