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
This way, the function matches the other names like nm_device_set_unmanaged().
Arguably, the name currently makes some sense. But future commits will make
nm_device_get_unmanaged() more to be a counterpart of nm_device_set_unmanaged().
- Also if the target object is the NMManager instance itself,
re-fetch the manager via nm_bus_manager_get_registered_object().
This way, we only set the property on the manager, if
it's also exported according to the bus-manager. Also,
we don't treat the manager instance special.
- Move fetching the object (nm_bus_manager_get_registered_object())
from do_set_property_check() to prop_set_auth_done_cb(). Otherwise,
we fetch the object first, but there is no guarantee that the object
is still exported after the asynchronous authentication succeeds.
Previously, nm_bus_manager_register_object() would take various D-Bus
skeleton objects that were associated with one NMExportedObject.
This was confusing, in that these skeleton objects are all for the
same NMObject but correspond to different D-Bus interfaces.
Also, setting the D-Bus property "Managed" of a Device is broken
because we might retrieve the wrong skeleton.
Now, the NMBusManager has a reference to the exported object directly.
The skeleton interface instances instead are now exposed by the NMExportedObject.
#0 0x00007fc52202dd3b in g_logv (breakpoint=1) at gmessages.c:315
#1 0x00007fc52202dd3b in g_logv (log_domain=0x7fc522351b84 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffeb818bfc0) at gmessages.c:1041
#2 0x00007fc52202deaf in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1079
#3 0x000055c658ee819f in free_property_filter_data (pfd=0x55c65a009000) at nm-manager.c:4418
#4 0x000055c658ee7e67 in do_set_property_check (user_data=0x55c65a009000) at nm-manager.c:4515
#5 0x00007fc522026a8a in g_main_context_dispatch (context=0x55c659e161c0) at gmain.c:3122
#6 0x00007fc522026a8a in g_main_context_dispatch (context=context@entry=0x55c659e161c0) at gmain.c:3737
#7 0x00007fc522026e20 in g_main_context_iterate (context=0x55c659e161c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
#8 0x00007fc522027142 in g_main_loop_run (loop=0x55c659e16280) at gmain.c:4002
#9 0x000055c658e047ee in main (argc=1, argv=0x7ffeb818c508) at main.c:449
Fixes: 751c674643
Without that the device is not properly initialized. It misses hardware
address and type description.
Testcase:
$ sudo ip link add dummy0 type dummy
$ nmcli device
DEVICE TYPE STATE CONNECTION
em1 ethernet connected Ethernet connection 1
FF wifi connected --
bond0 bond unmanaged --
bond1 bond unmanaged --
dummy0 unmanaged --
lo unmanaged --
Fixes: e8139f56c2
When a new link is detected, NM tries to generate a default "Wired
connection" in nm_settings_device_added(), but if the link has not
been initialized by udev yet the function returns early because
priv->unmanaged_flags = UNMANAGED_PLATFORM_INIT.
To be sure that a default connection is created is such situation, we
need to call again nm_settings_device_added() after link
initialization.
https://bugzilla.redhat.com/show_bug.cgi?id=1254089
check_if_startup_complete() could be invoked from nm_settings_start() before
devices had chance to be added, which results in premature "startup complete"
and NM would quit when configure-and-quit=yes is set up.
Postpone actual check_if_startup_complete() resolution until we add all devices
and they are processed.
(gdb) bt
#0 0x00005555556401f3 in check_if_startup_complete (self=0x5555559f91d0)
at nm-manager.c:719
#1 0x00007ffff4d69de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#2 0x00007ffff4d7b70d in signal_emit_unlocked_R ()
at /lib64/libgobject-2.0.so.0
#3 0x00007ffff4d83471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#4 0x00007ffff4d8372f in g_signal_emit () at /lib64/libgobject-2.0.so.0
#5 0x00007ffff4d6e4b5 in g_object_dispatch_properties_changed ()
at /lib64/libgobject-2.0.so.0
#6 0x00007ffff4d709d9 in g_object_notify () at /lib64/libgobject-2.0.so.0
#7 0x00005555556e232c in check_startup_complete (self=self@entry=0x555555a0e130) at settings/nm-settings.c:204
#8 0x00005555556e5203 in nm_settings_start (self=0x555555a0e130, error=error@entry=0x7fffffffe658) at settings/nm-settings.c:2122
#9 0x0000555555646d06 in nm_manager_start (self=0x5555559f91d0, error=0x7fffffffe658) at nm-manager.c:4153
#10 0x00005555555add43 in main (argc=1, argv=0x7fffffffe7c8) at main.c:428
(gdb)
Fixes:Beaker:NetworkManager_Test37_run_once_new_connection
https://bugzilla.redhat.com/show_bug.cgi?id=1256772
prop_filter() gets invoked on another thread and we don't take
a strong reference to the manager when subscribing the filter.
Fix the race, by passing on a weak reference.
