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)
"--with test" does two things:
(1) it enables "-Werror" compiler option. We always enable all
compiler warnings we care about, but this option makes all
warnings fatal.
Compiler warnings depend on compiler version and build options.
It's hard to build without any compiler warnings, in particular
for *future* compiler versions which we don't know yet. It
is desirable that a SRPM from yesterday can also be build
tomorrow.
(2) it fails build if any unit tests fail. We always run all
unit tests, but "--with test" makes it fatal. Again, we
have many unit tests that interact with the system (that is,
make system calls, like creating IP addresses or write files).
It is surprisingly hard to get them pass 100% on all the systems
we care. For example, on copr a test setup randomly fails during
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
nm_utils_ifname_cpy(ifr.ifr_name, TEST_IFNAME);
r = ioctl(fd, TUNSETIFF, &ifr);
It's not clear why, nor is it at all clear that there is a bug
in NetworkManager. Making tests fatal basically means that a build
on copr infrastructure fails with a probability from a few percent.
Enough to be seriously annoying.
Note that on copr we actually build "--with test", because we want to catch these
issues. Likewise for our CI builds we explicitly specify "--with test".
In general, we build with various build configurations (compiler warnings)
and run unit tests on a source package many times. Starting on the
developer machine (`make check`), gitlab-ci, copr builds,
NetworkManager-ci. If you build an SRPM with such sources, a failure
of the unit tests is much more likely a glitch than an actual issue.
This is about changing the default if you build a Fedora/RHEL package.
That is with the Fedora/RHEL packages that are build in koji/brew.
Well, at least usually. In practice, we don't build frequently on non
x64_86 archs, so what I said there is less true. But the package build
is not there to replace CI/testing. The package build is there to get
a (mostly) working binary.
Note that RHEL packages anyway go through rpmdiff too, and rpmdiff
parses the build log and complain if `make check` fails.
This reverts commit e68e5c0a4c.
(cherry picked from commit e23bafe5d5)
/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)
Under restricted permissions (like inside a podman container) opening
"/proc/self/ns/net" fails with Permission denied. Consequently we cannot
create our bottom NMPNetns instance. That is mostly fine, however we
would log an error message with severity <error>.
Note that test "src/core/platform/tests/test-platform-general" asserts
that no <warn> and <error> messages get logged. Hence, the test will
fail.
That is undesirable. Downgrade the message to <debug> so that the test
passes. Also, it's not clear that this error message is useful here.
Being unable to open a netns fd is fine and not necessarily an error
condition.
(cherry picked from commit 0213300dce)
We should always register the GArray stack with pthread
for cleanup the thread local storage. Do that first, before
creating the NMPNetns instance at the bottom of the stack.
(cherry picked from commit f9636080ac)
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)
We call `tc` from iproute2, which commonly is at "/sbin/tc".
That might not be in the "$PATH" of a regular user, and consequently
we fail to run the test.
Work around that by always adding "/bin" and "/sbin" to the $PATH.
(cherry picked from commit f591aa41c6)
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)
Add new configure option to set the path to "polkit-agent-helper-1".
The path cannot be obtained from pkg-config and `pkg-config
--variable=prefix polkit-agent-1` is not good enough.
On Fedora, the path is "/usr/lib/polkit-1/polkit-agent-helper-1".
On Debian Buster, the path is "/usr/lib/policykit-1/polkit-agent-helper-1"
On Debian Sid, the path is "/usr/libexec/polkit-agent-helper-1" (but
currently it is also symlinked from "/usr/lib/policykit-1/polkit-agent-helper-1".
(cherry picked from commit 801c41a11c)
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.
