Currently, ip4 new config signal is being emitted twice, due
to the lack of a barrier to a possible situation. This
commit includes this.
This fixes a crash on NMCI tests due to an assertion failure,
now it will not go ahead in the function anymore if it is under the
undesired conditions.
The backtrace of the crashes can be found at
https://bugzilla.redhat.com/show_bug.cgi?id=2028385
Previously (on RHEL<=8 and Fedora<=35), NetworkManager package contains
the compat scripts nm-ifup/nm-ifdown.
If initscripts package (not network-scripts!) is installed, then a RPM
trigger links them as alternatives for the ifup/ifdown commands.
One problem is that `dnf provides /usr/sbin/ifup` lists the
NetworkManager package. Which is technically true, but on RHEL9 where
initscripts is not installed by default, `dnf install NetworkManager`
does not actually create those scripts.
Solve that by moving those scripts to a new subpackage
NetworkManager-initscripts-updown. The %post script now always creates the
alternatives links, regardless whether initscripts package is installed.
Note that on RHEL8, NetworkManager package not only Obsoletes: but also
Suggests: the new package.
The name "initscripts-updown" is chosen because in the future we might
have additonal initscripts/ifcfg related subpackages to contain the
ifcfg-rh plugin (NetworkManager-initscripts-ifcfg) or ifcfg-rh migration
tools (NetworkManager-initscripts-tools).
https://bugzilla.redhat.com/show_bug.cgi?id=2022418https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1061
While (and after) NMClient gets destroyed, nm_device_get_active_connection()
gives a dangling pointer. That can lead to a crash. This probably
affects all NMLDBusPropertyO type properties.
It's not clear how to fix that best. Usually, NMClient does updates in
two phases, first it processes the D-Bus events and tracks internal
data, then it emits all GObject signals and notifications.
When an object gets removed from the NMClient cache, then the second
phase is not fully processed, because the object is already removed
from the cache. Thus, the property was not properly cleared leaving
a dangling pointer.
A simple fix is to always clear the pointer during the first phase. Note that
effectively we do the same also for NMLDBusPropertyAO (by clearing the
"pr_ao->arr"), so at least this is consistent.
Somehow it seems that we should make sure that the "second" phase gets
full processed in this case too. But it's complicated, and it's not
clear how to do that. So this solution seems fine.
https://bugzilla.redhat.com/show_bug.cgi?id=2039331https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/896
When destroying NMClient, nm_device_get_active_connection() still
return dangling pointers. Add a unit test for that bug.
Obviously, the bug currently exists, so the relevant code is commented
out.
Why? Because I often use a command line like
$ ./tools/run-nm-test.sh -m src/libnm-client-impl/tests/test-nm-client -p /libnm/device-connection-compatibility
or even alias it to a one character command `x`.
Usually I want to do the rebuild, and as `make` is so slow, it
adds noticeable time running the command. Thus, sometimes I want
to modify the command, for which I have to edit the command from the
history, or toggle two separate commands.
Add a `-M` flag that can reverse the effect of an earlier `-m`.
An "enable" flag in general should just also have a "disable" flag.
In function 'nm_uuid_unparse',
inlined from 'nm_uuid_generate_from_string_str' at src/libnm-glib-aux/nm-uuid.c:393:12,
inlined from 'nm_uuid_generate_from_strings.constprop' at src/libnm-glib-aux/nm-uuid.c:430:16:
src/libnm-glib-aux/nm-uuid.h:37:12: error: 'uuid' may be used uninitialized [-Werror=maybe-uninitialized]
37 | return nm_uuid_unparse_case(uuid, out_str, FALSE);
| ^
src/libnm-glib-aux/nm-uuid.c: In function 'nm_uuid_generate_from_strings.constprop':
src/libnm-glib-aux/nm-uuid.c:20:1: note: by argument 1 of type 'const struct NMUuid *' to 'nm_uuid_unparse_case.constprop' declared here
20 | nm_uuid_unparse_case(const NMUuid *uuid, char out_str[static 37], gboolean upper_case)
| ^
src/libnm-glib-aux/nm-uuid.c:390:12: note: 'uuid' declared here
390 | NMUuid uuid;
| ^
lto1: all warnings being treated as errors
The problem are code paths with failed g_return*() assertions. Being in
a bad state already, they don't bother to ensure proper return values,
and with LTO the compiler might think there are valid code paths wrongly
handled. Work around.
If the connection has wfd_ies set, we want to ensure that a WFD
connection is being established so we want to check that the target peer
also supports WFD. For now this in the IWD backend only.
However, WFD peers will send us their WFD IEs in their Probe Responses
only if our own Probe Request contained a WFD IE, or at least that's
when the spec mandates that they include the WFD IE. This implies that
the discovery phase (NM.Device.WifiP2P.StartFind(options) / .StopFind())
needs to know the value of the local WFD IE and include it in the Probe
Requests, which existing clients (gnome-network-displays) doesn't do and
in fact can't do because there's no API for the client to pass the WFD
IE -- that is easy to add in the options parameter though (a
dictionary).
The current situation is that with the wpa_supplicant backend we'll
sometimes see the WFD IE (when the peer is discovered from a Probe
Request that it has sent, rather than from a Probe Response) and
sometimes not, while with the IWD backend we'll never see the WFD
information because IWD assumes that the client (NM) is not interested
in seeing it if it hasn't registered the local WFD information before
starting discovery.
So, for compatibility with this existing situation and with the
wpa_supplicant backend, ignore whether the peer is a WFD peer except in
the PREPARE stage. In PREPARE, if we have a peer compatible with the
connection being activated -- except for the WFD information -- force a
new discovery, this time passing the WFD information from the
NMSettingConnection's wfd_ies, and only progress to CONFIG if the target
peer is re-discovered as a WFD peer within 10 seconds.
We don't actually check the contents of the WFD IEs to match, e.g. we
don't check the sink/source/dual role compatibility between our and the
peer's properties, but IWD will do some of these checks later during
activation.
Similarly as with wpa_supplicant, create NMDeviceIwdP2P objects for P2P
devices based on data from IWD -- not in NMWifiFactory::create_device
because that is only triggered for system netdevs and a P2P-Device
virtual interface has no netdev. Unlike NMDeviceWifiP2P,
NMDeviceIwdP2P's iface property is a unique string that likely doesn't
match any system interface name -- in theory there doesn't need to be
any related netdev on the system (such as an Infrastructure-mode
interface) before a P2P-Device is added.
[thaller@redhat.com: modified original patch]
Since the NM D-Bus API talks to the client using raw WFD IE bytes and
IWD's API wants/provides some of the actual values from the WFD IE
instead (e.g. boolean Source and Sink properties), we need to be able to
parse and build the WFD IE from those property values to do the
translation, add utilities for this. Use one of them to build the WFD IE
property on NMWifiP2PPeer objects.
[thaller@redhat.com: modify original patch to use
nm_g_variant_unref() and add missing #define]
In NMWifiFactory, move the check that prevents NMDevice's from being
created for interfaces in Monitor and other modes, out of the
wpa_supplicant-specific block so that it applies to both IWD and
wpa_supplicant. This check allows P2P device creation to work
differently that Infrastructure, Ad-Hoc and AP modes so it's needed for
P2P support in the IWD backend.
While there change the check to list the modes that are accepted rather
than rely on some of the modes (Monitor, P2P-{Device,Client,GO}) being
bunched together as _NM_802_11_MODE_UNKNOWN.
The interface name has changed in 2019 but the WSC interface has
never been used by NM. Update #define NM_IWD_WSC_INTERFACE in
nm-iwd-manager.h accordingly.
In function '_nm_auto_g_free',
inlined from 'test_tc_config_tfilter_matchall_mirred' at src/libnm-core-impl/tests/test-setting.c:2955:24:
./src/libnm-glib-aux/nm-macros-internal.h:58:1: error: 'str' may be used uninitialized [-Werror=maybe-uninitialized]
58 | NM_AUTO_DEFINE_FCN_VOID0(void *, _nm_auto_g_free, g_free);
| ^
src/libnm-core-impl/tests/test-setting.c: In function 'test_tc_config_tfilter_matchall_mirred':
src/libnm-core-impl/tests/test-setting.c:2955:24: note: 'str' was declared here
2955 | gs_free char *str;
| ^
lto1: all warnings being treated as errors
lto-wrapper: fatal error: gcc returned 1 exit status
We need to support systems where there are hundereds of thousand routes
(e.g. BGP software).
For that, we will ignore routes that have a rtm_protocol value which was
certainly not created by NetworkManager. Before we had a BPF filer to
filter them out, but that had issues and is removed for now. Still,
don't put those routes in the platform cache and ignore them early.
Note that we still deserialize the RTM_NEWROUTE message to a NMPObject,
and don't shortcut earlier. The reason is that we should still call
delayed_action_refresh_all_in_progress() and handle the RTM_GETROUTE
response, even if the route has a different protocol. So we error out
later, shortly before putting the object in the cache. This means we
will malloc() a NMPObject and initialize it, but that is probably cheap,
compared to the first problem that the process already had to wake up
and read the netlink socket.
This restores the effective behavior of the BPF filter, albeit with a
higher overhead, as the route is rejected later. The important part for
now is that we stick to the behavior of not caching certain routes of a
certain protocol. If that can in the future be optimized (e.g. by a new
BPF filter), then we should do that. But for now that would be only a
future performance improvement, which requires new profiling first and
that has not the highest priority. Note that not caching certain routes
already should reduce the largest part of the overhead that those routes
brings. Whether this form is sufficient to reach the expected
performance goals, needs to be measured in the future.
The socket BPF filter operates on the entire message (skb). One netlink
message (for RTM_NEWROUTE) usually contains a list of routes (struct
nlmsghdr), but the BPF filter was only looking at the first route to decide
whether to throw away the entire message. That is wrong.
This causes that we miss routes. It also means that the response to our
RTM_GETROUTE dump request could be filtered and we poll/wait (unsuccessfully)
for it:
<trace> [1641829930.4111] platform-linux: netlink: read: wait for ACK for sequence number 26...
To get this right, the BPF filter would have to look at all routes in the
list to find out whether there are any we want to receive (and if
there are any, to pass the entire message, regardless that is might also
contain routes we want to ignore). As BPF does not support loops, that
is not trivial. Arguably, we still could do something where we look at a
bounded, unrolled number of routes, in the hope that there are not more
routes in one message that we support. The problem is that this BPF
filter is supposed to filter out massive amounts of routes, so most
messages will be filled to the brim with routes and we would have to
expect a high number of routes in the RTM_NEWROUTE that need checking.
We could still ignore routes in _new_from_nl_route(), to enter the
cache. That means, we would catch them later than with the BPF filter,
but still before a lot of the overhead of handling them. That probably
will be done next, but for now revert the commit.
This reverts commit e9ca5583e5.
https://bugzilla.redhat.com/show_bug.cgi?id=2037411
NMConnection is an interface, implemented by NMSimpleConnection
and NMRemoteConnection. A connection is basically a set of NMSetting
instances.
Usually you would expect that one NMSetting instance only gets added to
zero or one NMConnection. It seems a bit ugly, to have one setting tracked by
multiple NMConnection. Still, technically I am not aware of a single problem
with doing that, where it not for NMSimpleConnection:dispose() to clear the
secrets.
There is no need to clear the secrets of an NMSetting, when the
NMConnection gets destroyed. Either this destroys the NMSetting instance
right away (and NMSetting's destructor will clear the secrets anyway), or
somebody else (e.g. another NMConnection instance), keeps the setting
alive. In the latter case, it is wrong to clear the secrets at
this point.
This was done since commit 6a19e68a7d ('libnm-core: clear secrets from
NMSimpleConnection and NMSettingsConnection dispose()'), but let's stop
doing that.
This also causes problems in practice, see [1].
[1] https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1099#note_1334333https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/876https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1056
The n-acd instance gets reset in various cases, for example
when the MAC address changes or during errors.
When that happens, we also need to forget all our pending probes,
because they would reference to a now-defunct n-acd instance.
When the address is currently in state NM_L3_ACD_ADDR_STATE_READY,
we possibly have a pending probe. We need to clean that up. Handle
it the same as in the other cases. Yes, this means we forget about
that the address was ready. But a reset of the n-acd state is a dramatic
event. It warrants some drastic start-over.
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=2026288
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=2028422
See-also: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1035
Fixes: 9a76b07f74 ('l3cfg: fix assertion failure')
While NetworkManager is of course (mostly) single threaded,
our static functions really should be thread safe.
"mostly" single threaded because we have GDBus's worker
thread, we use a thread for writing non-blocking SR-IOV sysctl,
in the past (or still?) we used a thread for async glibc resolver.
Anyway, a low-level function like must be thread safe, when it
uses global data.
Granted, the initialize-once pattern with the flag and the
int variable, is probably in many cases good enough. But it
makes me unhappy, the thought of accessing static data without
a synchronized operation.
This partly restores the previous behavior. The point of the
file owner check is to ensure that the file cannot be read
by unpriviledged processes as it may contain secrets. If the
file is owned by root, that is considered secure (even if our
euid is different).
Possibly, if our euid is not root, then we couldn't read the
file, but that is a different problem.
There is a hierarchy of how files include each other. "main-utils.h"
is pretty much at the bottom (one above "main.c"), in the sense that
it only includes other headers, but is not included itself (aside
"main.c").
Move the utils function to a place where its accessible from everywhere
and rename.
All callers of _nm_setting_get_private() got the offset from the
property info. Add a wrapper _nm_setting_get_private_field() that
takes the property info. This way, it can add some assertions.
Preferably, we embed the private struct in the GObject struct itself.
In the past, we didn't do that, because the struct was in public headers
and changing that would have been an ABI break. For those struct, we
still use g_type_class_add_private().
We have some structs, where the private struct is embedded. An
alternative to that would be, to not have the private struct at all,
like done for NMSettingOvsBridge.
Anyway. So for direct properties we need to capture the offset of the
field (in the private struct). We can either set the offset of the
private struct in _nm_setting_class_commit() to zero and let the field
offset include the private structure offset. Or, the offset of the
private struct is accounted during _nm_setting_class_commit().
Both approaches are basically the same. Just do it consistently. For no
particular reason, choose to set the offset of the private data to zero
for those types.
Several properties like "connection.type" are enum-like and only take a few
known values. We can use a NMRefString to share their instances.
Currently nm_setting_duplicate() does not yet explicitly handle direct properties.
But it should, because it can handle them more efficiently. If it would do that, it
would be very cheap to "copy" a NMRefString. But even with the current implementation
will the result be deduplicated.
