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)
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.
On m68k architecture, the struct
typedef struct {
gint64 timestamp_ms;
bool dirty;
} IP6RoutesTemporaryNotAvailableData;
ends up being of a previously unhandled size. Causing a compile time
assertion to fail.
Support argument sizes of 10 bytes for nm_g_slice_free_fcn().
(cherry picked from commit f468602d50)
On m68k architecture, the struct
typedef struct {
gint64 timestamp_ms;
bool dirty;
} IP6RoutesTemporaryNotAvailableData;
ends up being of a previously unhandled size. Causing a compile time
assertion to fail.
Support argument sizes of 10 bytes for nm_g_slice_free_fcn().
It's useless and redundant noise.
The original motivation seems to have been compatibility with ancient
versions uClibc (2011), but given CLOCK_BOOTTIME definition is shipped with
kernel headers, the libc version shall not matter anyway.
Even if it was the case, uClibc has shipped the definition for over
7 years now and been superseded by uClibc-ng that always had the
definition.
