When we deactivate a device, we flush all IP addresses and
routes. Thus, have yet another sync mode for that. It will sync more
than "ALL".
(cherry picked from commit e226b5eb82)
When using IWD-side autoconnect mode (current default), in .deactivate()
and .deactivate_async() refrain from commanding IWD to actually
disconnect until the device is managed. Likely the device is already
disconnected but in any case it's up to IWD to decide in this mode.
Calling IWD device's .Disconnect() D-Bus method has the side effect of
disabling autoconnect and doing this while NM is still in platform-init
was unexpectedly leaving the device without autoconnect after
platform-init was done, according to user reports.
Fixes: dc0e31fb70 ('iwd: Add the wifi.iwd.autoconnect setting')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/786
(cherry picked from commit 1708e9a3cc)
Ignore a rd.znet argument without subchannels. When using net.ifnames
(the default), subchannels are used to build the interface name, which
is required to match the right connection.
With net.ifnames=0 the interface name is build using a prefix and a
global counter and therefore in theory it is possible to omit
subchannels. However, without subchannels there won't be a udev rule
that renames the interface and so it can't work.
https://bugzilla.redhat.com/show_bug.cgi?id=1931284https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/783
(cherry picked from commit 0f8fe3c76b)
802-1x.optional=yes means that NM should tolerate a failure or a
timeout of the 802.1X authentication and should keep the connection
up. Even if the authentication doesn't succeed, NM keeps the
supplicant running so that it can continue trying.
If the supplicant disappears because it crashed or was killed
externally, NM should fail the connection so that it can be retried.
The current code is wrong also because after releasing the supplicant
interface, it calls wired_auth_cond_fail() which tries to connect a
signal to priv->supplicant.iface (which is NULL).
https://bugzilla.redhat.com/show_bug.cgi?id=1934291https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/776
(cherry picked from commit 840e54a96c)
If an existing connection has an interface name set and the generator
finds a BOOTIF argument, it creates a new connection for BOOTIF.
Instead, the generator should set the MAC in the existing connection;
this sounds more correct and it is what the network-legacy module
does.
https://bugzilla.redhat.com/show_bug.cgi?id=1915493
(cherry picked from commit 389575a6b1)
Currently we unconditionally reset the MAC to the previous value after
releasing ports. This has some disadvantages:
- by default, after the last port is removed the bond will have one
of the previous port's address, which could conflict with the port;
- in some cases, changing the bond MAC is not possible. For example
when the bond is active-backup and has fail_over_mac=1|2. In such
case the netlink call succeeds, but the address doesn't
change; then NM would keep waiting for some time.
Don't try to restore the MAC unless the bond connection has a cloned
MAC set.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/775
(cherry picked from commit 190fd9aa9f)
With systemd-resolved, NetworkManager considers `/etc/resolv.conf`
unmanaged. This breaks hostname lookups in a subtle way: when a new
connection comes online, NM will initiate the hostname lookup *before*
propagating DNS updates to systemd-resolved, which of course will cause
the request to fail. And because NM doesn't update `/etc/resolv.conf`,
it doesn't emit a `CONFIG_CHANGED` signal which would've restarted the
lookup.
Fix this by emitting a signal also when using a caching DNS plugin.
https://bugzilla.redhat.com/show_bug.cgi?id=1933863https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/770
(cherry picked from commit 1c0932a6e6)
The bond option ad_actor_system only matters (and is available) with
mode=802.3ad.
When you create a new bond, the sysctl value will be set to "00:00:00:00:00:00".
So this seems to be a valid value, and in fact the default value for
this option. However, kernel will fail with EINVAL to set the sysctl to
"00:00:00:00:00:00". Kernel fails both if the value is already
"00:00:00:00:00:00" (i.e. setting the same value results in an error) and
it also fails otherwise (i.e. we cannot ever reset the value to
"00:00:00:00:00:00", at least not via sysfs).
Avoid the warning in the common case, where the value is already as
expected.
Otherwise, we still get the warning and won't be able to set the right
value. But this is really a limitation of the kernel API where we cannot
do anything about it (in NetworkManager).
https://bugzilla.redhat.com/show_bug.cgi?id=1923999
(cherry picked from commit 9e7af31454)
A connection with key-mgmt=wpa-psk should be able to connect to WPA,
WPA2 and WPA3 APs, choosing the best candidate automatically.
Also pass SAE (WPA3) key-mgmt to wpa_supplicant when it is supported.
For example, I now get this when connecting to a WPA2 network:
<info> [1613749711.2915] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK SAE FT-SAE'
(cherry picked from commit f5d78c2d28)
fixes segfault with iwd backend after upgrade to NetworkManager 1.30.0
Signed-off-by: Jan Palus <jpalus@fastmail.com>
Fixes: 43fd93d8f4 ('iwd: Order objects from g_dbus_object_manager_get_objects')
(cherry picked from commit 2e0752b1bf)
/route/ip6: NMPlatformSignalAssert: ../src/core/platform/tests/test-route.c:449, test_ip6_route(): failure to accept signal one time: 'ip6-route-changed-added' ifindex 0 (2 times received)
(cherry picked from commit 39c3eacb7d)
Since we always set autoconnect-retries=1, use the value of
rd.net.dhcp.retry as a multiplier for the DHCP timeout.
(cherry picked from commit 099ce63888)
By default a connection is retried 4 times before it is blocked from
autoconnecting. This means that if a user specifies an explicit DHCP
timeout in the initrd command line, NM will wait up to 4 times more.
Instead, set the "connection.autoconnect-retries" property of
connections always to 1, so that NM only waits for the time
specified.
Before this commit a default DHCP connection would take at most (45 x
4) seconds. Since the multiplier is now only 1, also increase the DHCP
timeout to have a total time of (90 x 1) seconds, which is the half
than before.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/559
(cherry picked from commit 7e126fe898)
We periodically re-resolve the DNS name for entpoints. Since WireGuard
has no concept of being connected, we want to eventually pick up
if the DNS name resolves to a different IP address.
However, on resolution failure, we will never clear the endpoint we
already have. Thus, resolving names can only give a better endpoint,
not remove an IP address entirely.
DNS names might do Round-Robin load distribution and the name of the
endpoint might resolve to multiple IP addresses. Improve to stick to
the IP address that we already have -- provided that the IP address
is still among the new resolution result. Otherwise, we continue to
pick the first IP address that was resolved.
(cherry picked from commit 98348ee539)
In C, initialization of a union does not define that excess memory
is initialized. Ensure that, by initializing the largest member of the
NMSockAddrUnion union.
(cherry picked from commit 7bf2ddf73f)
Inside a podman container (without `--priviledged`) we don't have
permissions for "unshare(CLONE_NEWNET|CLONE_NEWNS)".
It's not useful to fail tests in environments where they cannot run.
Skip them.
(cherry picked from commit ecdbb1ab84)
Don't request new copies of strings from g_variant_get() to avoid
leaking memory as pointed out by Thomas Haller.
Fixes: dc0e31fb70 ('iwd: Add the wifi.iwd.autoconnect setting')
(cherry picked from commit 5ccb8ce17a)
On copr build, it seems possible that the ioctl fails with
ERROR: src/core/devices/tests/test-lldp - Bail out! NetworkManager:ERROR:src/core/devices/tests/test-lldp.c:823:_test_recv_fixture_setup: assertion failed (errno == 0): (1 == 0)
(1 is EPERM). Unclear why this happens. But as it only affects the
test setup, retry a few times.
Granted, for debugging this information is useful. However, to actually
debug an issue thoroughly, level=TRACE is anyway required. There is simply
no way how we can log useful debug information and not flood logging
messages for regular use.
For example, logging the DHCP lease options can easily print 30 lines.
And this, every time you get a lease update (e.g. every 30 minutes) and
for every interface that does DHCP.
It's simply too verbose. Downgrade the logging level.
Yes, now our default <info> level is even less useful to understand what
is going on. But the majority of time, users don't care so not spamming
the log is more important.
However, we still log the DHCP event (and the IP address) with <info>
level.
Previously, we would pass around the list of options. However,
- that isn't too nice to read. Also, usually when we want to treat
IP address families generically, then we have an addr_family argument.
Having to first resolve the addr_family to another set of variables
is inconvenient.
- the option array itself doesn't have enough information. For example,
we don't know how many elements there are, we don't know which address
family it is (unless we compare it to one of the two well known
lists).
For example, I'd like to do a binary search for the option. But that's
not immediately possible, because the length is unknown.
- in practice, there are only two address families: AF_INET and
AF_INET6. It is extremely unlikely that we will require a third
DHCP options list, and even if we had that, the addr_family argument
still abstracts them nicely.
We also don't need two different lists for one DHCP type. While that
would currently be possible (and afterwards not anymore), it would
be wrong to do.
- also add a new accessor nm_dhcp_option_find() to find the NMDhcpOption
instance by option number.
https://tools.ietf.org/html/rfc2132#section-2 says:
Options containing NVT ASCII data SHOULD NOT include a trailing NULL;
however, the receiver of such options MUST be prepared to delete trailing
nulls if they exist.
It speaks in plurals.
