Rather than having a bunch of udev-based tests, use
nm_platform_link_get_type() to categorize devices.
Incomplete, as NMPlatform still categorizes most hardware types as
"ETHERNET", so we still need udev-based tests for those.
https://bugzilla.gnome.org/show_bug.cgi?id=687254
Change the way that nm-properties-changed-signal works, and parse the
dbus-binding-tool-generated info to get the exact list of properties
that it's expected to export.
This makes NM_PROPERTY_PARAM_NO_EXPORT unnecessary, and also fixes the
problem of properties like NMDevice:hw-address being exported on
classes where it shouldn't be.
Reverts part of
2226a00cc2
core: add a "default-unmanaged" setting for devices
Newly-created master interfaces are in the UNAVAILABLE state, but if
they were created in response to a slave connection being activated,
the master must be activated immediately too. But a device cannot
be activated unless it's in the DISCONNECTED state, so restore that
state change.
Add NMDeviceGeneric, to provide generic support for unknown device
types, and create NMDeviceGenerics for those devices that NM
previously was ignoring. Allow NMSettingGeneric connections to be
activated on (managed) NMDeviceGenerics.
Allow devices to declare themselves unmanaged-by-default, but tweak
nm-manager and nm-policy to allow activating matching connections on
those devices anyway.
(This ensures that NM keeps its hands completely off the device unless
the user explicitly asks it to do something with it.)
get_virtual_iface_name() returns an allocated interface name which
we must free; that wasn't being done when attempting to find the
interface for which a virtual interface needs to be created. Also
throw in a cleanup for the given-device-doesn't-exist case just to
make it clearer when the interface name is freed.
Most callers of nm_auth_chain_new() call nm_dbus_manager_get_caller_info()
right before that, so just fold the get_caller_info() call into
nm_auth_chain_new() to reduce code complexity in callers. Yes, this
means sometimes we call nm_dbus_manager_get_caller_info() twice,
but that's not really a problem.
Since dbus senders are faked for private connections, we can't just
call dbus_bus_get_unix_user() on fake senders. They need to be
checked against the NMDBusManager's list of private connections
first.
Instead of doing something like
<get caller UID>
if (root) {
perform_operation()
other boilerplate stuff
return;
}
nm_auth_chain_new(perform_operation)
...
just have root also go through the auth chain, which is now
short circuited for root. This ensures we always use the same
code paths for root and non-root, and that fixes made in one path
are also executed for the other.
dbus-glib has had dbus_g_connection_lookup_g_object() since 0.72
(circa 2006) so instead of parsing the object paths ourselves, let
dbus-glib tell us what object it is, and rely on GObject property
permissions to block writes at the object level, and dbus-glib to
block writes at the D-Bus level based on the introspection XML.
Plus, we can use the various ways to get the caller UID that were
added in previous patches to simplify authentication.
When providing a service on the bus daemon and a private connection,
we'll need to track objects so we can register them with the
private connection too. Thus all registration/unregistration
calls have to go through the NMDBusManager, not straight to
dbus-glib.
Like if the dbus daemon restarts; in this case the connection has changed
and the new connection doesn't have the filter installed, and libdbus
aborts when we try to remove a filter that doesn't exist on the connection.
Fix that by re-adding the filter when the connection changes.
nm_device_connection_match_config() sounded more generic than it
really was; rename it to nm_device_find_assumable_connection(), which
is what it really does.
There was also a lot of redundancy/cut+paste in the subclass
implementations of connection_match_config(); Improve things by moving
the looping-over-connections code into NMDevice itself, and also doing
the general-device-compatibility and IP-config checking there, leaving
the device subclasses to just verify L2 properties. Which most of them
aren't doing...
https://bugzilla.gnome.org/show_bug.cgi?id=693684
Add a "need_carrier" argument to nm_device_is_available(), to allow
distinguishing between "device is not available", "device is fully
available", and "device is available except for not having carrier".
Adjust various parts of NMDevice and NMManager to allow for the
possibility of activating a connection with :carrier-detect = "no" on
a device with no carrier, and to avoid auto-disconnecting devices with
:carrier-detect = "on-activate".
https://bugzilla.gnome.org/show_bug.cgi?id=688284
g_malloc(), etc, never return NULL, by API contract. Likewise, by
extension, no other glib function ever returns NULL due to lack of
memory. So remove lots of unnecessary checks (the vast majority of
which would have immediately crashed had they ever run anyway, since
g_set_error(), g_warning(), and nm_log_*() all need to allocate
memory).
https://bugzilla.gnome.org/show_bug.cgi?id=693678
Like we do when the user sets the Wireless Enabled property at
runtime, ensure the kernel's softblock state is synced with the
user's WiFi enable preference at startup. This helps compensate
for BIOSes that don't save rfkill state over reboots and ensures
consistency of between startup and runtime Wireless Enabled
property behavior.
Suggested by John G.
Some devices (namely PPPoE (pppX), ADSL (nasX, pppX), and
mobile broadband (pppX, bnepX)) create a kernel netdevice for IP
communication (called the "IP interface" in NM) as part of the
connection process and thus the IP interface lifetime does not
correspond to the NMDevice lifetime. For these devices we must
ignore removal events for the IP interface name otherwise the
NMDevice would be removed.
Caused by 8cce42f2.
For example, this bug caused the NMDeviceBt to be removed when
a PAN connection's bnepX interface went down in response to a
terminated Bluetooth connection, which of course means that
you can't restart the PAN connection as your phone is no longer
in the NM device list.
Until we handle bridges non-destructively, only manage bridges
created by NM. When quitting write out a file listing all
bridges created by NM and a timestamp, and when starting read
that file and if the timestamp is within 30 minutes, manage
any bridge that was listed in that file. This scheme, while
not foolproof (eg, if NM crashes), should ensure that NM can
recognize bridges it created if it's restarted. The file
is stored in /run or /var/run, which is cleaned each restart,
ensuring that the state does not persist across reboots.
If an automatic or user-initiated activation request for
a bridge NM does not manage is received, that request is
denied. Only if the bridge interface does not yet exist, or
was present in the managed bridges file, will an
NMDeviceBridge be created and activation be possible.
Since the manager now tracks active connections, it needs to hold
a reference to the active connection objects too. The active
connection teardown code was changed to release that reference
(_active_connection_cleanup()) but the creation code was never
changed to remove the bits that pass ownership over the initial
reference to the NMDevice. Fix that.
Will replace the VPN manager's activated/deactivated signals; listeners
can attach to the active connection's 'state' property and listen
for the changes to ACTIVATED and DEACTIVATED. Works for all connections,
not just VPN ones.
Instead of using devices as a proxy for active connections, and
then also asking the VPN manager for the active connections it's
tracking, just track *all* active connections in the manager.
We'll want to use NMActiveConnection more in the manager and also fold
the PendingActivation functionality into it. All this functionality
applies to the VPN connections too, so it makes sense to have it all
in the base class instead of both NMActRequest and NMVPNConnection.
We don't need to check device state here because the manager, which
is the only thing that calls nm_device_activate() in
internal_activate_device() ensures that the device is deactivated
before starting a new activation request.
The new `MMManager' object takes care of notifying modems added or removed from
the ModemManager1 interface.
We will listen to both the old and new ModemManager implementations, but as soon
as the first ModemManager implementation is found, the other one gets cleared,
so that we don't wait forever to appear.
Previously, when a new bond or VLAN connection was created, NM would
always create the virtual device right away. But on startup, it only
creates virtual devices for connections that can autoconnect. Fix
connection_added() to make that check as well.
The logic behind the `iface' property (which actually is removed) gets split
into three new properties, as follows::
* `uid': Just defines a new string property which must contain a unique ID of
the modem, mainly for logging.
* `control-port': a string property defining which is the control port the
modem uses. This property is actually optional and may be specified as NULL.
The main purpose of this property is to allow the easy integration of the
new ModemManager into the `NMDeviceBt' object. The bluetooth device needs
to know the port used by the modem; and we cannot use the Data port
information as that is only available until the bearer is created. Instead,
for the new ModemManager we will use the control port information exposed.
* `data-port': a string property defining which is the data port to use in the
connection. This property is always defined in the `NMModemGsm' and
`NMModemCdma' objects.
Introduced in 64fd8eea7706038e5d38c8463a1c765ed9331db2; but honestly
I also thought GObject lower-cased signal names since it munges them
for - and _ too. Apparently not.
VLANs are only supported on certain kinds of devices, so don't try to
create them on other devices. (In fact, NM currently assumes that
VLANs are only created on Ethernet devices, so we need to be even more
picky than that.)
