For nl80211, we don't care about the interface name and only use it
when formatting error messages. For wext, an up-to-date interface name
should be obtained every time to minimize the chance of race
conditions when the interface is renamed.
state_changed_proxy() updates the value of @state and must also emit
the notify signal for it.
Without this, when the PropertiesChanged signal carrying the change of
'state' arrives after StateChanged, we notice that the value of @state
doesn't change and don't emit the notify, causing a loss of the state
change event.
Fixes: 40ffb962behttps://bugzilla.redhat.com/show_bug.cgi?id=1433883
When remove_device() is called on an already unrealized device, we
should release it from master if necessary and clear its IP
configurations to avoid leaks.
https://bugzilla.redhat.com/show_bug.cgi?id=1433303
NMVpnConnectionStateReason is no longer used and replaced by
NMActiveConnectionStateReason. However, the old enums should
stay in place as they were:
Otherwise:
#define NMVpnConnectionStateReason NMActiveConnectionStateReason
causes compiler warnings:
NMVpnConnectionStateReason x;
x = NM_VPN_CONNECTION_STATE_REASON_UNKNOWN; // -Wenum-conversion
if (x == NM_VPN_CONNECTION_STATE_REASON_NO_SECRETS) { } // -Wenum-compare
Similarly, a user who didn't upgrade shall continue to get the
old GType for NM_TYPE_VPN_CONNECTION_STATE_REASON.
In practice, old users will have no issues using the old enum
the places where it worked before.
The only use of the deprecated enum is in vpn_state_changed()
signal slot of NMVpnConnection. This makes the signal slot
itself deprecated. However, NMVpnConnection is an NMObject and commonly
created within libnm itself, not by the user. It is very unlikely that
a user of libnm subclassed NMVpnConnection and makes use of the
vpn_state_changed() signal slot. So, deprecate it without replacement.
Fixes: a91369f80d
It's utterly useless: the textual version of the reason if logged only if
the plugin fails; but the plugin failure already logs the plugin state
change reason which is directly translated to the connection one.
Track both device and active connections at the same time and decide
whether activation finished (either successfully or not) in a single
place, check_activated().
This makes the already too complex code path a bit more straightforward
and also makes it possible to be more reasonable about the diagnostics.
Now that the active connection signals the reason, we include it; but if
the failure is due to the device disconnection while we're activating,
include a device reason instead, since it's often more useful. Like:
Before:
Error: Connection activation failed.
Without considering the device:
Error: Connection activation failed: the base network connection was interrupted
After:
Error: Connection activation failed: The Wi-Fi network could not be found
Note that the reason tracking starts as soon as the object exists (which
is immediately after GDBusObject is created), not when the asynchronous
NMObject initialization finishes. That is so that we the reason changes
in between are not lost.
The vpn-connection should probably be doing the same.
It includes a reason code that makes it possible for the clients to be
more reasonable about error messages.
The reason code is essentially copied from the VPN, plus three more
reasons that were useful for non-VPN connections.
When deciding whether to touch a device we sometimes look at whether
the active connection is external/assumed. In many cases however,
there is no active connection around (e.g. while moving the device
from state unmanaged to disconnected before assuming).
So in most cases we instead look at the device-state-reason to decide
whether to touch the interface (see nm_device_state_reason_check()).
Often it's desirable to have no state and passing data as function
arguments. However, the state reason has to be passed along several hops
(e.g. a queued state change). Or a change to a master/slave can affect
the slave/master, where we pass on the state reason. Or an intermediate
event might invalidate a previous state reason. Passing the state
whether to touch a device or not as a state-reason is cumbersome
and limited.
Instead, the device should be aware of whats going on. Add a
sys-iface-state with:
- SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it
- SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over
- SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM
- SYS_IFACE_STATE_REMOVED: the device no longer exists
This replaces most checks of nm_device_state_reason_check() and
nm_active_connection_get_activation_type() by instead looking at
the sys-iface-state of the device.
This patch probably has still issues, but the previous behavior was
not very clear either. We will need to identify those issues in future
tests and tweak the behavior. At least, now there is one flag that
describes how to behave.
Now we only search for a candiate with matching UUID. No need to
first lookup all activatable connections, just find the candidate
by UUID and see if it is activatable.
- rename find_ac_for_connection() to
active_connection_find_first_by_connection().
This function has the unexpected(?) behavior to either
search by the @connection using pointer identity, or
by looking up the UUID (depending on whether @connection
is a NMSettingsConnection).
- Split out a active_connection_find_first() part.
The name "find-first" makes it clear that we walk the list until
a matching active-connection is found. That's why I added the
max_state argument. Otherwise, it would have to be called
"find-first-non-disconnected".
- drop nm_manager_get_connection_device(). It only had two callers.
It also used the ambiguity of the @connection argument, but
only one of the two callers cared about that. Meaning,
_internal_activate_device() now explicitly does a lookup by
the NMSettingsConnection.
There is only one caller of assume_connection().
The tasks there are not clearly separate and it is clearer just to
have one large recheck_assume_connection() function which proceeds
step by step, instead of breaking it into separate parts and move
them apart in the source code. The latter implies that -- unless
we forward-declare assume_connection() -- the order of definition
with assume_connection,recheck_assume_connection is contrary the
flow of the code.
Having a separate function in this case is not a simplification
so merge it.
An EXTERNAL activation type comes with a nm-generated, volatile,
in-memory connection. When the user actively modifies that connection, we
shall mark the active connection as fully managed.