A failure to cancel something is not worth a warning. It probably
just means that no operation was in progress. In my logs I always
see a warning:
CODE_FILE=src/core/supplicant/nm-supplicant-interface.c
CODE_LINE=391
MESSAGE=<warn> [1624517233.8822] sup-iface[a22b181a321ffd9b,9,wlan0]: call-p2p-cancel: failed with P2P cancel failed
Downgrade this to trace level.
When we are a client in the group we may be assigned an address by the
group owner. Use this address if it is available, but only if we are in
AUTO configuration mode.
In NetworkManager.conf, we can only configure one "[main].dhcp="
for both address families. Consequently, NMDhcpClientFactory
represents also both address families. However, most plugins
don't support IPv4 and IPv6 together.
Thus, if a plugin does not support an address family, we fallback
to the implementation of the "internal" plugin.
Slightly rework the code how that is done. Instead of having
a "get_type()" and "get_type_per_addr_family()" callback, have
an IPv4 and IPv6 getter.
NMConfigData is immutable and with the previous commit are the strings
already cached internally. There is no need to clone it.
Of course, the callers must not assume that the string stays alive after
a config reload (SIGHUP), where the NMConfigData might change. So they
are not always alive, but long enough for all callers to avoid cloning
the string.
Previously, we would call g_key_file_get_string(), which requires
two hash lookups (one for the group and one for the key).
We can do better. Especially since NMConfigData is immutable, it's
simple to build a lookup index of the values we have and then do binary
search.
Note that we call nm_config_data_get_connection_default() and similar
API *a lot*, so this is measurable.
In presence of a IPv6 deprecated address and a non-deprecated one, the
latter will be used by kernel for new connections according to RFC
6724 section 5 (Source Address Selection). Prefer it also to lookup a
hostname via reverse DNS.
While at it, also prefer non-link-local addresses over link-local
ones.
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=1970335https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/895
We now have a cached list of NMSettingsConnection instances,
sorted by their autoconnect priority.
However, the sort order nm_settings_connection_cmp_autoconnect_priority()
depends on various properties of the connection:
- "connection.autoconnect" and "connection.autoconnect-priority"
- the timestamp
- "connection.uuid"
These properties almost never change, so it's a waste that every call
to nm_settings_get_connections_sorted_by_autoconnect_priority() needs
to check whether the sort order is still satisfied.
We can do better by tracking when the sort order might have been
destroyed and only check in those (much fewer) cases.
Note that we end up calling nm_settings_get_connections_sorted_by_autoconnect_priority()
a lot, so this makes a difference.
The GetSettings() call is not the only place where we convert a
NMConnection to D-Bus. However it is one of the most prominent ones
with a measurable performance overhead.
The connection seldom changes, so it makes sense to cache it.
Note that GetSettings() is the only caller that specifies an option,
thus it's the only caller that converts a NMConnection to variant
in this particular way. That means, other callers don't benefit from
this caching and we could not cache the variant in the NMConnection
instance itself, because those callers use different parameters.
Turns out, we call nm_settings_get_connection_clone() *a lot* with sort order
nm_settings_connection_cmp_autoconnect_priority_p_with_data().
As we cache the (differently sorted) list of connections, also cache
the presorted list. The only complication is that every time we still
need to check whether the list is still sorted, because it would be
more complicated to invalidate the list when an entry changes which
affects the sort order. Still, such a check is usually successful
and requires "only" N-1 comparisons.
During timeout we cancel the (internal) GCancellable. But the overall
error reason is not cancellation by the user, it's timeout. Fix
the error reason.
Fixes: 9ebdb967de ('firewall: implement masquerading for shared mode with nftables')
It seems that the nftables backend works well. Let's change the default.
This will also be backported to nm-1-32 branch, for 1.32.0 release.
This reverts commit 0609f1f31c.
The new function resolve an address via DNS, first by using
systemd-resolved (disabling synthesized results) and then by spawning
the daemon helper.
Trying systemd-resolved via D-Bus before spawning the helper is
important to get a correct result. Suppose that resolv.conf points to
the local stub listener at 127.0.0.53; if NM only spawns the helper,
the helper will query the local systemd-resolved which could return a
synthesized result.
Therefore, we first query systemd-resolved with NO_SYNTHESIZE and
then, in case of error, we spawn the helper.
This setting can't be handled IWD (e.g. during autoactivations performed
by IWD) and although for manual activations NM will probably check it,
there's no reason for the IWD backend to restrict new profiles to one
interface plus when running IWD the udev permanent interface naming is
likely to be broken.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/886
The user really must not treat UuidData.bin as a NUL terminated string.
The _nul_sentinel is not necessary. And if by chance the user makes this
fatal mistake, then UuidData.str will still be there to NUL terminate the
buffer, the content is garbage either way.
Remove the sentinel.
nm_uuid_generate_from_string*() accepts an optional namespace parameter,
to seed the hashing. This previously was a UUID in string format, so it
first had to be parsed.
Rework the code to pass a NMUuid instance that can be used directly.
Also, as the type_args parameter is always of the same type, change
the argument from a void pointer to "const NMUuid *" pointer.
- always remember priv->last_state_dir that we received via
D-Bus. Only later, during get_config_path() we will check
whether the path is valid.
- remember in priv->warned_state_dir the full path for
which we warned. We want to print a warning for each
path once, if the path changes, then we also want a new
warning. A boolean flag cannot express that.
Otherwise we see a warning:
<warn> [1622790097.3601] config: unknown key firewall-backend in section [main] of file /etc/NetworkManager/NetworkManager.conf
Fixes: 1da1ad9c99 ('firewall: make firewall-backend configurable via "NetworkManager.conf"')
Since commit 207cf3d5d4 ('libnm: normalize "connection.uuid"') the
"connection.uuid" is normalized to be a valid UUID and all lower case.
That means, if we have .nmmeta files on disk with a previously valid,
but now invalid UUID, the meta file is no longer going to match.
Reject such file outright as invalid. If we really wanted to preserve
backward compatibility, then we would have to also normalize the
filename when we read it. However, that means, that suddenly we might
have any number of compatible .nmmeta files that normalize to the same
UUID, like the files
71088c75dec54119ab41be71bc10e736aaaabbbb.nmmeta
F95D40B4-578A-5E68-8597-39392249442B.nmmeta
f95d40b4-578a-5e68-8597-39392249442b.nmmeta
Having multiple places for the nmmeta file is complicated to handle.
Also, we often have the connection profile (and the normalized UUID)
first, and then check whether it has a .nmmeta file. If we would support
those unnormalized file names, we would have to visit all file names and
try to normalize it, to find those with a matching UUID.
Non-normalized UUIDs really should not be used and they already are not
working anymore for the .nmmeta file. This commit only outright rejects
them. This is a change in behavior, but the behavior change happened
earlier when we started normalizing "connection.uuid".
"uuid" is returned from nms_keyfile_nmmeta_check_filename(),
and contains "$UUID.nmmeta". We must compare only the first
"uuid_len" bytes.
Fixes: 064544cc07 ('settings: support storing "shadowed-storage" to .nmmeta files')
Most of the time, we care about whether we have a normalized UUID.
nm_uuid_is_valid_full() only exists for a particular case where we want
to use the function in a header, without including "nm-uuid.h". In that
case, we actually also care about normalized UUIDs.
If the TC setting contains no qdiscs and filters, it is lost after a
write-read cycle. Fix this by adding a new property to indicate the
presence of the (empty) setting.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1928078
Mimic the behaviour of wpa_supplicant where the "secure" identity in
TTLS and PEAP (802-1x.identity) is used as a fallback in the anonymous
identity (802-1x.anonymous_identity) if that is not provided. This is
needed to keep the profiles compatible between the two wifi backends,
for users of poorly configured WPA-Enterprise networks that require the
user login to be sent in phase 1 or in both phases.
The code responsible for this mechanism in wpa_supplicant, at the time
of writing, is
https://w1.fi/cgit/hostap/tree/src/eap_peer/eap.c?id=c733664be9dd3763c03f2da2cb32a23775dde388#n1688
and offers no comment about the privacy implications.
