We need a distinction between external activations and assuming
connections. The former shall have the meaning of devices that are
*not* managed by NetworkManager, the latter are configurations that
are gracefully taken over after restart (but fully managed).
Express that in the activation-type of the active connection.
Also, no longer use the settings NM_SETTINGS_CONNECTION_FLAGS_VOLATILE
flag to determine whether an assumed connection is "external". These
concepts are entirely orthogonal (although in pratice, external
activations are in-memory and flagged as volatile, but the inverse
is not necessarily true).
Also change match_connection_filter() to consider all connections.
Later, we only call nm_utils_match_connection() for the connection
we want to assume -- which will be a regular settings connection,
not a generated one.
nm_device_uses_assumed_connection() basically called
nm_active_connection_get_assumed() on the device.
Rename those functions to be closer to the activation-type
flags.
The concepts of "assume", "external", and "assume_or_external"
will make sense with the following commits.
The concept of assumed-connection will change. Currently we mark
connections that are generated and assumed as "nm-generated-assumed".
That has several consequences, one of them being that such a settings
connection gets deleted when the device disconnects.
That is, such a settings connection lingers around as long as it's active,
but once it deactivates it gets automatically deleted. As such, it's
a more volatile concept of an in-memory connection.
The concept of such automatically cleaned up connections is useful beyond
generated-assumed. See the related bug rh#1401515.
Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based
on the settings connection. That is not optimal, because whether
a connection is assumed or externally managed, should be really a
property of the active-connection. So, in the this will change soon
and we would need yet another argument to nm_dispatcher_call().
Instead, drop the settings-connection and applied-connection
arguments and fetch them from the device as needed (but allow
to pass a specific act-request argument to explicitly state
which active connection to use).
Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(),
it this is not a generic dispatcher call, but it is particularly
related to device events. Likewise, rename nm_dispatcher_call_sync()
to nm_dispatcher_call_device_sync().
Remove the redundant action argument. It is clear, that
nm_dispatcher_call_connectivity() is called with action
NM_DISPATCHER_ACTION_CONNECTIVITY_CHANGE.
On the other hand, add the async callbacks. Altough they are
not used at the moment, it seems more correct that an async
API has a callback and a call-id to cancel the invocation.
If the connection candidate contains a static route
without route-metric, but overrides the default
route-metric, matching would have failed:
ipv4.route-metric: 200
ipv4.routes: { ip = 192.168.5.0/32 }
Then, we must not compare existing routes using the device's
metric, but must use the overwrite from the connection.
When hostname changes, resolv.conf should be rewritten to update the
"search" option with the new domain parameters. If no device is
active nor going to activate, skip triggering resolv.conf update.
We use output redirection in numerous places; leaving the half-built
artifacts in place would cause the subsequent builds to succeed when it
should not.
The default route manager logs for each entry relevant information,
in a compact but cryptic way:
default-route: entry[0/dev:0x5633d5528560:enp0s25:1:+sync]: record:add 0.0.0.0/0 via 192.168.0.1 dev 2 metric 100 mss 0 rt-src user (100)
The flag whether a route is configured or not, was only expressed
via 0|1. Change that to log instead:
default-route: entry[0/dev:0x5633d5528560:enp0s25:+has:+sync]: record:add 0.0.0.0/0 via 192.168.0.1 dev 2 metric 100 mss 0 rt-src user (100)
Whenever we call update for a non-assumed, synced route, we must
force a resync with the platform. Even if according to our internal
book-keeping the route is already configured, the route may have
been removed externally. So we cannot assume that everything is
still up-to-date.
https://bugzilla.redhat.com/show_bug.cgi?id=1431268
Scenario:
Have a connection with DHCPv4 and a default-route. When externally
removing the default route (`ip route delete 0.0.0.0/0`) and issuing
`nmcli device reapply $IF`, the default route was not restored.
That was because when externally removing the default route,
we would remove the gateway from priv->con_ip4_config (see
update_ip4_config()). Later, when reapplying the connection,
the IP method doesn't actually change. So we would not restart
DHCP and thus there is no gateway around to add the default route.
The default route would only be restored after receiving a DHCP lease
in the far future.
Fix that, by always restarting the IP method.
Based on this flag, we decide that:
- if we are not gonna commit the first time and the
connection is configured with never-default, we
would not remove a default route added externally.
During a reapply, we however want to get rid of an externally
configured default route.
Commit 4a6fd0e83e ("device: honor the connection.autoconnect-retries
for 802.1X") added a reset of the autoconnect retries when the device
changes state, because the retry logic for 802.1x is implemented in
NMDeviceEthernet. For other connections, we should not reset the
retries as NMPolicy handles them.
Fixes: 4a6fd0e83e
Instead of throwing an assertion, fail DHCPv6 when a IPv6 link-local
address is not configured on the device. There are different reasons
why the assertion may fail: for example the address was removed
externally; or the device is gone (and thus the platform already
received the notification of addresses removal) but the device is still
connecting because its disposal happens in an idle callback.
None of these deserves an assertion, which should only be for
programming errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1432251
The devices_inited_cb() callback is really supposed to only run
when there is nothing else left in the mainloop to dispatch.
But as we already schedule the idle action with G_PRIORITY_LOW+10
priority, it is very unlikely that there is anything else ready
to run (unless scheduled with an even lower priority, and then it
wouldn't help either because devices_inited_cb() would win again).
This doesn't really matter, because NMSetting's startup-complete never
switches back to FALSE once reached. Still, cleanup our signal handlers
when no longer needed.
And disconnect the signals before emitting "notify::startup".
Possibly pending messages from the netlink socket were not processed
since the platform instance was created earlier. As nm_manager_start()
may take a long time to run, make sure that there are no pending
messages before querying the devices.
Udev may be slow at startup and it may take a while until the
device is visible in udev. Before that, there are no pending
actions yet because the device is still in unmanaged state.
Hack nm_device_has_pending_action() to indicate a pending action
when the platform link is not yet initialized.
We don't bother using nm_device_add_pending_action() to schedule
a proper pending-action. It is simpler this way, also we precisely
log about the state of NM_UNMANAGED_PLATFORM_INIT flag. The pending
actions are implemented in their way mostly for logging purpose to
understand what blocks a device. For NM_UNMANAGED_PLATFORM_INIT we
have sufficient logging so no need for the overhead and effort.
https://bugzilla.gnome.org/show_bug.cgi?id=779920
We should implement all our private-getters with the very same pattern
(i.e. their type structure contains a field "_priv" and nm_assert()
with a GObject type check).
NM_LINUX_PLATFORM_GET_PRIVATE() was already doing all of that. Now just
use the _NM_GET_PRIVATE_VOID() macro which formally follows the
intended pattern.
_NM_GET_PRIVATE() macro is used to implement a standard private-getter, but it
requires that "self" is a pointer of either "const type *" or "type *". That
is great in most cases, but sometimes we have predominatly self pointers of
different type, so it would require a lot of casts.
Add a different form _NM_GET_PRIVATE_VOID() where self pointer can be any
non-const pointer and returns a non-const private pointer after casting.
