In device_ipx_changed() we only keep track of dad6_failed_addrs
addresses if the device's state is > DISCONNECTED.
For the same reason, we should also do that in queued_ip_config_change().
But it's worse. If the device is in state disconnected, and the user
externally adds IPv6 addresses, we will end up in queued_ip_config_change().
It is easily possible that "need_ipv6ll" ends up being TRUE, which results
in a call to check_and_add_ipv6ll_addr() and later possibly
ip_config_merge_and_apply (self, AF_INET6, TRUE);
This in turn will modify the IP configuration on the device, although
the device may be externally managed and NetworkManager shouldn't touch it.
https://bugzilla.redhat.com/show_bug.cgi?id=1593210
We first iterate over addresses that might have failed IPv6 DAD and
update the state in NMNDisc.
However, while we do that, don't yet invoke the changed signal.
Otherwise, we will invoke it multiple times (in case multiple addresses
failed). Instead, keep track of whether something changed, and handle
it once a bit later.
Whenever we process queued IP changes, we must handle all pending
dad6_failed_addrs. This is, to ensure we don't accumulate more
and more addresses in the list.
Rework the code, by stealing the entire list once at the beginning
dad6_failed_addrs = g_steal_pointer (&priv->dad6_failed_addrs);
and free it at the end:
g_slist_free_full (dad6_failed_addrs, (GDestroyNotify) nmp_object_unref);
This makes it easier to see, that we always process all addresses in
priv->dad6_failed_addrs.
There is no change in behavior, however don't handle dad6_failed_addrs
and dad6_ip6_config in the same block.
While both parts are related to IPv6 DAD, they do something rather
different:
- the first block, checks all candidates from dad6_failed_addrs whether
they actually indicate DAD failed, and handles them by notifying
NMNDisc about failed addresses.
- the second block, checks whether we have now all addresses from
dad6_ip6_config that we are waiting for.
Split the blocks.
We don't need to cancel the current idle-action and schedule a new
one. Just return and wait to be called again.
Also, drop the logging. Similarly, we don't log the postponing for
the previous case either.
We also cancel the idle handler
nm_clear_g_source (&priv->queued_ip_config_id_x[IS_IPv4])
which means, nobody is going to process these addresses (at least
for the moment).
The purpose of "dad6_failed_addrs" is to keep track of addresses that
might be interesting for checking about DAD failures. If we are no
longer reacting on IP changes (because the idle handler was removed),
we also no longer need these addresses.
This simplifies commit 31ca7962f8.
We don't need the boolean flags like "queued_ip4_config_pending" to
track whether we received any platform signals while being not yet
initialized in platform (udev, NM_UNMANAGED_PLATFORM_INIT).
In general, as long as the device is NM_UNMANAGED_PLATFORM_INIT,
all platform signals are ignored. And when the device becomes managed,
we schedule anyway an initial config-change.
"debug" was documentation in `man NetworkManager.conf` as a valid
logging backend. However, it was completely ignored by
nm_logging_syslog_openlog().
In fact, it makes not sense. Passing debug = TRUE to
nm_logging_syslog_openlog(), means that all messages will be
printed to stderr in addition to syslog/journal. However, when
NetworkManager is daemonizing, stderr is closed.
Whether NetworkManager is daemonizing depends entirely on command
line options --no-daemon and --debug. Hence, the logging backend "debug"
from the configuration file either conflicts or is redundant.
Also, adjust logging backend description in `man NetworkManager.conf`.
Also, log a warning about invalid/unsupported logging backend.
'num_grat_arp' and 'num_unsol_na' are actually the same attribute on
kernel side, so if only 'num_grat_arp' is set in configuration, we
first write its value and then overwrite it with the 'num_unsol_na'
default value (1). Instead, just write one of the two option.
https://bugzilla.redhat.com/show_bug.cgi?id=1591734
<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.
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.
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.
_LOGD() is preferred, because it includes a common prefix depending
on the device. This macro requires, that we have a suitable @self
variable in the local scope.
Rather trivial change. Return-early, to completely handle the simpler
case (the success case) first. In the failure case, we only need
extra effort to generate a nice error message.
It is safer to enable send-sci by default because, at the cost of
8-byte overhead, it makes MACsec work over bridges (note that kernel
also enables it by default). While at it, also make the option
configurable.
https://bugzilla.redhat.com/show_bug.cgi?id=1588041
We set the metric to the routes as we receive them from the PPP plugin. We
ought to let the modem know before it starts IPv4 configuration, not right
before the commit.
https://bugzilla.redhat.com/show_bug.cgi?id=1585611
