It is rather unlikely, that we call this function with no existing
routes/addresses. Hence, usually this does not safe an allocation
of the GPtrArray.
However, it's slightly less code and makes more sense this way
(instead of checking afterwards, whether the array is empty and
destroy it).
The entire point of the dance in nm_platform_ip_address_sync() is to ensure that
conflicting IPv4 addresses are in their right order, that is, they have
the right primary/secondary flag.
Kernel only sets secondary flags for addresses that are in the same
subnet, and we also only care about the relative order of addresses
that are in the same subnet. In particular, because we rely on kernel's
"secondary" flag to implement this.
But kernel only treads addresses as secondary, if they share the exact
same subnet. For example, 192.168.0.5/24 and 192.168.0.6/25 would not
be treated as primary/secondary but just as unrelated addresses, even if
the address cleared of it's host part is the same.
This means, we must not only hash the network part of the addresses, but
also the prefix length. Implement that, by tracking the full NMPObject.
None of the callers really handle the return value of nm_platform_ip_address_sync()
or whether the function encountered problems. What would they anyway do
about that?
For IPv4 we were already ignoring errors to add addresses, but for IPv6 we
aborted. That seems wrong. As the caller does not really handle errors,
I think we should follow through and add all addresses in case of error.
Still, also collect a overall "success" of the function and return it.
In the past, nm_platform_ip_address_sync() only had the @known_addresses
argument. We would figure out which addresses to delete and which to preserve,
based on what addresses were known. That means, @known_addresses must have contained
all the addresses we wanted to preserve, even the external ones. That approach
was inherently racy.
Instead, nowadays we have the addresses we want to configure (@known_addresses)
and the addresses we want to delete (@prune_addresses). This started to change in
commit dadfc3abd5 ('platform: allow injecting the list of addresses to prune'),
but only commit 58287cbcc0 ('core: rework IP configuration in NetworkManager using
layer 3 configuration') actually changed to pass separate @prune_addresses argument.
However, the order of IP addresses matters and there is no sensible kernel API
to configure the order (short of adding them in the right order), we still need
to look at all the addresses, check their order, and possibly delete some.
That is, we need to handle addresses we want to delete (@prune_addresses)
but still look at all addresses in platform (@plat_addresses) to check
their order.
Now, first handle @prune_addresses. That's simple. These are just the
addresses we want to delete. Second, get the list of all addresses in
platform (@plat_addresses) and check the order.
Note that if there is an external address that interferes with our
desired order, we will leave it untouched. Thus, such external addresses
might prevent us from getting the order as desired. But that's just
how it is. Don't add addresses outside of NetworkManager to avoid that.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
No need to try further. The verdict is clear.
From the log:
<debug> [1649424031.1507] connectivity: (wlan0,IPv4,427) can't resolve a name via systemd-resolved: GDBus.Error:org.freedesktop.resolve1.NoNameServers: No appropriate name servers or networks for name found
<debug> [1649424031.1507] connectivity: (wlan0,IPv4,427) start request to 'http://fedoraproject.org/static/hotspot.txt' (try resolving 'fedoraproject.org' using system resolver)
This can lead to a crash. The code might continue to call
system_resolver_resolve(), then it has no more cancellable.
That means, if the task gets cancelled, then the callback
will still return and result in a crash.
There is no need to cancel or clear the cancellable during
normal operation. It will be cleaned up at the end.
This leads to an assertion error (or possibly crash):
...
#6 0x00005584ff461e67 in system_resolver_resolve_cb (source_object=<optimized out>, res=0x5585016b9190, user_data=user_data@entry=0x558501667800) at src/core/nm-connectivity.c:798
#7 0x00007f348a02419a in g_task_return_now (task=0x5585016b9190) at ../gio/gtask.c:1219
#8 0x00007f348a0241dd in complete_in_idle_cb (task=task@entry=0x5585016b9190) at ../gio/gtask.c:1233
#9 0x00007f3489e263eb in g_idle_dispatch (source=0x7f3464001070, callback=0x7f348a0241d0 <complete_in_idle_cb>, user_data=0x5585016b9190) at ../glib/gmain.c:5897
...
Fixes: 57d226d3f0 ('connectivity: resolve hostname ourselves to avoid blocking libcurl')
Supplicant does not allow setting certain properties to empty values.
It also does not make sense.
Also, ifcfg-rh writer uses svSetValueStr() for these properties, so
the ifcfg plugin would always loose having hte values set to "".
Also, you couldn't enter these strings in nmcli.
It's fair to assume that it makes no sense to have these values set to
an empty value. Since we cannot just tighten up verification to reject
them, normalize them.
It also seems that some GUI now starts setting domain_suffix_match to an
empty string. Or maybe it was always doing it, and ifcfg plugin just hid
the problem? Anyway, we have users out there who set these properties to
"".
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/973
Currently NetworkManager fails to establish a NAP bridge because it never gets
out of the stage2.
This is caused because when making the BlueZ callback reentrant we return
NM_ACT_STAGE_RETURN_POSTPONE even after registration has succeeded.
This patch changes registration to a three state automaton instead of a
boolean. This allows distinguishing when we are waiting for registration
to finish and when it is done and therefore ensures that when the stage2
is called again by the callback the result is success so NetworkManager
can proceed to the IP configuration.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1181
When the ovs-bridge datapath is netdev, OpenvSwitch will not create a
ovs-interface but a tun interface. The ovs-interface device must check
all the link-change signals and check if the link type is tun and the
interface name is the same than the device name. If so, the
ovs-interface device will get the ifindex of the tun device. This allow
NetworkManager to manage the interface properly, modifying MTU,
configuring IPv4/IPv6 and others.
Example:
```
55: ovsbridge-port0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether fa:fb:07:98:e0:c6 brd ff:ff:ff:ff:ff:ff
inet 192.168.123.100/24 brd 192.168.123.255 scope global noprefixroute ovsbridge-port0
valid_lft forever preferred_lft forever
inet6 fe80::9805:55c4:4c5f:da1c/64 scope link noprefixroute
valid_lft forever preferred_lft forever
```
https://bugzilla.redhat.com/show_bug.cgi?id=2001792https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1179
For regular operation -- even for `level=TRACE` -- it's just too verbose.
Only enable it if the environment "NM_LOG_CONCHECK=1" is set.
An environment variable is a bit unwieldy to use, but this
is really just for a heavy libcurl debugging session.
We have some reports of APs that advertise WPA2/WPA3 with
MFP-required=0/MFP-capable=0, and reject the association when the
client doesn't support 802.11w.
According to WPA3_Specification_v3.0 section 2.3, when operating in
WPA3-Personal transition mode a STA:
- should allow AKM suite selector: 00-0F-AC:6 (WPA-PSK-SHA256) to be
selected for an association;
- shall negotiate PMF when associating to an AP using SAE.
The first is guaranteed by capability PMF; the second by checking that
the interface supports BIP ciphers suitable for PMF.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/964https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907
Move initialization of NMSettingBridge from NMPlatformLnkBridge to separate
function.
This is needed because this initialization will be used in more than one
function.
We store the timestamp when a profile activated the last time to
"/var/lib/NetworkManager/timestamps". There was also a timer which
would update the timestamp of activated connections every 300 seconds.
That seems unnecessary, drop it.
For one, waking up every 5 minutes and rewriting a file to disk seems
undesirable, for example if /var is a device where unnecessary writes
should be minimized.
Note that we already update the timestamp when a device goes down,
and of course when it comes up. Updating the timestamp in between seems
unnecessary.
This reverts commit 607350294d ('core: update timestamp in active
system connections every 5 mins (bgo #583756)').
An alternative would be to only update the timestamp in memory (so that
it would appear updated on D-Bus), but delay writing the file until
something important happens. `nm_key_file_db_*()` already tracks whether
there are changes ("dirty") and whether it's necessary to write the
file. It would be possible to track two dirty flags: one that requires
immediate update, and one that only ensures we will re-write dirty files
eventually.
See-also: https://bugzilla.gnome.org/show_bug.cgi?id=583756https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1171
Our convention is that a function that fails MUST set the GError output.
No need to check for that in nm_crypto_is_pkcs12_data(). Simplify the
error paths.
Also, in gnutls' _nm_crypto_verify_pkcs12(), don't call gnutls_pkcs12_deinit()
before gnutls_strerror(). It's unclear whether that couldn't set a
different error reason.
It has no actual dependency on the crypto library. All it does, is
to be careful about not leaking secrets in memory. We have code
for that in libnm-glib-aux already. Move.
The goal is to reduce the number of places where we use libnm-crypto,
because that has a large dependency. libnm-glib-aux is a very light
dependency instead.
libnm-core is also used by the daemon, thus currently dragging in
libnm-crypto there. But could we ever drop that dependency?
One use of the libnm-crypto is in functions like nm_utils_file_is_certificate()
in "nm-utils.h". These are part of the public API of libnm.
But this is not used by the daemon. Move it to "libnm-client-core"
to be closer to where it's actually used.
As we have unit tests in "libnm-core-impl/tests" that test this function,
those unit tests also would need to move to "libnm-client-impl".
Instead, add the actual implementation of these function to "libnm-crypto"
and test it there.
This patch moves forward declarations from public header "nm-utils.h" to
"nm-client.h". Arguably, "nm-client.h" is not a great name, but we don't
have a general purpose header in "libnm-client-public", so use this.
Note that libnm users can only include <NetworkManager.h> and including
individual files is not supported (and even prevented). Thus moving
the declarations won't break any users.
libnm-core currently has a dependency on crypto libraries (either
"gnutls", "nss" or "null"). We need this huge dependency for few cases.
Move the crypto code to a separate static library"src/libnm-crypto/libnm-crypto.la".
The reasoning is that it becomes clearer where we have this dependency,
to use it more consciously, and to be better see how it's used.
We clearly need the crypto functionality in libnm. But do we also need
it in the daemon? Could we ever link the daemon without crypto libraries?
The goal of splitting the crypto part out, to better understand the
crypto dependency.
"nm-error.h" is public API of libnm, and contains error numbers and
quarks. Clearly our "nm-crypto" implementation wants to use those
errors.
I want to move "nm-crypto" out of libnm, and as it's more basic, I think
it should not have a dependency on all of libnm-core. Also because
libnm-core currently uses nm-crypto, so there would be a circular
dependency. Which would be possible to do (libnm-core-aux-intern is
also used in such a way). But it's better avoided, to have clear
hierarchy of dependencies.
Add a version of the same error codes to libnm-base. libnm-base is a
very basic dependency (just one step above libnm-glib-aux).
nm_utils_bin2hexstr() is part of public libnm API.
That means, if we want to use this function, we need to link with
libnm-core-impl.
This is used by "nm-crypto.c". That file is currently part of
libnm-core, but that will change.
Move the implementation to libnm-glib-aux, so that we can use this code
from all our glib-based code (because all our glib-based code is allowed
to link with libnm-glib-aux).
When a static function only has one caller, it is often simpler to not
have the code in a separate function. Drop need_private_key_password()
and move it to need_secrets_tls().
g_warning() for unexpected scheme is not right. Either, this should be an
assertion (and never be hit), or the library should be silent about conditions
that can happen regularly.
I think code is easier to understand, if the difference (between phase1
and phase2) is pushed to the bottom. Having one large "if(phase2){}else{}"
at the top makes it harder to compare the two branches and see where
they differ.
