priv->system_secrets may be updated by e.g.
nm_settings_connection_new_secrets and nm_settings_connection_update,
but if the plugin creates the object with g_object_new, then adds some
settings but never adds any secrets there's no reason to call either of
those two methods. A call to nm_settings_connection_get_secrets should
still be able to request new secrets (and may then update
priv->system_secrets as a result).
(cherry picked from commit f11246154e)
If the hints parameter to the agent request wasn't empty, ask
specifically for the 802-1x keys listed in the hints and skip the
guessing. I didn't add human readable names for all of the 802-1x
settings, it could be useful to do for at least the three 802-1x
properties that add_8021x_secrets already knows about because
those may have translations.
(cherry picked from commit 1a6e53808d)
Allow the IWD backend to use secrets provided in the connection settings
on initial connection attempt, only require new secrets on subsequent
connections when IWD asks for them -- it only asks if fresh secrets are
required.
(cherry picked from commit 24f5cf23e5)
The IWD DBus interface currently
(https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/doc/agent-api.txt?id=38952813dddd776f66d2ed5e88eca9a892964c06)
knows about 3 secret types related to 802.1x authentication in addition
to the PSK secret request. Add support for the new methods and the new
secret types in NM's implementation of the IWD secret agent. Note that
the secret types are mapped to NMSetting8021x property keys and they are
then sent to the NM Secret Agent in the hints parameter to GetSecrets,
this will need support in the NM clients as the exact usage of the
hints parameter is specified a little ambiguously, but this seems to be
one of the permitted usages.
Rework the IWD agent interface info initialization to use NM convenience
macros.
(cherry picked from commit 74d9e04a66)
To improve the code logic and reduce space for bugs, don't save the
dbus invocation object as priv->secrets_request, instead move it to
the nm_act_request_get_secrets()'s user_data as we only need the
invocation object for exactly the life time of the request. See
https://github.com/NetworkManager/NetworkManager/pull/139 for
discussion.
(cherry picked from commit ffd96edf76)
Blank mode property in the wireless settings is documented in
libnm-core/nm-setting-wireless.c to mean infrastructure mode.
(cherry picked from commit d01ba607a6)
Internally, the device migth have negative or zero ifindex.
When calling nm_manager_get_device_by_ifindex(), the caller
wants to find a device with a valid ifindex, hence filter
out non-positive values.
<error> level is for something really bad happening. When another party
(iwd in this case) sends a D-Bus request that we cannot meaningfully handle,
that is hardly reason to warn about. <debug> level is enough in this case.
Also, give all messages a common prefix "agent-request" so that we have
something to grep for.
nm_utils_random_bytes() will always try its best to give some
random numbers. A failure only means, that the kernel interfaces
get_random() or /dev/urandom failed to provide good randomness. We
don't really need good random numbers here, so no need to handle
a failure.
priv->system_secrets may be updated by e.g.
nm_settings_connection_new_secrets and nm_settings_connection_update,
but if the plugin creates the object with g_object_new, then adds some
settings but never adds any secrets there's no reason to call either of
those two methods. A call to nm_settings_connection_get_secrets should
still be able to request new secrets (and may then update
priv->system_secrets as a result).
If the hints parameter to the agent request wasn't empty, ask
specifically for the 802-1x keys listed in the hints and skip the
guessing. I didn't add human readable names for all of the 802-1x
settings, it could be useful to do for at least the three 802-1x
properties that add_8021x_secrets already knows about because
those may have translations.
Allow the IWD backend to use secrets provided in the connection settings
on initial connection attempt, only require new secrets on subsequent
connections when IWD asks for them -- it only asks if fresh secrets are
required.
The IWD DBus interface currently
(https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/doc/agent-api.txt?id=38952813dddd776f66d2ed5e88eca9a892964c06)
knows about 3 secret types related to 802.1x authentication in addition
to the PSK secret request. Add support for the new methods and the new
secret types in NM's implementation of the IWD secret agent. Note that
the secret types are mapped to NMSetting8021x property keys and they are
then sent to the NM Secret Agent in the hints parameter to GetSecrets,
this will need support in the NM clients as the exact usage of the
hints parameter is specified a little ambiguously, but this seems to be
one of the permitted usages.
Rework the IWD agent interface info initialization to use NM convenience
macros.
To improve the code logic and reduce space for bugs, don't save the
dbus invocation object as priv->secrets_request, instead move it to
the nm_act_request_get_secrets()'s user_data as we only need the
invocation object for exactly the life time of the request. See
https://github.com/NetworkManager/NetworkManager/pull/139 for
discussion.
- in wake_on_wlan_restore(), if we decide that there is something
to restore, also clear priv->wowlan_restore by setting it to
IGNORE. That way, we are sure to only try resetting the value
once after setting it.
- from nm_platform_wifi_get_wake_on_wlan(), return IGNORE if
the value cannot be read. If we could not read the value
we should not restore NONE, but don't restore.
If commit_mtu() is called multiple times and dev->get_configured_mtu()
returns @is_user_config=FALSE, only the first call changes the
MTU. So, for example, when the parent MTU of a VLAN changes, we apply
the new MTU only the first time.
Rework the handling of MTU in NMDevice, and store the source of the
configured MTU. When commit_mtu() is called again, we ask the subclass
a MTU to configure and apply it only if the source has higher
priority, or when the parent MTU changed.
Instead of returning a boolean @is_user_config value from
get_configured_mtu(), return an mtu-source enum with possible values
NONE,CONNECTION. This enum will be expanded later; for now there is no
change in behavior.
If a device-factory wouldn't support any link-type or setting-type,
we would not take an additional reference to the @factory instance
(because, the factory is not added to one of the static hash tables).
As such, we would invoke the callback with a factory instance, which
is about to be destroyed immediately afterwards. That would be unusual
for device-plugins, because usually a device-plugin is never destroyed
and essentially leaked at exit.
Just don't get into that situation. All device plugins are internal API,
and they are known to support at least something. Assert for that.
(cherry picked from commit 94200b03fe)
Actually, we anyway leak them, because they are added to static hash tables
which are never released. Anyway, get the ref-count right.
(cherry picked from commit 4c43d7cad3)
Internal device plugins are compiled-in. In fact, none of the
internal device plugins can currently be disabled via compile
time options. The user would have to patch the sources to
not include a particular device plugin.
Hence, the available device plugins depends exclusively on the
build itself. That is not worth <info> level logging. Especially,
as it was quite verbose, logging 13 lines.
(cherry picked from commit dff157b867)
If a device-factory wouldn't support any link-type or setting-type,
we would not take an additional reference to the @factory instance
(because, the factory is not added to one of the static hash tables).
As such, we would invoke the callback with a factory instance, which
is about to be destroyed immediately afterwards. That would be unusual
for device-plugins, because usually a device-plugin is never destroyed
and essentially leaked at exit.
Just don't get into that situation. All device plugins are internal API,
and they are known to support at least something. Assert for that.
Internal device plugins are compiled-in. In fact, none of the
internal device plugins can currently be disabled via compile
time options. The user would have to patch the sources to
not include a particular device plugin.
Hence, the available device plugins depends exclusively on the
build itself. That is not worth <info> level logging. Especially,
as it was quite verbose, logging 13 lines.
Otherwise, we easily get a failure
test:ERROR:src/platform/tests/test-cleanup.c:78:test_cleanup_internal: assertion failed (addresses6->len == 2): (1 == 2)
Avoid that by waiting for kernel to add the link-local
address.
(cherry picked from commit fb63d8d706)
Otherwise, we easily get a failure
test:ERROR:src/platform/tests/test-cleanup.c:78:test_cleanup_internal: assertion failed (addresses6->len == 2): (1 == 2)
Avoid that by waiting for kernel to add the link-local
address.
Option to check just in NM private dhcp client specific lease files has
been dropped: either get DUID from specific DHCP plugin or just use the
provided one.
This reverts commit f054c3fcaa.
(cherry picked from commit 08116409f3)
