When generating a connection, if the device has no non-link-local IPv6
address, then it's unclear whether (a) the connection was link-local
originally, or (b) the connection was 'auto' but IPv6 failed or timed
out.
In this case, if there is a persistent connection that is 'auto' but
the generated connection is 'link-local', the persistent connection
should be used.
Add a more-testable framework for doing the connection matching to
handle this.
INFERRABLE means the opposite of CANDIDATE; a property which NetworkManager
can read ("infer") from the system or the kernel when generating
connections. CANDIDATE isn't a great name and thus dies.
We can only create virtual interfaces when the connection has autoconnect
property *and* the device was not manually disconnected before.
Without this commit NetworkManager would auto-activate all virtual connections
when a change was done (e.g. new virtual connection was addded).
Else loopback is managed, and could be easily disconnected, which causes various
issues with applications. So do not manage it for now, to be on the safer side.
https://bugzilla.redhat.com/show_bug.cgi?id=1032594
Previously, the default wired connection was removed on quit when the
device was cleaned up. This is inconsistent with other connections.
Leave the default wired connection up when quitting to fix this
inconsistency.
This allows default wired connections to be assumed when NM starts.
The change to allow an NMConnection to only be active on a single
device accidentally broke the case of re-activating a connection on
the same device. Fix that.
These are (most likely) only warnings and not severe bugs.
Some of these changes are mostly made to get a clean run of
Coverity without any warnings.
Error found by running Coverity scan
https://bugzilla.redhat.com/show_bug.cgi?id=1025894
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
If an assumed bridge/bond/team/whatever happened to be in the process
of activating (perhaps it had no recognized slaves and was waiting for
them to continue with IP configuration) when NM quits, don't deactivate
the device and blow away the assumed configuration.
Don't set NMManager:state to CONNECTING when assuming a connection,
since it's not actually "connecting".
If there are active connections, but none has the default route, then
the global state should be CONNECTED_LOCAL, not CONNECTED_GLOBAL.
Also tweak the semantics of CONNECTING/DISCONNECTING slightly; we only
set state to CONNECTING when connecting a new connection if we are not
already CONNECTED_GLOBAL, and we only set it to DISCONNECTING if we
will be DISCONNECTED afterward.
If an assumed connection should have a master (bridge port, bond slave,
etc) it needs to notify its master that it's a slave. Since slaves
are ordered after their masters at start, the master should already
have a generated connection which we can use as the master.
Various code during the activation paths will want to know whether
the connection is assumed or not, so that it doesn't do stuff that
touches the device.
If the device has a valid generated connection, it's already applied
and the device is already "activated" outside NM, so let activation
happen inside NM regardless of whether the device is available or not
according to NM.
In the case of autoconnect VLANs or IB partitions, if the parent interface
hasn't been detected yet at startup, then the get_virtual_interface_name()
won't be able to find the parent yet. That's normal, and when the parent
is found, system_create_virtual_device() will be run again and the parent
will be found, and the autoconnect VLAN/IB partition will be created.
But we shouldn't warn that the parent can't be found when that might be
a normal occurance.
Only NMSettingsConnections can be activated on device, and
get_connection() wasn't doing that. So the generated connection
must be added to NMSettings. That also triggers the
ConnectionProvider's 'connection-added' signal with the happy
result of adding the new connection to the device's
AvailableConnections list.
Acked-by: Dan Williams <dcbw@redhat.com>
Previously, ignore-carrier devices were always in the unavailable state
until they were activated. This required some complicated code to keep
track of whether the device was available or not based on what connections
existed, whether those connections were static-IP, and whether the device
was ignore-carrier. Various bits of the code used nm_device_can_activate()
for two different purposes: (1) to determine if the device was available
on an L2 basis, which nm_device_can_activate() wasn't well-suited to, and
(2) whether a specific connection could be activated at a given time
based on ignore-carrier and whether the connection was static IP or not.
Remove that complexity and confusion by making ignore-carrier devices
always move to DISCONNECTED state, and simply refuse to activate
connections that require connectivity, but allow connections that don't
require connectivity. Also, when the device has no carrier, don't
add connections that require connectivity to the AvailableConnections
device property.
When settings are NULL or empty in impl_manager_add_and_activate_connection(),
the connection is created and completed by nm_utils_complete_generic() or
nm_device_complete_connection().
Also, do not assert in nm_connection_is_type(). Returning FALSE there is
sufficient.
Related commit a878cd8145
When called with a connection path, activates that connection.
When called without a connection path, picks the best available
connection to activate for that device.
Doesn't work with VPN connections because they don't have devices.
Besides killing PendingActivation, this patch decouples ActiveConnection
creation from actually activating that connection. This allows the
ActiveConnection to complete authorization asynchronously. This will
also be used in the future for handling the DEACTIVATING state of devices
(for "pre-down" functionality).
We need to track the master active connection, since it may require authentication
or other operations to complete before the device actually starts activating.
We want to create the object earlier now, and figuring out the master is
a lot of code that we don't want to run before creating the object. The
master still must be set before exporting the object over D-Bus though,
as before.
Eventually the manager will create both NMActRequest and
NMVPNConnection subclasses directly, instead of leaving
NMVPNConnection creation to the VPN manager.
This also ensures that VPN connections get their user_requested
attribute set correctly, which wasn't happening before in the
case of secondary VPN connections.
When we eventually do authorization in the ActiveConnection itself,
we want to make sure the AC doesn't get exported until everything
is authorized. Thus let the manager handle exporting the objects
since it knows when the AC will be authorized or not.
Do less authentication in the PA and make the DBusGMethodInvocation
opaque to the PA. This pushes the responsibility for replying to
the D-Bus method call closer to the D-Bus method handler instead
of stuffing it all into the PA. This does mean we need to get
the D-Bus sender name and the sender UID and pass that into the
pending_activation_new(), but we'll clean that up in a bit.
Move the connection completion code out of the PendingActivation
object and into the D-Bus method handler for AddAndActivate. This is
part of simplifying PendingActivation so we can fold its functionality
into NMActiveConnection and use the AC objects to track all activation
requests from start to finish.
This also requires a bit of reorganization since the PA used to handle
some of the request validation but that now needs to be handled by
each DBus method itself.
Previously the PA tracked the connection path, but that's really
quite unecessary, we might as well just track the actual connection
object itself. This allows us to only validate the path once, instead
of three times like the code did before. This does require a boolean
"add_and_activate" variable though, because the PA handles the DBus
method return and it needs to know whether the request came from
ActivateConnection or AddAndActivateConnection, which was previously
handled by checking pending->connection, which only AddAndActivate set.
When an interface is manually disconnected NM remembers that, and prevents
automatic activation of the device.
However, software devices are removed when they are disconnected, and thus
the state of the device is lost. We need to track autoconnect outside the
device - hash table of interface names not allowed to activate automatically.
Without that the device would be auto-activated again and again, even if
explicitly disconnected.
Test case:
$ nmcli con add type bond ifname bb con-name bb-con
$ nmcli con add type bond-slave ifname em1 con-name b1-con master bb
$ nmcli dev disconnect bb
https://bugzilla.redhat.com/show_bug.cgi?id=1005913
When freeing one of the collections such as GArray, GPtrArray, GSList,
etc. it is common that the items inside the connections must be
freed/unrefed too.
The previous code often iterated over the collection first with
e.g. g_ptr_array_foreach and passing e.g. g_free as GFunc argument.
For one, this has the problem, that g_free has a different signature
GDestroyNotify then the expected GFunc. Moreover, this can be
simplified either by setting a clear function
(g_ptr_array_set_clear_func) or by passing the destroy function to the
free function (g_slist_free_full).
Signed-off-by: Thomas Haller <thaller@redhat.com>
NMBluezManager is now a proxy and only delegates to either
NMBluez4Manager or NMBluez5Manager. It detects the running BlueZ
version at runtime, and once it decides for one version, it cannot be
changed anymore as long NetworkManager is running.
This means, when switching from BlueZ4 to BlueZ5 or vice versa you have
to restart NetworkManager. This should be acceptable, because it is
not a common use case (most systems won't have both versions installed
anyway) and it greatly simplifies implementation.
Also note that NMBluez4Manager and NMBluez5Manager do not implement a
common interface. NMBluezManager delegates to the correct manager.
Having them share an common interface or base class would not simplify
the code, because NMBluezManager not only delegates, but it also acts as
a proxy until it is decided which BlueZ version is running. So, this
proxy-like behaviour would still be needed. The alternative would be to
merge the functionality of all three NMBluez*Manager classes into one.
This also removes the --enable-bluez4 configure switch, because both
versions are now always enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=709412
Signed-off-by: Thomas Haller <thaller@redhat.com>
If the WiMAX plugin isn't installed, or the WiMAX device isn't
recognized, NetworkManager shouldn't treat the interface as
regular ethernet since the device requires specific setup to
be ready for IP configuration, which of course NetworkManager
can't do because the WiMAX plugin isn't loaded. Ignore them
instead.
