Active-connections in the async_op_lst are not guaranteed to have a
settings-connection. In particular, the settings-connection for an
AddAndActivate() AC is set only after the authorization succeeds. Use
the non-asserting variant of the function to fix the following
failure:
nm_active_connection_get_settings_connection: assertion 'sett_conn' failed
1 _g_log_abort()
2 g_logv()
3 g_log()
4 _nm_g_return_if_fail_warning.constprop.14()
5 nm_active_connection_get_settings_connection()
6 active_connection_find()
7 _get_activatable_connections_filter()
8 nm_settings_get_connections_clone()
9 nm_manager_get_activatable_connections()
10 auto_activate_device_cb()
11 g_idle_dispatch()
12 g_main_context_dispatch()
13 g_main_context_iterate.isra.21()
14 g_main_loop_run()
15 main()
Fixes: 33b9fa3a3c ('manager: Keep volatile/external connections while referenced by async_op_lst')
https://bugzilla.redhat.com/show_bug.cgi?id=1933719https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/834
If the configuration contains dns=none and resolv.conf is updated
through a dispatcher script, currently there is no way to tell NM that
the content of resolv.conf changed, so that it can restart a hostname
resolution.
Use SIGUSR1 (and SIGHUP) for that.
wpa-eap-suite-b-192 key-mgmt method uses special values for "pairwise"
and "group" ciphers, we can also handle that a few lines underneath
where those are set to make this a bit easier to read.
We currently set the supplicants PMF config (ieee80211w) inside an if
block that tries to detect whether WPA is used. That if-block doesn't
include the "wpa-eap-suite-b-192" case because we want special
"pairwise" and "group" handling for wpa-eap-suite-b-192. This means
we're currently missing to enable PMF in the "wpa-eap-suite-b-192" case,
even though it's set to REQUIRED.
Fix it by moving the "pairwise" and "group" special-casing down a bit so
we can include "wpa-eap-suite-b-192" in the "Only WPA-specific things
when using WPA" check, that will make sure ieee80211w gets set in the
wpa-eap-suite-b-192 case.
We only set the "ieee80211w" option in the wpa_supplicant config in case
we're using WPA (see the if-block underneath), otherwise the value of
"pmf" is completely ignored. That means the override here (in case WPA
isn't used) isn't getting applied anyway, so just remove it.
It looks a bit weird on the first glance that we do nothing when
NM_SETTING_WIRELESS_SECURITY_PMF_OPTIONAL is used. The reason for this
is that we already intialize the global option "pmf" of wpa_supplicant
to "1" (optional), so add a brief comment about that here.
ResolveAddress is a simple D-Bus API. One might think that it does not
require much logic, and we would just make the D-Bus call directly.
However, we want to ensure that we always sent our latest DNS
configuration to systemd-resolved first, before making any D-Bus request
to resolve a name.
Also, as we D-Bus activate the service and watch the name owner, we
want to handle that. If a user resolves a name while we are still D-Bus
activating, then we need to queue the request.
This adds some complexity in the implementation. But the benefit is that
the API becomes simple from the user's point of view. The queuing and
avoiding race conditions is handled internally.
The implementation does not use standard glib patterns with GAsyncResult
GTask and GCancellable. I find implementing them correctly is more
effort and leads to a less nice API. That might be fine for public API,
which should follow glib style. But this is entirely internal, and
returning a NMDnsSystemdResolvedResolveHandle that allows cancellation
seems more convenient to me.
As we already track the current name owner, it seems wrong to make
requests to the well-known name. It theoretically opens a race
where we would talk to the wrong systemd-resolved instance.
So far, we didn't care and it didn't make much of a difference.
Still, let's talk to the process that we expect.
For infiniband, request_broadcast is automatically (and always) enabled.
Otherwise, we usually don't enable it, and (unlike systemd-networkd),
there is currently no configuration option to enable it.
Still honor the new udev property that can indicate to enable the flag
per device.
See-also: https://github.com/systemd/systemd/pull/ ### 19346
The DHCP client has potentially a large number of options,
including boolean options (flags). It is cumbersome to implement
them one by one. Instead, make more prominent use of NMDhcpClientFlags.
Previously, we used nm_udev_utils_property_as_boolean(), which was
taken from g_udev_device_get_property_as_boolean(). That function
accepts "1" and "true" (with ASCII case insensitive).
When we parse a flag, there is no need to reject "no", "yes" or
"on"/"off" as invalid (and thus return FALSE). We have a boolean
parse method _nm_utils_ascii_str_to_bool(), which parses everything
that nm_udev_utils_property_as_boolean() accepts, and more.
Be liberal in what we accept, so use our general parse function.
g_key_file_set_comment() has slightly weird API that will fail to set a
comment if it doesn't find the group. This is the case here since we
haven't set any strings under the [Security] group yet.
Fixing this is kind of ugly, so for now just don't add that comment in
the case where we don't have the [Security] group.
There are cases where the settings didn't actually change and we just
want to ensure NM and iwd settings are in sync (one such case would be
when a setting was changed while iwd wasn't running, here we want to
synchronize all settings when starting up iwd).
We're already doing this and calling sett_conn_changed() from
mirror_connection() on all connections after adding an interface, the
actual settings synchronization code doesn't get executed though because
we're passing 0 as update_reason, which means we bail out early from
sett_conn_changed().
To make sure we actually update the iwd network configurations in that
case, too, pass UPDATE_REASON_UPDATE_NON_SECRET as the update reason to
sett_conn_changed(), which is the correct update reason in this case.
Quite obviously, we want to update the AutoConnect setting of the iwd
network in case the NM and iwd settings differ, not if they are the
same. So check for unequality here instead of equality, which fixes the
AutoConnect setting's synchronization.
Fixes: 4229c97012 ('iwd: Mirror NM connections to IWD network config files'):
Apparently moving secrets between priv->connection and
priv->system_secrets in the various places throughout
NMSettingsConnection is no longer needed and has no effect on the
state of the D-Bus object or the gobject visible from outside. It
seems that it was needed for the secrets handling in NMDevice
subclasses before the introduction of the applied connection concept
but now nm_connection_need_secrets() is called in those subclasses
directly on the applied connection object and the secrets obtained
from multiple nm_settings_connection_get_secrets calls are also
collected directly in the applied connection's settings.
Drop the system secrets cache mechanism as a cause of a minor memory
overhead, some code overhead and also a source of some unneeded gobject
signals as the connection settings were being updated.
Note: the NM_SETTINGS_CONNECTION_UPDATE_REASON_CLEAR_SYSTEM_SECRETS and
NM_SETTINGS_CONNECTION_UPDATE_REASON_RESET_SYSTEM_SECRETS flags in the
SettingsConnection update signals appear to only have been used by the
SettingsConnection internally to keep priv->system_secrets up to date.
They can have potential other uses in the handlers of those signals so I
kept them. Unlike some of the other NMSettingsConnectionUpdateReason
values these are actual update *reasons* and not flags telling the
settings backends how to handle a specific change in the settings.
All usages of nm_settings_connection_clear_secrets() outside of the
NMSettingsConnection implementation were setting the
clear_cached_system_secrets parameter to FALSE which meant that the
operation was a no-op since the system-secrets cache kept a copy of the
secrets being cleared and any access to the SettingsConnection through
the D-Bus API or the class methods would behave the same as without the
call, with the exception of directly reading the settings from the
result of nm_settings_connection_get_connection(). The calls would
still generate D-Bus and gobject signals however, which were redundant.
Drop the method and its calls from the rest of NM code as not needed and
potentially confusing. The comments preceding these calls implied that
they were needed so that the next activation attempt would be forced to
use nm_settings_connection_get_secrets() but this was the case probably
only before the applied connection concept was introduced.
Also drop two nm_active_connection_clear_secrets() uses in
NMVpnConnection, right before the teardown of the active connection,
that could only possibly have any effect if they affected the
NMSettingsConnection, but as mentioned earlier the
nm_settings_connection_clear_secrets() use inside
nm_active_connection_clear_secrets() didn't do anything and is now
removed.
The one internal use of nm_active_connection_clear_secrets() in the
D-Bus ClearSecrets() implementation is inlined.
This patch is introducing the wired setting accept-all-mac-addresses
property. The value corresponds to the kernel flag IFF_PROMISC.
When accept-all-mac-address is enabled, the interface will accept all
the packets without checking the destination mac address.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Having two functions like link_set_x() and link_set_nox() it is not a
good idea. This patch is introducing nm_platform_link_change_flags().
This allow flag modification directly, so the developer does not need to
define the virtual functions all the time everywhere.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
This patch is introducing NM_DEVICE_INTERFACE_FLAG_PROMISC in
interface_flags. The flag represents IFF_PROMISC kernel flag.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Allow IP prefixes of 0 for routing rules, which are used for specifying a
route for all traffic. (e.g. route all traffic by default with separate
rules to exclude specific IP ranges)
#711
When the link goes away the manager keeps software devices alive as
unrealized because there is still a connection for them.
If the device is software and has a NM-generated connection, keeping
the device alive means that also the generated connection stays
alive. The result is that both stick around forever even if there is
no longer a kernel link.
Add a check to avoid this situation.
https://bugzilla.redhat.com/show_bug.cgi?id=1945282
Fixes: cd0cf9229d ('veth: add support to configure veth interfaces')
We need to handle the case that kernel mangles the configured values. We
already do, but there was a left over nm_platform_lnk_bridge_cmp() that
is still wrong.
Related: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/665
Fixes: ce9211500e ('platform/tests: work around rounding errors for bridge values in unit tests')
This ensures that the argument is some pointer to pointer. This gives a
bit of additional compile time safety, but in general, it still casts
any pointer to pointer (because that's what we require, as most arguments
won't be of type NMDBusObject to begin with).
NM should have been creating the IWD network config files with 0600
permission bits from the beginning since they can contain secrets.
g_key_file_save_to_file() uses 0666 which shouldn't be used even for the
temporary file before setting the final permissions.
Also try to preserve the last modification timestamp of the original
file because it is currently used by IWD when ranking networks for
autoconnect and updating it everytime NM rewrites the file could
potentially affect autoconnect priorities.
Extend nm_utils_file_set_contents to be able to optionally set the last
access + last modification times on the file being created, in addition
to the mode.
There was an attempt in the code to allow using existing system-owned
secrets based on whether the connection had ever succeeded before but
this wasn't implemented properly. Now decide whether existing secrets
are allowed and whether to pass the REQUEST_NEW flag to the secrets
request based on the last connection timestamp and on the network
security type (PSK vs. 802.1X) to align the policy with the policy
inside IWD.
Drop a useless nm_connection_clear_secrets call on the applied
connection just before failing the connection attempt and thus
destroying the applied connection.
Avoid saving agent-owned secrets when converting settings connections
to IWD config files and avoid reacting to NMSettingsConnection updates
that don't seem to touch any non-secret or system-owned-secret settings.
Along with NM_SETTINGS_CONNECTION_UPDATE_REASON_RESET_SYSTEM_SECRETS
and NM_SETTINGS_CONNECTION_UPDATE_REASON_RESET_AGENT_SECRETS, which can
be used in the NMSettingConnection's "updated" handlers to track secrets
updates, add NM_SETTINGS_CONNECTION_UPDATE_REASON_UPDATE_NON_SECRET so
that the handlers can tell when something other than secrets has been
updated in the connection.
It can also potentially be used in _connection_changed_update in
src/core/settings/nm-settings.c to stop emitting the
NetworkManager.Settings.Connection.Updated() dbus signal if only secrets
are being updated (on agent queries etc.) if it is deemed to be correct.
