For upstream, we changed behavior here. However, I think certain
downstream don't want to do that, and revert patch "d37ad15f12 keyfile:
also add ".nmconnection" extension when writing keyfiles in /etc".
For that to make easier, keep the upstream sources closer to what
was. Revert.
This reverts commit e93d8cdb74.
is_available would recently return true after IWD had disconnected
if a connection was active because it would check that
priv->dbus_station_proxy was non-NULL (i.e. that the DBus interface was
still visible, which it wasn't) but that check would be overridden
if the NMDevice state was activated. Now require priv->dbus_obj to be
non-NULL, which would even be enough on its own although I'm leaving the
previous check there too to catch potential IWD states we don't support
in which priv->dbus_station_proxy is NULL without an active connection.
Sanity check networks received from the Station.GetOrderedNetworks()
DBus method. Duplicates shouldn't happen but the code should be safe
against bogus data received over DBus. There was a recent bug in a
library used by IWD causing occasional duplicates to be returned which
would cause invalid memory accesses reported by valgrind in NM because
g_hash_table_insert would free what we passed as the key.
Watch for connection-removed events and delete corresponding IWD network
configs if found. This mainly changes anything for 802.1X networks
where the deleted NM connections might annoyingly re-appear after a
restart. For PSK networks though it'll make IWD forget the password
which, until now, would be remembered by IWD even if it was removed or
changed in the NM profile, which is a bug.
This is still fragile because we don't handle "connection-updated"
events so the data->mirror_connection pointer for a known network record
may after some time point to an NMSettingsConnection with a different
SSID or security type and there are corner cases where the IWD-side
profile will not be forgotten. At least I'm trying to make sure we
don't crash and don't wrongly remove any IWD profile which could also be
annoying for complicated EAP configs.
Something is possibly wrong with the DBus signal handling if a newly
added KnownNetwork interface already has an entry in
priv->known_networks, but since we handle this case add a warning and
update the GDBusProxy pointer for that existing entry.
interface_added expects mirror_8021x_connection() to return the pointer to
the existing connection if one exists, and NULL on error, rather than
NULL if a conneciton exists. While touching that, add logic to return
specifically a connection with EAP method set to 'external' if one
exists even though this should not affect any other logic we have
currently.
Some internal logic causes the secrets in a connection to be
occasionally moved to NMSettingConnection's priv->system_secrets after a
connection attempt so we need to use nm_act_request_get_secrets to get
them added to the device's settings connection and applied connection if
the PSK is missing during an AP or AdHoc mode activation (in
infrastructure mode we already do secret requests though they're cached
by IWD in most cases).
The common steps for the PSK available and unavailable scenarios is moved
from act_stage2_config to act_set_mode.
This simplifies the code by using g_variant_lookup. In this handler
where we parse more than one property this is probably slower although
the number of string comparisons will be the same.
NM_CONFIG_KEYFILE_PATH_IN_MEMORY is now called NMS_KEYFILE_PATH_NAME_RUN.
This name seems odd in the current context, it will be more suitable
when we also have NMS_KEYFILE_PATH_NAME_LIB (for /usr/lib).
These utilities are concerned with valid file names (as NetworkManager
daemon requires it). This is relevant for everybody who wants to write
keyfile files directly. Hence, move it to libnm-core. Still as internal
API.
Add a helper function for the common check whether a file is
inside a path. Also, this function handles special cases like
repeated file separators. However, as it is still entirely text
based, it also cannot recognize if two (literally) different
paths reference the same inode/file.
We have a fork of a lot of useful systemd helper code.
However, until now we shyed away from using it aside from
the bits that we really need.
That means, although we have some really nice implementations
in our source-tree, we didn't use them. Either we were missing
them, or we had to re-implement them.
Add "nm-sd-utils.h" header to very carefully make internal
systemd API accessible to the rest of core.
This is not intended as a vehicle to access all of internal
API. Instead, this must be used with care, and only a hand picked
selection of functions must be exposed. Use with caution, but where it
makes sense.
initrd does not use keyfile API from "src/settings/plugins/keyfile",
hence it does not use nms_keyfile_utils_escape_filename() to add
the ".nmconnection" file extension.
I think that is problematic, because it also misses escapings which
are necessary so that NetworkManager will accept the file.
Anyway, the proper solution here would be to move the keyfile utility
functions to libnm-core, alongside base keyfile API. That way, it
could be used by initrd generator.
For now, just dirty fix the generated filename.
Fixes: 648c256b90
For profiles in "/etc/NetworkManager/system-connections", we did not enforce
that the keyfiles have a special suffix, nor did we generate the
filenames in such a manner. In hindsight, I think that was a mistake.
Recently we added "/run/NetworkManager/system-connections" as additional
keyfile directory. Enforce a suffix and write keyfiles with such a name.
In principle, we could also start writing keyfiles in /etc with the
same suffix. But let's not do that, because we anyway cannot enforce
it.
An ugly part is, that during `nmcli connection load` we need to
determine whether the to-be-loaded connection is under /etc or /run.
Preferably, we would allow any kind of symlinking as what matters
is the file object (inode) and not the path. Anyway, we don't do
that but compare plain paths. That means, paths which are not
in an expected form, will be rejected. In particular, the paths
starting with "/run/..." and "/var/run/..." will be treated differently,
and one of them will be rejected.
Note that ifcfg-rh plugin strictly enforces that the path
starts with IFCFG_DIR as well. So, while this is a breaking
change for keyfile, I think it's reasonable.
This is independent functionality that only depends on linux API
and glib.
Note how "nm-logging" uses this for getting the timestamps. This
makes "nm-logging.c" itself dependen on "src/nm-core-utils.c",
for little reason.
When a device is unmanaged, an explicit activation request can
still activate it. In particular, that is the case for
$ nmcli connection up "$PROFILE" ifname "$DEVICE"
It is also the case, for plain
$ nmcli connection up "$PROFILE"
where NetworkManager searches for a suitable device -- depending on
multi-connect setting of the profile.
The idea is, that a profile with "multi-connect=single" is expected
to sufficently and uniquely match a device, based on matching properties
like "connection.interface-name". In that case, an explicit activation
request from the user shows the intent to manage the device.
Note that it's hard to understand whether the profile really uniquely
selects a particular device. For example, if the profile doesn't specify
"connection.interface-name", it might still uniquely identify
an ethernet device, if you only have one such device.
On the other hand, with "connection.multi-connect" other than "single",
it is very much expected that the profile does not strictly match
one device.
Change the behavior here for multi-connect profiles. This allows the
user to block individual devices from activation via
$ nmcli device set "$DEVICE" managed not
A subsequent
$ nmcli connection up "$MULTI_PROFILE"
will not consider "$DEVICE" as suitable candidate for activation.
Likewise, in the future we may want to add a
$ nmcli connection up --all "$MULTI_PROFILE"
command, to activate the profile on all suitable device.
In that case again, unmanaged devices probably also should be skipped
for multi-connect profiles.
https://bugzilla.redhat.com/show_bug.cgi?id=1639254
This flag is more granular in whether to consider the connection
available or not. We probably should never check for the combined
flag NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST directly, but
always explicitly for the relevant parts.
Also, improve the error message, to indicate whether the device is
strictly unmanaged or whether it could be overruled.
The flags NMDeviceCheckConAvailableFlags and NMDeviceCheckDevAvailableFlags
both control whether a device appears available (either, available in
general, or related to a particular profile).
Also, both flag types strictly increase availability. Meaning: more flags,
more available.
There is some overlap between the flags, however they still have
their own distinct parts.
Improve the mapping from NMDeviceCheckConAvailableFlags to
NMDeviceCheckDevAvailableFlags, by picking exactly the flags
that are relevant.
- fix stopping ppp-manager. Previously, we would take a reference
to priv->ppp_manager to cancel it later. However, deactivate_cleanup()
is called first, which already issues nm_ppp_manager_stop().
Thereby, not using a callback and not waiting for the operation
to complete.
- get rid of this "step" state machine. There are litterally two steps
that need to be performed asynchornously. Instead chain the calls.
- it is now obviously visible, that the async callback never completes
synchronously upon being called (provided that all async operations
that it calls themself have this behavior -- which they should).
Previously nm_ppp_manager_stop() would return a handle which
makes it easy to cancel the operation.
However, sometimes, we may want to cancel an operation based on
an GCancellable. So, extend nm_ppp_manager_stop() to hook it
with a cancellable.
Essentially, move the code from nm-modem.c to nm-ppp-manager-call.c,
where it belongs and where the functionality gets available to every
component.
We should not use GAsyncResult. At least, not for internal API.
It's more cumbersome then helpful, in my opinion. It requires
this awkward async_finish() pattern.
Instead, let the caller pass a suitable callback of the right type.
