We possibly need the unrealized device for connections that need
this. nm_device_unrealize() will check if there are still any
available-connections and possibly emit DEVICE_REMOVED signal.
Fixes: 7e5f27a21c
When a new device gets added or when an existing one changes name,
virtual connections that refer to it as parent device may become
ready, so let's try to activate them.
Previously we tried to activate virtual connections only on startup
and, after commit d8e1590c50 ("manager: retry device creation for
connection that would use a newly created device"), also when a
connection was added/changed, but this doesn't cover the case in which
a parent device appears or changes name at runtime.
https://bugzilla.redhat.com/show_bug.cgi?id=1275875
When there's a slave that allows autoconnection and an unrealized master this
would cause the master activation to fail.
For the actual auto-activations the proper check is already done in NMPolicy's
auto_activate_device().
Instead of using a signal for triggering the generation of a default
connection when the device becomes managed, let the manager wait for a
transition to UNAVAILABLE or DISCONNECTED states.
This partially reverts b3b0b46250 ("device: retry creation of
default connection after link is initialized").
Only do so on user initiated changes. Fixes this:
# ip link add br0 type bridge
# ip addr add 2001:DB8::666/64 dev br0
# ip link set br0 up # A generated connection is assumed
# ip link del br0 # The device and its address are removed.
# The address removal triggers an update
# of the connection's ipv6 settings,
# which causes the NMDevice to reappear.
# ip link add br0 type bridge # The new plink is associated with
# the NMDevice, managed by NM
Do the reporting in system_create_virtual_device() only. None of the callers
checked for errors and some of the callees did issue a warning despite also
passing back a GError.
Also, drop the return value. It didn't make much sense and was not used anyway.
Fixes this:
nmcli c add type bridge # Creates and realizes the device, autoconnects connection
nmcli c del bridge # Device unrealizes
nmcli c add type bridge # The new connection does not autoconnect, since the
# device stays unrealized
When activating a device, we must progress the device state to
disconnected state.
This matters when activating a device without carrier. In this
case we would have skipped DISCONNECTED state. Skipping the
device state then leads to other issues like a slave device
never noticing that the master got ready.
It's clearer to (always) subscribe early to the NM_DEVICE_RECHECK_ASSUME signal
instead of during realize. Also, because a device can be realized several times.
Just make sure that recheck_assume_connection() doesn't do anything if it shouldn't
handle the event.
Only downside is some unnecessary work when there is nothing to do.
Also fix the signature of the NM_DEVICE_RECHECK_ASSUME handler recheck_assume_connection().
NM_DEVICE_RECHECK_ASSUME signal returns void. We should not subscribe recheck_assume_connection()
which returns gboolean.
But, of course, only one realized device can have the same
interface name at a time.
This commit effectively reverts most of:
1b37cd0340
core: allow ActiveConnections to be created without a device
But it's not easy to do a separate revert of that code due to
interdependencies with nm-manager.c.
Creating devices when they are defined by a connection also makes
makes it possible to require the NMDevice to be present when
activating it, which means we can remove a bunch of code from
NMManager that had to handle software devices not existing yet at
the time of the activation request.
But it also means we must be more careful when finding master
interfaces during slave activation, since we cannot simply match
by interface name alone. Instead we must find the master which
matches both the interface name and can control slaves of the type
which is being activated.
Ensure the platform link with the same interface name as the
NMDevice is actually compatible with it before using the link
for initialization of device properties. If not, remove the
NMDevice and create a new one since there are kernel resources
with a different type.
Unrealized devices aren't backed by kernel resources and so won't know
all of their attributes. That means three things:
1) they must update their attributes when they become realized
2) they must clear those attributes when unrealized
3) they must be looser in checking compatible connections until
they are realized
This requires that the setup() function be split into two parts, start & finish,
because finish must be run after add_device()
Also, we can simplify whether to pay attention to 'recheck-assume', which
is now dependent on priv->is_nm_owned, because the only case where NM should
*not* listen for the 'recheck-assume' signal is when the device is a
software device created by NM itself. That logic was previously spread
across the callers of add_device() but is now consolidated into
nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
Commit cd3df12c8f reused the
virtual function component_added() to notify the vlan device
about a possibly new parent.
This reuse of the virtual function for another purpose is confusing.
Clean that up by splitting the implementation and add a new
virtual function nm_device_notify_new_device_added() which gets
(only implemented by NMDeviceVlan).
This enum was unused and meaningless because the platform signals
are emitted as a consequence of netlink messages. It is not clear
whether a netlink message was received due to an external event
or an internal action.
NMExportedObject now derives from GDBusObjectSkeleton, which is what
GDBusObjectManagerServer wants. The main GDBusConnection and each
private server connection now gets a new GDBusObjectManagerServer,
and exported objects are registered with that instead of individually
exporting each GDBusInterfaceSkeleton.
Previously exported objects were not referenced by the BusManager,
but instead removed from the exports hash via weak references. The
GDBusObjectManagerServer instead references exported objects, which
can make them live much longer than they did before.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
Previously most objects were implicitly unexported when they were
destroyed, but since refcounts may make the object live longer than
intended, we should explicitly unexport them when they should no
longer be present on the bus.
This means we can assume that objects will always be un-exported
already when they are destroyed, *except* when quitting where most
objects will live until exit because NM leaves interfaces up and
running on quit.
For an explicit user-request, we relax some checks when searching for a suitable
device; such as requiring-carrier.
Without this patch, a connection-up while the device has no carrier yet,
would fail right away with "No suitable device found for this connection."
https://bugzilla.redhat.com/show_bug.cgi?id=1079353
Fixes: 0bfe635119
A separate instance of the support plugin is spawned for each connection with
a different bus name. The bus name is passed via --bus-name <name> argument.
Plugins that support the feature indicate it with
support-multiple-connections=true key in the [VPN Connection] section.
The bus name is currently generated by adding a .<connection.uuid> to the VPN
service name. It's guarranteed unique, but if it proves to be too long or ugly
it can easily be replaced with something more meaningful (such as the same number
as is used for connection's DBus name).
NMVpnService has been removed and folded into NMVpnConnection. A
NMVpnConnection will spawn a service plugin instance whenever it is activated
and notices the bus name it needs is not provided.
The NMVpnManager no longer needs to keep track of the connections in use apart
for compatibility purposes with plugins that don't support the feature.
g_dbus_message_get_interface() can return NULL in the message filter,
for example when the client does:
#!/usr/bin/env python
import dbus
bus = dbus.SystemBus()
proxy = bus.get_object("org.freedesktop.NetworkManager",
"/org/freedesktop/NetworkManager")
proxy.foobar()
Use g_strcmp0() to compare the interface and member names.
Fixes: 34ba4e14b8
Clone the connection upon activation. This makes it safe for the user
to modify the original connection while it is activated.
This involves several changes:
- NMActiveConnection gets @settings_connection and @applied_connection.
To support add-and-activate, we constructing a NMActiveConnection with
no connection set. Previously, we would set the "connection" field to
a temporary NMConnection. Now NMManager piggybacks this temporary
connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE).
- get rid of the functions nm_active_connection_get_connection_type()
and nm_active_connection_get_connection_uuid(). From their names
it is unclear whether this returns the settings or applied connection.
The (few) callers should figure that out themselves.
- rename nm_active_connection_get_id() to
nm_active_connection_get_settings_connection_id(). This function
is only used internally for logging.
- dispatcher calls now get two connections as well. The
applied-connection is used for the connection data, while
the settings-connection is used for the connection path.
- needs special handling for properties that apply immediately
when changed (nm_device_reapply_settings_immediately()).
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=724041
