If the kernel doesn't tag a modem's ethernet interface with
DEVTYPE=wwan then NetworkManager has no idea that's a modem
(and cannot be used until connected via the control port).
Since DEVTYPE=wwan devices get ignored by NM, so should these
interfaces when NM knows they are modems.
That got broken at some point for ModemManager1, because the
data port isn't read until the modem is connected. NM only
looked for and removed the data-port-as-ethernet-device when
the modem was added, long before the MM1 data port was found.
ModemManager does provide a list of ports owned by the modem
though, which we can use at modem addition time to remove
an ethernet device that is controled by the modem.
find_master() does not (always) set the output parameters. Initialize
paramter to NULL before calling find_master().
Just introduced recently with commit 8123cd2410.
Signed-off-by: Thomas Haller <thaller@redhat.com>
If a master and at least one of its slaves were both autoconnect,
NMManager would end up creating two NMActiveConnections for the master
(one when the master itself is activated, and a second when the slave
is activated and calls ensure_master_active_connection(). (This
probably got broken when we changed it so ACs were created before
their devices.)
Fix this by checking for an existing master AC before creating one.
Fix a crash caused by "merge: remove at_console..." when a scan request
comes in via the D-Bus interface. This usage of the device "auth-request"
signal was missed the first time around.
If a master activation failed early (eg, because the virtual device
could not be created), then the slaves were not being notified of the
failure. Fix that.
Virtual devices may be created and destroyed, but we need to keep
their autoconnect state across that. Previously this was handled by
NMManager, but it really belongs with the other autoconnect tracking
in NMPolicy and NMSettingsConnection.
This also fixes a bug where NMPolicy would sometimes decide to
autoactivate a virtual device connection which NMManager would then
have to cancel.
When a device is disconnected by the user (as opposed to due to
network or hardware error, etc), set it first to DEACTIVATING, which
does nothing but queue a transition to disconnected. This lets other
parts of NM observe the device when it is about-to-disconnect, but
still has an associated connection.
Similar to "core: respect connection user permissions for activation/deactivation",
if a master connection is being activated because a slave connection requested
it, ensure that the user requesting the master connection is allowed to
activate it.
This appears to be a bug since the original 0.9.0 release when
connection permissions were implemented.
If all the following are true:
- the user is local (as determined by systemd or ConsoleKit)
- the user has been given the NETWORK_CONTROL PolicyKit permission
- the user is not listed in the connection's permissions
- the user knows the D-Bus object path of a connection which they
have no permissions for
then that user may activate/deactivate connections that are not
visible to that user as determined by the connection permissions.
Fix that by ensuring that these operations check whether the user
has permission.
These operations are *not* affected, and have always checked user
permissions before allowing the operation:
- modifying any connection details
- requesting any secrets or passwords for the connection
- deleting the connection
nm_logging_level_to_string() returned a const string, but
nm_logging_domains_to_string() returned a malloced one, which was
getting leaked in impl_manager_get_logging(). Fix this by making them
both malloced, and freeing as needed.
If the command line or NetworkManager.conf mentions a non-existent
domain, just print a warning and ignore it. That way if you switch to
using an older NM that doesn't have that domain, it will still work.
NM bounces devices on suspend/resume, since some buggy drivers require
it. However, there's no need to take down virtual devices. (In
particular, we don't want to take down libvirt's virbr0, since it
won't get automatically brought back up afterward.)
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.
