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.
Previously, we would check that all characters are ASCII. But we would
also accept NUL characters (and truncate on the first NUL).
Now:
- reject any NUL characters inside the string (except trailing NUL).
- accept all characters, and if necessary backslash-encode non UTF-8.
The hostname is in the end a string, which means it must be in a known,
sensible encoding (UTF-8). Previously, we would not ensure the encoding,
nor that the hostname was valid.
Fix that. Follow what systemd does with lease_parse_domain().
See-also: https://tools.ietf.org/html/rfc2132#section-3.14
It's not clear why the option argument would be optional.
Also, it's not optional for nm_dhcp_option_take_option().
Add an nm_assert() to catch such wrong uses.
NMStrBuf's API is all about convenience. When you reset the buffer,
is it convenient to immediately append a new string?
It seems not. Make nm_str_buf_reset() simpler by doing only one thing.
IWD's "open" networks can be either unsecured or use OWE and "psk"
networks may be using WPA2 personal or WPA3 personal so when looking for
an exsiting NMSettingsConnection matching an IWD KnownNetwork, also
check for these connection key_mgmt types.
Add explicit checks for AP and ADHOC connection modes to exclude OWE and
SAE as they're not supported by IWD in those modes and we don't want to
make it appear like a connection of this type was successfully
activated.
In Infrastructure mode there's won't be any way to know whether IWDxi
established an OWE or unsecured connection (or WPA2-PSK vs. SAE)
regardless of what was set in the NMConnection and it's not considered
to be meaningful (also isn't normally exposed in a GUI) although you
could argue OWE vs. unsecured is a big difference.
IWD doesn't expose on D-Bus, or in the network profile files, the
information on whether a network has no security or uses OWE so they
should be the same thing to the iwd backend (similarly WPA2-Personal and
WPA3-Personal/SAE). But OWE implies some security against some attacks
so the NONE naming could be misleading.
Before there was a licensing conflict between the keyfile code
(libnm-keyfile) and libnm. The latter would require LGPL-2.1+ while
keyfile code was GPL-2.0+.
Consequently we were linking libnm-keyfile into the daemon, but not in
libnm.so.
This conflict has been resolved and keyfile API is part of libnm.so.
There is no more need to build a separate (intermediary) library. Merge
them.
This also makes sense because keyfile code needs access to private code
from libnm-core. It is closely tied to libnm-core, so that building them
separate makes no sense (anymore).
"shared/nm-meta-setting.[hc]" contains meta data about settings.
As such it is similarly used by libnm-core (as internal API) and
by clients (as extension of public API of libnm). However, it must
be compiled twice, because while it defines in both cases a
NMMetaSettingInfo type, these types are different between internal and
public API.
Hence, the files must also be compiled twice (and differently), once
against libnm-core and once against the client helper library.
Previously, the file was under "shared/", but there it's a bit odd
it doesn't clearly belong anywhere.
There are two goals here:
- copy the file to the two places where it is used. We also have
a "check-tree" unit test that ensures those files don't diverge in
the future.
- we no longer require CFLAGS set during built. Instead, the sources
should control the build. For that we have new (simple) headers
"nm-meta-setting-base.h" that define the right behavior for the
impl files.
There is still an ugliness (among several): the files must be named the
same for libnm-core and clients/common. Preferably, all our sources have
unique names, but that is not possible with this scheme (without
introducing other ugliness). To mitigate that, include the files only at
one exact place.
We got rid of all these redundant defines. All we need, is the base
source directory, which we already define in config.h as
NM_BUILD_SRCDIR. Use that.
Currently if we detect that a scan finished in
_scan_notify_is_scanning(), we call immediately _scan_kickoff() (which
might start a new scan) and then we check again whether the device can
autoactivate or whether to remove the wifi-scan pending action.
This means that if the scan takes long enough, when
_scan_notify_is_scanning() is called, it is already time to start
another scan and the device activation will be delayed. It will be
delayed until the scan duration becomes shorter than the
exponentially-growing periodic scan interval.
Fix this by delaying the next scan immediately after a scan result.
Co-authored-by: Thomas Haller <thaller@redhat.com>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/574
