fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-27 22:10:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/nm-manager.c

8315 lines
294 KiB
C
Raw Normal View History

all: SPDX header conversion $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
2019-09-10 11:19:01 +02:00
// SPDX-License-Identifier: GPL-2.0+
all: manually drop code comments with file description
2019-09-25 13:13:40 +02:00
/*
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
* Copyright (C) 2007 - 2009 Novell, Inc.
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
* Copyright (C) 2007 - 2017 Red Hat, Inc.
2008-11-02 Dan Williams <dcbw@redhat.com> * Add license headers to everything in src/ git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4247 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-03 04:13:42 +00:00
*/
2007-08-14 Tambet Ingo <tambet@gmail.com> * libnm-glib/Makefile.am: Use nm-manager-client.xml to produce * nm-client-bindings. * introspection/nm-manager-client.xml: Add a horrible horrbile * hack to work around an issue with dbus-glib bindings generator. The issue is, the generated C caller functions for dbus methods "Sleep(bool)" and "sleep()" both have the same function name and different arguments and it won't compile anymore. To fix this, we now have two copies of nm-manager.xml file. nm-manager.xml contains the actual interface, that is new API + compatibility API and used by the daemon. The other, nm-manager-client.xml is only the new API without compatibility bits and is used by libnm-glib to make it compile. * introspection/nm-manager.xml: Define compatibility methods * (sleep, wake, state). * src/nm-manager.c (impl_manager_legacy_sleep) (impl_manager_legacy_wake, impl_manager_legacy_state): Implement the compatibility interface functions for 0.6 branch. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2688 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-08-15 07:52:25 +00:00
all: cleanup includes and let "nm-default.h" include "config.h" - All internal source files (except "examples", which are not internal) should include "config.h" first. As also all internal source files should include "nm-default.h", let "config.h" be included by "nm-default.h" and include "nm-default.h" as first in every source file. We already wanted to include "nm-default.h" before other headers because it might contains some fixes (like "nm-glib.h" compatibility) that is required first. - After including "nm-default.h", we optinally allow for including the corresponding header file for the source file at hand. The idea is to ensure that each header file is self contained. - Don't include "config.h" or "nm-default.h" in any header file (except "nm-sd-adapt.h"). Public headers anyway must not include these headers, and internal headers are never included after "nm-default.h", as of the first previous point. - Include all internal headers with quotes instead of angle brackets. In practice it doesn't matter, because in our public headers we must include other headers with angle brackets. As we use our public headers also to compile our interal source files, effectively the result must be the same. Still do it for consistency. - Except for <config.h> itself. Include it with angle brackets as suggested by https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
2016-02-19 14:57:48 +01:00
#include "nm-default.h"
core: fix builds with polkit >= 0.97 polkit_authority_get() is deprecated, should use polkit_authority_get_sync() instead.
2010-08-13 13:18:58 -05:00
core: drop NMConnectionProvider and use NMSettings directly This is not C# but glib. Using interfaces is so cumbersome, that they don't simplify code but make it more complicated. E.g. following signals and its subscribers is complicated enough. It gets more complicated by having NM_SETTINGS_SIGNAL_CONNECTION_ADDED and NM_CP_SIGNAL_CONNECTION_ADDED. Of course, your favorite IDE has no idea about glib interfaces, so figuring out who calls who gets more complicated. This undoes commit 4fe48b1273cff8dde3688a1dc4b7bcbf0a9e16f4. Originally, NMConnectionProvider had only one function get_best_connection(). But it kept growing and more functions were added. If we want to ~hide~ certain part of the NMSettings API, we should move them to a separate header which gives internal access.
2016-05-16 18:08:08 +02:00
#include "nm-manager.h"
trivial: don't rely on indirect include
2013-05-27 20:35:33 +02:00
#include <stdlib.h>
core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002) This commit changes rfkill state handling slightly in the following ways: - when checking whether a user toggle request can change radio state, ignore states we can change in radio_enabled_for_rstate() as a result of the toggle; this fixes WiMAX enable/disable because a softblock can be changed by telling wimaxd to enable the radio. As a side-effect this also fixes handling of WiFi when altering the rfkill state as well. - make WiFi user toggle requests change wifi killswitch state; this has been long requested and on the TODO list for a while and it turns out to be a lot easier to do these days. This provides the expected behavior when disabling wireless from user agent menus since there's not an easy way to do this other than dropping to shell and running rfkill.
2011-04-22 14:56:31 -05:00
#include <fcntl.h>
core: add missing system includes for: open(2), close(2), etc. for types like ssize_t
2012-02-22 16:52:41 +01:00
#include <unistd.h>
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" From the files under "shared/nm-utils" we build an internal library that provides glib-based helper utilities. Move the files of that basic library to a new subdirectory "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la" to "libnm-glib-aux.la". Reasons: - the name "utils" is overused in our code-base. Everything's an "utils". Give this thing a more distinct name. - there were additional files under "shared/nm-utils", which are not part of this internal library "libnm-utils-base.la". All the files that are part of this library should be together in the same directory, but files that are not, should not be there. - the new name should better convey what this library is and what is isn't: it's a set of utilities and helper functions that extend glib with funcitonality that we commonly need. There are still some files left under "shared/nm-utils". They have less a unifying propose to be in their own directory, so I leave them there for now. But at least they are separate from "shared/nm-glib-aux", which has a very clear purpose. (cherry picked from commit 80db06f768e47541eae7d66ef48fbe47bf1a69ce)
2019-04-15 08:16:00 +02:00
#include "nm-glib-aux/nm-c-list.h"
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core "libnm-core" implements common functionality for "NetworkManager" and "libnm". Note that clients like "nmcli" cannot access the internal API provided by "libnm-core". So, if nmcli wants to do something that is also done by "libnm-core", , "libnm", or "NetworkManager", the code would have to be duplicated. Instead, such code can be in "libnm-libnm-core-{intern|aux}.la". Note that: 0) "libnm-libnm-core-intern.la" is used by libnm-core itsself. On the other hand, "libnm-libnm-core-aux.la" is not used by libnm-core, but provides utilities on top of it. 1) they both extend "libnm-core" with utlities that are not public API of libnm itself. Maybe part of the code should one day become public API of libnm. On the other hand, this is code for which we may not want to commit to a stable interface or which we don't want to provide as part of the API. 2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core" and thus directly available to "libnm" and "NetworkManager". On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm" and "NetworkManager". Both libraries may be statically linked by libnm clients (like nmcli). 3) it must only use glib, libnm-glib-aux.la, and the public API of libnm-core. This is important: it must not use "libnm-core/nm-core-internal.h" nor "libnm-core/nm-utils-private.h" so the static library is usable by nmcli which couldn't access these. Note that "shared/nm-meta-setting.c" is an entirely different case, because it behaves differently depending on whether linking against "libnm-core" or the client programs. As such, this file must be compiled twice. (cherry picked from commit af07ed01c04867e281cc3982a7ab0d244d4f8e2e)
2019-04-15 09:26:53 +02:00
#include "nm-libnm-core-intern/nm-common-macros.h"
core: rename "nm-bus-manager.h" to "nm-dbus-manager.h" The next commit will completely rework NMBusManager and replace NMExportedObject by a new type NMDBusObject. Originally, NMDBusObject was added along NMExportedObject to ease the rework and have compilable, intermediate stages of refactoring. Now, I think the new name is better, because NMDBusObject is very strongly related to the bus manager and the old name NMExportedObject didn't make that clear. I also slighly prefer the name NMDBusObject over NMBusObject, hence for consistancy, also rename NMBusManager to NMDBusManager. This commit only renames the file for a nicer diff in the next commit. It does not actually update the type name in sources. That will be done later.
2018-03-02 05:55:21 +01:00
#include "nm-dbus-manager.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "vpn/nm-vpn-manager.h"
#include "devices/nm-device.h"
#include "devices/nm-device-generic.h"
#include "platform/nm-platform.h"
platform: refactor nm_platform_link_get_all() to return GPtrArray Instead of doing a full clone, return a pointer array (with references owned). The NMPlatformLink instances are now immutable.
2017-07-04 22:29:27 +02:00
#include "platform/nmp-object.h"
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
#include "nm-hostname-manager.h"
keep-alive: use NMKeepAlive API directly instead of via NMActiveConnection NMKeepAlive is a proper GObject type, with a specific API that on the one end allows to configure watches/bindings, and on the other end exposes and is-alive property and the owner instance. That's great, as NMActiveConnection is not concerned with either end (moving complexity away from "nm-active-connection.c") and as we later can reuse NMKeepAlive with NMSettingsConnection. However, we don't need to wrap this API by NMActiveConnection. Doing so means, we need to expose all the watch/bind functions also as part of NMActiveConnection API. The only ugliness here is, that NMPolicy subscribes to property changed signal of the keep alive instance, which would fail horribly if NMActiveConnection ever decides to swap the keep alive instance (in which case NMPolicy would have to disconnect the signal, and possibly reconnect it to another NMKeepAlive instance). We avoid that by just not doing that and documenting it.
2018-11-20 14:51:22 +01:00
#include "nm-keep-alive.h"
core: split NMRfkillManager out of NMUdevManager Split the rfkill-monitoring parts of NMUdevManager into a separate class. Now NMUdevManager only handles device enumeration.
2013-05-09 10:24:08 -04:00
#include "nm-rfkill-manager.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "dhcp/nm-dhcp-manager.h"
#include "settings/nm-settings.h"
#include "settings/nm-settings-connection.h"
auth: rename file nm-manager-auth.* to nm-auth-utils.* Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-16 01:33:46 +02:00
#include "nm-auth-utils.h"
auth: rework polkit autorization to use DBUS interface directly This makes NetworkManager independent of <polkit/polkit.h> development headers and libpolkit-gobject-1.so library. Instead communicate directly with polkit using its DBUS interface. PolicyKit support is now always compiled in. You can control polkit authorization with the configuration option [main] auth-polkit=yes|no If the configure option is omitted, a build time default value is used. This default value can be set with the configure option --enable-polkit. This commit adds a new class NMAuthManager that reimplements the relevant DBUS client parts. It takes source code from the polkit library. https://bugzilla.gnome.org/show_bug.cgi?id=734146 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-14 13:34:57 +02:00
#include "nm-auth-manager.h"
core: allow minimal completion of VPN connections for AddAndActivate We can at least fill in the connection setting if we're just given the VPN setting.
2011-01-13 13:30:30 -06:00
#include "NetworkManagerUtils.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "devices/nm-device-factory.h"
core: factor out the upower suspend/resume code (bgo #677694) Factor the code that listens for upower sleeping and resuming signals out into a class code NMSleepMonitor.
2012-10-09 00:36:35 -04:00
#include "nm-sleep-monitor.h"
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
#include "nm-connectivity.h"
core: make NMPolicy a GObject And make it owned by NMManager, rather than being a separate top-level object.
2013-08-22 10:10:17 -04:00
#include "nm-policy.h"
core: fill in nm-types.h, clean out other headers Clean up some of the cross-includes between headers (which made it so that, eg, if you included NetworkManagerUtils.h in a test program, you would need to build the test with -I$(top_srcdir)/src/platform, and if you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all GObject struct definitions for src/ and src/settings/ into nm-types.h (which already existed to solve the NMDevice/NMActRequest circular references). Update various .c files to explicitly include the headers they used to get implicitly, and remove some now-unnecessary -I options from Makefiles.
2014-07-17 17:06:44 -04:00
#include "nm-session-monitor.h"
core: rename "nm-activation-request.[hc]" for NMActRequest "nm-activation-request.[hc]" contains NMActRequest. It should thus be called "nm-act-request.[hc]".
2016-09-28 19:37:10 +02:00
#include "nm-act-request.h"
libnm-core: add nm-core-types.h, remove cross-includes Add nm-core-types.h, typedefing all of the GObject types in libnm-core; this is needed so that nm-setting.h can reference NMConnection in addition to nm-connection.h referencing NMSetting. Removing the cross-includes from the various headers causes lots of fallout elsewhere. (In particular, nm-utils.h used to include nm-connection.h, which included every setting header, so any file that included nm-utils.h automatically got most of the rest of libnm-core without needing to pay attention to specifics.) Fix this up by including nm-core-internal.h from those files that are now missing includes.
2014-10-21 22:09:52 -04:00
#include "nm-core-internal.h"
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
#include "nm-config.h"
manager: add audit support
2015-07-14 10:26:54 +02:00
#include "nm-audit-manager.h"
shared: move "nm-dbus-compat.h" header to "nm-std-aux/nm-dbus-compat.h" (cherry picked from commit 81833358786b0fdd0668ef92b0bdc1361fa980b3)
2019-04-15 09:23:31 +02:00
#include "nm-std-aux/nm-dbus-compat.h"
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
#include "nm-checkpoint.h"
#include "nm-checkpoint-manager.h"
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
#include "nm-dbus-object.h"
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
#include "nm-dispatcher.h"
core: nm_singleton_instance_register() of NMManager instance Register the singleton instance of NMManager as we do for other singletons. That way, we get automatic destruction and the singleton instance get's properly cleared (when the instance gets destroyed).
2015-08-10 16:38:26 +02:00
#include "NetworkManagerUtils.h"
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
/*****************************************************************************/
2007-09-28 Tambet Ingo <tambet@gmail.com> * src/nm-manager.c: * src/nm-manager.h: Implement device activation through NMManager. Implement "pending device activation" here - If the connection isn't found, we try to wait for up to 5 seconds for the connection to be provided. Add NMConnectionType argument to "connection-added" and "connection-removed" signals. (nm_manager_get): Remove. Finally. * src/nm-activation-request.c: * src/nm-activation-request.h: Remove all the deferred activation code. * src/nm-device.c: Remove all the deferred activation code. Once * the device activation is started, it's started. Update the activation virtual function signature. * src/nm-device-interface.c: * src/nm-device-interface.h: Device activation now takes only NMActRequest argument. Don't expose device activation directly on dbus, it's supposed to go through NMManager now. * src/NetworkManagerPolicy.c (nm_policy_device_change_check): * Make the code a bit more compact. Use the new device activation methods through NMManager. * introspection/nm-manager-client.xml: * introspection/nm-manager.xml: * libnm-glib/nm-client.c: * libnm-glib/nm-client.h: Add device activation method. * libnm-glib/nm-device.c: * libnm-glib/nm-device.h: * introspection/nm-device.xml: Remove device activation method. It's done through NMManager now. * src/vpn-manager/nm-vpn-manager.c (impl_vpn_manager_connect): * Use the shiny new (nm_manager_get_device_by_path) function, get rid of our own )find_device). git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2915 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-10-01 15:38:39 +00:00
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
typedef struct {
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
gboolean user_enabled;
gboolean sw_enabled;
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
gboolean hw_enabled;
core: better matching of rfkill types This also fixes a bug where WWAN devices were not correctly recognized for enable/disable operations.
2010-03-25 11:36:19 -07:00
RfKillType rtype;
config: let NMConfig handle "NetworkManager.state" file (bgo#764474) Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
2015-11-06 16:45:27 +01:00
NMConfigRunStatePropertyType key;
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
const char *desc;
const char *prop;
const char *hw_prop;
} RadioState;
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
typedef enum {
ASYNC_OP_TYPE_AC_AUTH_ACTIVATE_INTERNAL,
ASYNC_OP_TYPE_AC_AUTH_ACTIVATE_USER,
ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE,
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE2,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
} AsyncOpType;
typedef struct {
CList async_op_lst;
NMManager *self;
AsyncOpType async_op_type;
union {
struct {
NMActiveConnection *active;
union {
struct {
GDBusMethodInvocation *invocation;
} activate_user;
struct {
GDBusMethodInvocation *invocation;
NMConnection *connection;
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
NMSettingsConnectionPersistMode persist_mode;
bool is_volatile:1;
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
} add_and_activate;
};
} ac_auth;
};
} AsyncOpData;
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
enum {
DEVICE_ADDED,
INTERNAL_DEVICE_ADDED,
DEVICE_REMOVED,
INTERNAL_DEVICE_REMOVED,
ACTIVE_CONNECTION_ADDED,
ACTIVE_CONNECTION_REMOVED,
CONFIGURE_QUIT,
LAST_SIGNAL
};
static guint signals[LAST_SIGNAL] = { 0 };
NM_GOBJECT_PROPERTIES_DEFINE (NMManager,
PROP_VERSION,
PROP_CAPABILITIES,
PROP_STATE,
PROP_STARTUP,
PROP_NETWORKING_ENABLED,
PROP_WIRELESS_ENABLED,
PROP_WIRELESS_HARDWARE_ENABLED,
PROP_WWAN_ENABLED,
PROP_WWAN_HARDWARE_ENABLED,
PROP_WIMAX_ENABLED,
PROP_WIMAX_HARDWARE_ENABLED,
PROP_ACTIVE_CONNECTIONS,
PROP_CONNECTIVITY,
PROP_CONNECTIVITY_CHECK_AVAILABLE,
PROP_CONNECTIVITY_CHECK_ENABLED,
libnm,core: Add ConnectivityCheckUri property and accessors So that applications like GNOME Shell can hit the same URI to show the captive portal login page. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/209
2019-07-22 15:55:15 +01:00
PROP_CONNECTIVITY_CHECK_URI,
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
PROP_PRIMARY_CONNECTION,
PROP_PRIMARY_CONNECTION_TYPE,
PROP_ACTIVATING_CONNECTION,
PROP_DEVICES,
PROP_METERED,
PROP_GLOBAL_DNS_CONFIGURATION,
PROP_ALL_DEVICES,
PROP_CHECKPOINTS,
/* Not exported */
PROP_SLEEPING,
);
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
typedef struct {
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
NMPlatform *platform;
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
GArray *capabilities;
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
CList active_connections_lst_head;
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
CList async_op_lst_head;
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
guint ac_cleanup_id;
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
NMActiveConnection *primary_connection;
NMActiveConnection *activating_connection;
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
NMMetered metered;
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
CList devices_lst_head;
2007-09-25 Dan Williams <dcbw@redhat.com> * src/nm-manager.c - (nm_manager_update_state): new function; updates state and emits appropriate signals ensuring a state-change signal for the same state never gets emitted twice in a row. - (manager_device_state_changed): handle more device state to get a better picture of the overall NM state git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2882 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-25 16:47:53 +00:00
NMState state;
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
NMConfig *config;
connectivity: schedule connectivity timers per-device and probe for short outages It might happen, that connectivitiy is lost only for a moment and returns soon after. Based on that assumption, when we loose connectivity we want to have a probe interval where we check for returning connectivity more frequently. For that, we handle tracking of the timeouts per-device. The intervall shall start with 1 seconds, and double the interval time until the full interval is reached. Actually, due to the implementation, it's unlikely that we already perform the second check 1 second later. That is because commonly the first check returns before the one second timeout is reached and bumps the interval to 2 seconds right away. Also, we go through extra lengths so that manual connectivity check delay the periodic checks. By being more smart about that, we can reduce the number of connectivity checks, but still keeping the promise to check at least within the requested interval. The complexity of book keeping the timeouts is remarkable. But I think it is worth the effort and we should try hard to - have a connectivity state as accurate as possible. Clearly, connectivity checking means that we probing, so being more intelligent about timeout and backoff timers can result in a better connectivity state. The connectivity state is important because we use it for the default-route penaly and the GUI indicates bad connectivity. - be intelligent about avoiding redundant connectivity checks. While we want to check often to get an accurate connectivity state, we also want to minimize the number of HTTP requests, in case the connectivity is established and suppossedly stable. Also, perform connectivity checks in every state of the device. Even if a device is disconnected, it still might have connectivity, for example if the user externally adds an IP address on an unmanaged device. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-02-20 21:41:14 +01:00
NMConnectivity *concheck_mgr;
core: make NMPolicy a GObject And make it owned by NMManager, rather than being a separate top-level object.
2013-08-22 10:10:17 -04:00
NMPolicy *policy;
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
NMHostnameManager *hostname_manager;
manager: fix race subscribing prop_filter() 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.
2015-08-20 14:25:46 +02:00
struct {
GDBusConnection *connection;
guint id;
} prop_filter;
core: split NMRfkillManager out of NMUdevManager Split the rfkill-monitoring parts of NMUdevManager into a separate class. Now NMUdevManager only handles device enumeration.
2013-05-09 10:24:08 -04:00
NMRfkillManager *rfkill_mgr;
2008-01-02 Tambet Ingo <tambet@gmail.com> * libnm-util/nm-setting-serial.c (nm_setting_serial_class_init): * Mark the properties with G_PARAM_CONSTRUCT so that they get the default values. * src/nm-gsm-device.c: Add preliminary support for monitoring * device. It only monitors the monitoring device and prints out the output for now. Or more precicely, doesn't do absolutely anything right now since the montoring device argument is never set. * src/nm-serial-device.c (serial_debug): Implement. It's very * verbose and thus requires it's own knob to turn it on. (config_fd): Add NMSettingSerial to the arguments list. (nm_serial_device_open): Ditto. (get_reply_got_data): Ignore the terminators at the beginning of the output. (nm_serial_device_get_io_channel): Implement. * src/nm-manager.c: Add NMDBusManager to the private data of the * NMManager. Asking a new reference every time (and forgetting to release it sometimes) is a pain and it's not like NMManager could work without dbus. (nm_manager_add_device): Register the added device on dbus here. * src/nm-hal-manager.c (modem_device_creator): Pass NULL for now * for the monitoring device. * src/nm-device.c (constructor): Don't export the device here, * instead export it when it's added to the NMManager's device list. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3203 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-01-02 13:42:52 +00:00
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
CList link_cb_lst;
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
NMCheckpointManager *checkpoint_mgr;
settings: rename NMSysconfigSettings to NMSettings
2010-10-27 20:05:23 -05:00
NMSettings *settings;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
core: create virtual device on settings changes in idle handler The callback from NMSettings about adding/updating a settings comes from a deep call-stack already. We don't know the context of it, and we shouldn't just right away create the profile. Instead, schedule an action to create it in an idle handler.
2019-06-30 10:33:28 +02:00
CList connection_changed_on_idle_lst;
guint connection_changed_on_idle_id;
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
RadioState radio_states[RFKILL_TYPE_MAX];
libnm, core, cli, tui: fix the capitalization of various types GLib/Gtk have mostly settled on the convention that two-letter acronyms in type names remain all-caps (eg, "IO"), but longer acronyms become initial-caps-only (eg, "Tcp"). NM was inconsistent, with most long acronyms using initial caps only (Adsl, Cdma, Dcb, Gsm, Olpc, Vlan), but others using all caps (DHCP, PPP, PPPOE, VPN). Fix libnm and src/ to use initial-caps only for all three-or-more-letter-long acronyms (and update nmcli and nmtui for the libnm changes).
2014-06-26 13:44:36 -04:00
NMVpnManager *vpn_manager;
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
core: factor out the upower suspend/resume code (bgo #677694) Factor the code that listens for upower sleeping and resuming signals out into a class code NMSleepMonitor.
2012-10-09 00:36:35 -04:00
NMSleepMonitor *sleep_monitor;
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
manager: keep reference on NMAuthManager singleton A singleton (NMManager) subscribing to another singleton (NMAuthManager) should take a reference on the latter, to ensure its lifetime is longer.
2016-07-01 14:25:34 +02:00
NMAuthManager *auth_mgr;
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
GHashTable *device_route_metrics;
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
CList auth_lst_head;
manager: disconnect devices before unmanaging them on suspend/sleep So that dispatcher scripts are run and other applications notified of the change in connectivity. https://bugzilla.redhat.com/show_bug.cgi?id=1330694 https://bugzilla.gnome.org/show_bug.cgi?id=748531
2016-05-05 14:14:40 +02:00
GHashTable *sleep_devices;
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
/* Firmware dir monitor */
GFileMonitor *fw_monitor;
guint fw_changed_id;
core: update timestamp in active system connections every 5 mins (bgo #583756) This patch updates timestamps in system connections. The update occurs on connection activation and then periodically every 5 mins while the connection is active. It only works for plugins having write support and for writable connections (not read-only).
2010-10-19 11:10:17 +02:00
guint timestamp_update_id;
manager: delay startup-complete and devices-inited until idle As long as there are events in the mainloop that are ready for dispatch, it's clear that startup-complete is not yet reached. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-14 10:42:36 +01:00
guint devices_inited_id;
connectivity: schedule connectivity timers per-device and probe for short outages It might happen, that connectivitiy is lost only for a moment and returns soon after. Based on that assumption, when we loose connectivity we want to have a probe interval where we check for returning connectivity more frequently. For that, we handle tracking of the timeouts per-device. The intervall shall start with 1 seconds, and double the interval time until the full interval is reached. Actually, due to the implementation, it's unlikely that we already perform the second check 1 second later. That is because commonly the first check returns before the one second timeout is reached and bumps the interval to 2 seconds right away. Also, we go through extra lengths so that manual connectivity check delay the periodic checks. By being more smart about that, we can reduce the number of connectivity checks, but still keeping the promise to check at least within the requested interval. The complexity of book keeping the timeouts is remarkable. But I think it is worth the effort and we should try hard to - have a connectivity state as accurate as possible. Clearly, connectivity checking means that we probing, so being more intelligent about timeout and backoff timers can result in a better connectivity state. The connectivity state is important because we use it for the default-route penaly and the GUI indicates bad connectivity. - be intelligent about avoiding redundant connectivity checks. While we want to check often to get an accurate connectivity state, we also want to minimize the number of HTTP requests, in case the connectivity is established and suppossedly stable. Also, perform connectivity checks in every state of the device. Even if a device is disconnected, it still might have connectivity, for example if the user externally adds an IP address on an unmanaged device. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-02-20 21:41:14 +01:00
NMConnectivityState connectivity_state;
manager: delay startup-complete and devices-inited until idle As long as there are events in the mainloop that are ready for dispatch, it's clear that startup-complete is not yet reached. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-14 10:42:36 +01:00
bool startup:1;
bool devices_inited:1;
bool sleeping:1;
bool net_enabled:1;
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
connectivity: emit properties-changed about connectivity settings
2018-04-10 15:55:16 +02:00
unsigned connectivity_check_enabled_last:2;
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
guint delete_volatile_connection_idle_id;
CList delete_volatile_connection_lst_head;
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
} NMManagerPrivate;
manager: make NMManager's structs private They are only useful when we want to derive a class from NM_TYPE_MANAGER -- which we clearly don't.
2016-04-28 14:03:32 +02:00
struct _NMManager {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMDBusObject parent;
manager: preserve constness in NM_MANAGER_GET_PRIVATE() and add compile-time type check
2016-07-01 15:23:29 +02:00
NMManagerPrivate _priv;
manager: make NMManager's structs private They are only useful when we want to derive a class from NM_TYPE_MANAGER -- which we clearly don't.
2016-04-28 14:03:32 +02:00
};
typedef struct {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMDBusObjectClass parent;
manager: make NMManager's structs private They are only useful when we want to derive a class from NM_TYPE_MANAGER -- which we clearly don't.
2016-04-28 14:03:32 +02:00
} NMManagerClass;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
G_DEFINE_TYPE (NMManager, nm_manager, NM_TYPE_DBUS_OBJECT)
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
core: use _NM_GET_PRIVATE() macros
2016-09-05 16:55:07 +02:00
#define NM_MANAGER_GET_PRIVATE(self) _NM_GET_PRIVATE(self, NMManager, NM_IS_MANAGER)
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
/*****************************************************************************/
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
core: add NMLOG macros to nm-manager.c
2016-01-18 14:04:56 +01:00
NM_DEFINE_SINGLETON_INSTANCE (NMManager);
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: add NMLOG macros to nm-manager.c
2016-01-18 14:04:56 +01:00
#define _NMLOG_PREFIX_NAME "manager"
manager: use logging helpers
2016-03-02 11:38:26 +01:00
#define _NMLOG(level, domain, ...) \
core: add NMLOG macros to nm-manager.c
2016-01-18 14:04:56 +01:00
G_STMT_START { \
manager: add logging macro _NMLOG2() for logging device messages It unifies the way how we print the logging prefix, but also it passes the ifname down for structured logging.
2017-06-07 12:46:10 +02:00
const NMLogLevel _level = (level); \
const NMLogDomain _domain = (domain); \
core: add NMLOG macros to nm-manager.c
2016-01-18 14:04:56 +01:00
\
manager: add logging macro _NMLOG2() for logging device messages It unifies the way how we print the logging prefix, but also it passes the ifname down for structured logging.
2017-06-07 12:46:10 +02:00
if (nm_logging_enabled (_level, _domain)) { \
const NMManager *const _self = (self); \
char _sbuf[32]; \
manager: use logging helpers
2016-03-02 11:38:26 +01:00
\
manager: add logging macro _NMLOG2() for logging device messages It unifies the way how we print the logging prefix, but also it passes the ifname down for structured logging.
2017-06-07 12:46:10 +02:00
_nm_log (_level, _domain, 0, NULL, NULL, \
manager: use logging helpers
2016-03-02 11:38:26 +01:00
"%s%s: " _NM_UTILS_MACRO_FIRST (__VA_ARGS__), \
_NMLOG_PREFIX_NAME, \
manager: add logging macro _NMLOG2() for logging device messages It unifies the way how we print the logging prefix, but also it passes the ifname down for structured logging.
2017-06-07 12:46:10 +02:00
((_self && _self != singleton_instance) \
? nm_sprintf_buf (_sbuf, "[%p]", _self) \
: "") \
_NM_UTILS_MACRO_REST (__VA_ARGS__)); \
} \
} G_STMT_END
#define _NMLOG2(level, domain, device, ...) \
G_STMT_START { \
const NMLogLevel _level = (level); \
const NMLogDomain _domain = (domain); \
\
if (nm_logging_enabled (_level, _domain)) { \
const NMManager *const _self = (self); \
const char *const _ifname = _nm_device_get_iface (device); \
char _sbuf[32]; \
\
_nm_log (_level, _domain, 0, \
_ifname, NULL, \
"%s%s: %s%s%s" _NM_UTILS_MACRO_FIRST (__VA_ARGS__), \
_NMLOG_PREFIX_NAME, \
((_self && _self != singleton_instance) \
? nm_sprintf_buf (_sbuf, "[%p]", _self) \
: ""), \
NM_PRINT_FMT_QUOTED (_ifname, "(", _ifname, "): ", "") \
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_NM_UTILS_MACRO_REST (__VA_ARGS__)); \
} \
core: add NMLOG macros to nm-manager.c
2016-01-18 14:04:56 +01:00
} G_STMT_END
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
manager: add logging macro _NMLOG3() for logging connection messages It unifies the way how we print the logging prefix, but also it passes the con_uuid down for structured logging.
2017-06-07 12:46:10 +02:00
#define _NMLOG3(level, domain, connection, ...) \
G_STMT_START { \
const NMLogLevel _level = (level); \
const NMLogDomain _domain = (domain); \
\
if (nm_logging_enabled (_level, _domain)) { \
const NMManager *const _self = (self); \
NMConnection *const _connection = (connection); \
const char *const _con_id = _nm_connection_get_id (_connection); \
char _sbuf[32]; \
\
_nm_log (_level, _domain, 0, \
NULL, _nm_connection_get_uuid (_connection), \
"%s%s: %s%s%s" _NM_UTILS_MACRO_FIRST (__VA_ARGS__), \
_NMLOG_PREFIX_NAME, \
((_self && _self != singleton_instance) \
? nm_sprintf_buf (_sbuf, "[%p]", _self) \
: ""), \
NM_PRINT_FMT_QUOTED (_con_id, "(", _con_id, ") ", "") \
_NM_UTILS_MACRO_REST (__VA_ARGS__)); \
} \
} G_STMT_END
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
static const NMDBusInterfaceInfoExtended interface_info_manager;
static const GDBusSignalInfo signal_info_check_permissions;
static const GDBusSignalInfo signal_info_state_changed;
static const GDBusSignalInfo signal_info_device_added;
static const GDBusSignalInfo signal_info_device_removed;
Update connectivity value on device removal When a device is removed (like when the user unplugs a usb network device) the device object is removed, so it doesn't emit a notify signal for a change in its connectivity and so, device_connectivity_changed is not called. This means that nobody updates the global connectivity value which is potentially wrong if the device was the one providing network connectivity. Since device_connectivity_changed's first two parameters aren't actually used and are there just for the signal to be able to be connected, I moved the code from device_connectivity_changed to a new update_connectivity_value function that just takes a NMManager parameter and also call it from remove_device. [thaller@redhat.com: fix coding style regarding whitespace] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/141 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/101
2019-03-21 11:32:32 +01:00
static void update_connectivity_value (NMManager *self);
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
static gboolean add_device (NMManager *self, NMDevice *device, GError **error);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
static void _emit_device_added_removed (NMManager *self,
NMDevice *device,
gboolean is_added);
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
static NMActiveConnection *_new_active_connection (NMManager *self,
manager: add is-vpn argument to _new_active_connection() and avoid searching existing activations - pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection() would re-determine whether a connection is a VPN type, although that was already established previously. The confusing part is: will they come to the same result? Why? What if not? Instead pass it as argument and assert that we got it right. - the check for existing connections should look whether there is an existing active connection of type NMVpnConnection. Instead, what matters is, - do we have a connection of type VPN (otherwise, don't even bother to search for existing-ac) - is the connection already active? Checking whether the connection is already active, and ask backwards whether it's of type NMVpnConnection is odd, maybe even wrong in some cases.
2018-04-12 11:32:18 +02:00
gboolean is_vpn,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
NMConnection *incompl_conn,
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
NMConnection *applied,
const char *specific_object,
NMDevice *device,
NMAuthSubject *subject,
NMActivationType activation_type,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
NMActivationReason activation_reason,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
NMActivationStateFlags initial_state_flags,
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
GError **error);
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
static void policy_activating_ac_changed (GObject *object, GParamSpec *pspec, gpointer user_data);
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
static gboolean find_master (NMManager *self,
NMConnection *connection,
NMDevice *device,
NMSettingsConnection **out_master_connection,
NMDevice **out_master_device,
NMActiveConnection **out_master_ac,
GError **error);
static void nm_manager_update_state (NMManager *manager);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
static void connection_changed (NMManager *self,
NMSettingsConnection *sett_conn);
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
static void device_sleep_cb (NMDevice *device,
GParamSpec *pspec,
NMManager *self);
static void settings_startup_complete_changed (NMSettings *settings,
GParamSpec *pspec,
NMManager *self);
static void retry_connections_for_parent_device (NMManager *self, NMDevice *device);
manager: allow slave connection to auto-connect its slaves Since connection.autoconnect-slaves was introduced, we only allowed it to autoactivate slaves for connections that were not slave themselves. It seems useful to remove such limitation, but we must prevent an infinite loop if there is a circular dependency between connections. https://bugzilla.redhat.com/show_bug.cgi?id=1360386
2016-09-26 16:01:27 +02:00
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
static void active_connection_state_changed (NMActiveConnection *active,
GParamSpec *pspec,
NMManager *self);
core: fix lag in NMManager:state moving to CONNECTED_GLOBAL Something changed at some point so that NMManager was now recomputing its state after a connection was activated, but before NMPolicy had decided whether to give that connection the default route, meaning NMManager would set the state to CONNECTED_LOCAL rather than CONNECTED_GLOBAL. Fix this by watching the active connection :default and :default6 properties too, so we do the right thing regardless of what order the AC properties change in.
2014-06-06 15:30:24 -04:00
static void active_connection_default_changed (NMActiveConnection *active,
GParamSpec *pspec,
NMManager *self);
manager: allow delaying the device activation when the parent is not real Don't try to realize our device when the parent device is not real. Instead, enqueue the activation and wait until it is active before realizing our device and progressing the device to DISCONNECTED so that it can get connected.
2016-03-24 15:20:44 +01:00
static void active_connection_parent_active (NMActiveConnection *active,
NMActiveConnection *parent_ac,
NMManager *self);
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
static NMActiveConnection *active_connection_find (NMManager *self,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
const char *uuid,
NMActiveConnectionState max_state,
GPtrArray **out_all_matching);
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
connectivity: emit properties-changed about connectivity settings
2018-04-10 15:55:16 +02:00
static NMConnectivity *concheck_get_mgr (NMManager *self);
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
static void _internal_activation_auth_done (NMManager *self,
NMActiveConnection *active,
gboolean success,
const char *error_desc);
static void _add_and_activate_auth_done (NMManager *self,
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
AsyncOpType async_op_type,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
NMActiveConnection *active,
NMConnection *connection,
GDBusMethodInvocation *invocation,
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
NMSettingsConnectionPersistMode persist_mode,
gboolean is_volatile,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
gboolean success,
const char *error_desc);
static void _activation_auth_done (NMManager *self,
NMActiveConnection *active,
GDBusMethodInvocation *invocation,
gboolean success,
const char *error_desc);
manager/trivial: reorder declarations at beginning of file First, define structs. Then forward declare functions. Reorder code to have a certain order that is also used by other files (or should be).
2017-12-05 12:35:38 +01:00
/*****************************************************************************/
static NM_CACHED_QUARK_FCN ("autoconnect-root", autoconnect_root_quark)
/*****************************************************************************/
manager: add _connection_is_vpn() helper to unify checks for VPN type
2018-04-12 11:19:06 +02:00
static gboolean
_connection_is_vpn (NMConnection *connection)
{
const char *type;
type = nm_connection_get_connection_type (connection);
if (type)
return nm_streq (type, NM_SETTING_VPN_SETTING_NAME);
/* we have an incomplete (invalid) connection at hand. That can only
* happen during AddAndActivate. Determine whether it's VPN type based
docs: misc. typos pt2 Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
2018-09-15 07:20:54 -04:00
* on the existence of a [vpn] section. */
manager: add _connection_is_vpn() helper to unify checks for VPN type
2018-04-12 11:19:06 +02:00
return !!nm_connection_get_setting_vpn (connection);
}
/*****************************************************************************/
connectivity: emit properties-changed about connectivity settings
2018-04-10 15:55:16 +02:00
static gboolean
concheck_enabled (NMManager *self, gboolean *out_changed)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
guint check_enabled;
check_enabled = nm_connectivity_check_enabled (concheck_get_mgr (self))
? 1 : 2;
if (priv->connectivity_check_enabled_last == check_enabled)
NM_SET_OUT (out_changed, FALSE);
else {
NM_SET_OUT (out_changed, TRUE);
priv->connectivity_check_enabled_last = check_enabled;
}
return check_enabled == 1;
}
connectivity: schedule connectivity timers per-device and probe for short outages It might happen, that connectivitiy is lost only for a moment and returns soon after. Based on that assumption, when we loose connectivity we want to have a probe interval where we check for returning connectivity more frequently. For that, we handle tracking of the timeouts per-device. The intervall shall start with 1 seconds, and double the interval time until the full interval is reached. Actually, due to the implementation, it's unlikely that we already perform the second check 1 second later. That is because commonly the first check returns before the one second timeout is reached and bumps the interval to 2 seconds right away. Also, we go through extra lengths so that manual connectivity check delay the periodic checks. By being more smart about that, we can reduce the number of connectivity checks, but still keeping the promise to check at least within the requested interval. The complexity of book keeping the timeouts is remarkable. But I think it is worth the effort and we should try hard to - have a connectivity state as accurate as possible. Clearly, connectivity checking means that we probing, so being more intelligent about timeout and backoff timers can result in a better connectivity state. The connectivity state is important because we use it for the default-route penaly and the GUI indicates bad connectivity. - be intelligent about avoiding redundant connectivity checks. While we want to check often to get an accurate connectivity state, we also want to minimize the number of HTTP requests, in case the connectivity is established and suppossedly stable. Also, perform connectivity checks in every state of the device. Even if a device is disconnected, it still might have connectivity, for example if the user externally adds an IP address on an unmanaged device. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-02-20 21:41:14 +01:00
static void
concheck_config_changed_cb (NMConnectivity *connectivity,
NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMDevice *device;
connectivity: emit properties-changed about connectivity settings
2018-04-10 15:55:16 +02:00
gboolean changed;
concheck_enabled (self, &changed);
if (changed)
_notify (self, PROP_CONNECTIVITY_CHECK_ENABLED);
connectivity: schedule connectivity timers per-device and probe for short outages It might happen, that connectivitiy is lost only for a moment and returns soon after. Based on that assumption, when we loose connectivity we want to have a probe interval where we check for returning connectivity more frequently. For that, we handle tracking of the timeouts per-device. The intervall shall start with 1 seconds, and double the interval time until the full interval is reached. Actually, due to the implementation, it's unlikely that we already perform the second check 1 second later. That is because commonly the first check returns before the one second timeout is reached and bumps the interval to 2 seconds right away. Also, we go through extra lengths so that manual connectivity check delay the periodic checks. By being more smart about that, we can reduce the number of connectivity checks, but still keeping the promise to check at least within the requested interval. The complexity of book keeping the timeouts is remarkable. But I think it is worth the effort and we should try hard to - have a connectivity state as accurate as possible. Clearly, connectivity checking means that we probing, so being more intelligent about timeout and backoff timers can result in a better connectivity state. The connectivity state is important because we use it for the default-route penaly and the GUI indicates bad connectivity. - be intelligent about avoiding redundant connectivity checks. While we want to check often to get an accurate connectivity state, we also want to minimize the number of HTTP requests, in case the connectivity is established and suppossedly stable. Also, perform connectivity checks in every state of the device. Even if a device is disconnected, it still might have connectivity, for example if the user externally adds an IP address on an unmanaged device. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-02-20 21:41:14 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst)
nm_device_check_connectivity_update_interval (device);
}
static NMConnectivity *
concheck_get_mgr (NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
if (G_UNLIKELY (!priv->concheck_mgr)) {
priv->concheck_mgr = g_object_ref (nm_connectivity_get ());
g_signal_connect (priv->concheck_mgr,
NM_CONNECTIVITY_CONFIG_CHANGED,
G_CALLBACK (concheck_config_changed_cb),
self);
}
return priv->concheck_mgr;
}
/*****************************************************************************/
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
static AsyncOpData *
_async_op_data_new_authorize_activate_internal (NMManager *self, NMActiveConnection *active_take)
{
AsyncOpData *async_op_data;
async_op_data = g_slice_new0 (AsyncOpData);
async_op_data->async_op_type = ASYNC_OP_TYPE_AC_AUTH_ACTIVATE_INTERNAL;
async_op_data->self = g_object_ref (self);
async_op_data->ac_auth.active = active_take;
c_list_link_tail (&NM_MANAGER_GET_PRIVATE (self)->async_op_lst_head, &async_op_data->async_op_lst);
return async_op_data;
}
static AsyncOpData *
_async_op_data_new_ac_auth_activate_user (NMManager *self,
NMActiveConnection *active_take,
GDBusMethodInvocation *invocation_take)
{
AsyncOpData *async_op_data;
async_op_data = g_slice_new0 (AsyncOpData);
async_op_data->async_op_type = ASYNC_OP_TYPE_AC_AUTH_ACTIVATE_USER;
async_op_data->self = g_object_ref (self);
async_op_data->ac_auth.active = active_take;
async_op_data->ac_auth.activate_user.invocation = invocation_take;
c_list_link_tail (&NM_MANAGER_GET_PRIVATE (self)->async_op_lst_head, &async_op_data->async_op_lst);
return async_op_data;
}
static AsyncOpData *
_async_op_data_new_ac_auth_add_and_activate (NMManager *self,
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
AsyncOpType async_op_type,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
NMActiveConnection *active_take,
GDBusMethodInvocation *invocation_take,
core: Add persist option to AddAndActivateConnection2 This option allows setting the rules for how long the connection should be stored. Valid values are "disk" (the default), "memory" and "volatile". If "memory" or "volatile" is selected, the connection will not be saved to disk and with "volatile" it will be automatically removed when it is deactivated again.
2018-10-25 16:54:37 +02:00
NMConnection *connection_take,
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
NMSettingsConnectionPersistMode persist_mode,
gboolean is_volatile)
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
{
AsyncOpData *async_op_data;
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
nm_assert (NM_IN_SET (async_op_type, ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE,
ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE2));
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
async_op_data = g_slice_new0 (AsyncOpData);
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
async_op_data->async_op_type = async_op_type;
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
async_op_data->self = g_object_ref (self);
async_op_data->ac_auth.active = active_take;
async_op_data->ac_auth.add_and_activate.invocation = invocation_take;
async_op_data->ac_auth.add_and_activate.connection = connection_take;
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
async_op_data->ac_auth.add_and_activate.persist_mode = persist_mode;
async_op_data->ac_auth.add_and_activate.is_volatile = is_volatile;
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
c_list_link_tail (&NM_MANAGER_GET_PRIVATE (self)->async_op_lst_head, &async_op_data->async_op_lst);
return async_op_data;
}
static void
_async_op_complete_ac_auth_cb (NMActiveConnection *active,
gboolean success,
const char *error_desc,
gpointer user_data)
{
AsyncOpData *async_op_data = user_data;
nm_assert (async_op_data);
nm_assert (NM_IS_MANAGER (async_op_data->self));
nm_assert (nm_c_list_contains_entry (&NM_MANAGER_GET_PRIVATE (async_op_data->self)->async_op_lst_head, async_op_data, async_op_lst));
nm_assert (NM_IS_ACTIVE_CONNECTION (active));
nm_assert (active == async_op_data->ac_auth.active);
c_list_unlink (&async_op_data->async_op_lst);
switch (async_op_data->async_op_type) {
case ASYNC_OP_TYPE_AC_AUTH_ACTIVATE_INTERNAL:
_internal_activation_auth_done (async_op_data->self,
async_op_data->ac_auth.active,
success,
error_desc);
break;
case ASYNC_OP_TYPE_AC_AUTH_ACTIVATE_USER:
_activation_auth_done (async_op_data->self,
async_op_data->ac_auth.active,
async_op_data->ac_auth.activate_user.invocation,
success,
error_desc);
break;
case ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE:
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
case ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE2:
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
_add_and_activate_auth_done (async_op_data->self,
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
async_op_data->async_op_type,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
async_op_data->ac_auth.active,
async_op_data->ac_auth.add_and_activate.connection,
async_op_data->ac_auth.add_and_activate.invocation,
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
async_op_data->ac_auth.add_and_activate.persist_mode,
async_op_data->ac_auth.add_and_activate.is_volatile,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
success,
error_desc);
g_object_unref (async_op_data->ac_auth.add_and_activate.connection);
break;
default:
nm_assert_not_reached ();
break;
}
g_object_unref (async_op_data->ac_auth.active);
g_object_unref (async_op_data->self);
g_slice_free (AsyncOpData, async_op_data);
}
/*****************************************************************************/
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
typedef struct {
int ifindex;
guint32 aspired_metric;
guint32 effective_metric;
} DeviceRouteMetricData;
static DeviceRouteMetricData *
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
_device_route_metric_data_new (int ifindex, guint32 aspired_metric, guint32 effective_metric)
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
{
DeviceRouteMetricData *data;
nm_assert (ifindex > 0);
/* For IPv4, metrics can use the entire uint32 bit range. For IPv6,
* zero is treated like 1024. Since we handle IPv4 and IPv6 identically,
* we cannot allow a zero metric here.
*/
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
nm_assert (aspired_metric > 0);
nm_assert (effective_metric == 0 || aspired_metric <= effective_metric);
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
data = g_slice_new0 (DeviceRouteMetricData);
data->ifindex = ifindex;
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
data->aspired_metric = aspired_metric;
data->effective_metric = effective_metric ?: aspired_metric;
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
return data;
}
static guint
_device_route_metric_data_by_ifindex_hash (gconstpointer p)
{
const DeviceRouteMetricData *data = p;
NMHashState h;
nm_hash_init (&h, 1030338191);
nm_hash_update_vals (&h, data->ifindex);
return nm_hash_complete (&h);
}
static gboolean
_device_route_metric_data_by_ifindex_equal (gconstpointer pa, gconstpointer pb)
{
const DeviceRouteMetricData *a = pa;
const DeviceRouteMetricData *b = pb;
return a->ifindex == b->ifindex;
}
static guint32
_device_route_metric_get (NMManager *self,
int ifindex,
NMDeviceType device_type,
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
gboolean lookup_only,
guint32 *out_aspired_metric)
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
{
NMManagerPrivate *priv;
const DeviceRouteMetricData *d2;
DeviceRouteMetricData *data;
DeviceRouteMetricData data_lookup;
const NMDedupMultiHeadEntry *all_links_head;
NMPObject links_needle;
guint n_links;
gboolean cleaned = FALSE;
GHashTableIter h_iter;
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
guint32 metric;
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
g_return_val_if_fail (NM_IS_MANAGER (self), 0);
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
NM_SET_OUT (out_aspired_metric, 0);
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
if (ifindex <= 0) {
if (lookup_only)
return 0;
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
metric = nm_device_get_route_metric_default (device_type);
NM_SET_OUT (out_aspired_metric, metric);
return metric;
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
}
priv = NM_MANAGER_GET_PRIVATE (self);
if ( lookup_only
&& !priv->device_route_metrics)
return 0;
if (G_UNLIKELY (!priv->device_route_metrics)) {
const GHashTable *h;
const NMConfigDeviceStateData *device_state;
priv->device_route_metrics = g_hash_table_new_full (_device_route_metric_data_by_ifindex_hash,
_device_route_metric_data_by_ifindex_equal,
NULL,
nm_g_slice_free_fcn (DeviceRouteMetricData));
cleaned = TRUE;
/* we need to pre-populate the cache for all (still existing) devices from the state-file */
h = nm_config_device_state_get_all (priv->config);
if (!h)
goto initited;
g_hash_table_iter_init (&h_iter, (GHashTable *) h);
while (g_hash_table_iter_next (&h_iter, NULL, (gpointer *) &device_state)) {
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
if (!device_state->route_metric_default_effective)
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
continue;
if (!nm_platform_link_get (priv->platform, device_state->ifindex)) {
/* we have the entry in the state file, but (currently) no such
* ifindex exists in platform. Most likely the entry is obsolete,
* hence we skip it. */
continue;
}
all: require glib 2.40 RHEL 7.1 and Ubuntu 14.04 LTS both have this. https://bugzilla.gnome.org/show_bug.cgi?id=792323
2018-01-02 15:47:37 +01:00
if (!g_hash_table_add (priv->device_route_metrics,
_device_route_metric_data_new (device_state->ifindex,
device_state->route_metric_default_aspired,
device_state->route_metric_default_effective)))
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
nm_assert_not_reached ();
}
}
initited:
data_lookup.ifindex = ifindex;
data = g_hash_table_lookup (priv->device_route_metrics, &data_lookup);
if (data)
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
goto out;
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
if (lookup_only)
return 0;
if (!cleaned) {
/* get the number of all links in the platform cache. */
all_links_head = nm_platform_lookup_all (priv->platform,
NMP_CACHE_ID_TYPE_OBJECT_TYPE,
nmp_object_stackinit_id_link (&links_needle, 1));
n_links = all_links_head ? all_links_head->len : 0;
/* on systems where a lot of devices are created and go away, the index contains
* a lot of stale entries. We must from time to time clean them up.
*
* Do do this cleanup, whenever we have more enties then 2 times the number of links. */
if (G_UNLIKELY (g_hash_table_size (priv->device_route_metrics) > NM_MAX (20, n_links * 2))) {
/* from time to time, we need to do some house-keeping and prune stale entries.
* Otherwise, on a system where interfaces frequently come and go (docker), we
* keep growing this cache for ifindexes that no longer exist. */
g_hash_table_iter_init (&h_iter, priv->device_route_metrics);
while (g_hash_table_iter_next (&h_iter, NULL, (gpointer *) &d2)) {
if (!nm_platform_link_get (priv->platform, d2->ifindex))
g_hash_table_iter_remove (&h_iter);
}
cleaned = TRUE;
}
}
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
data = _device_route_metric_data_new (ifindex, nm_device_get_route_metric_default (device_type), 0);
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
/* unfortunately, there is no stright forward way to lookup all reserved metrics.
* Note, that we don't only have to know which metrics are currently reserved,
* but also, which metrics are now seemingly un-used but caused another reserved
core: ensure that the default route-metric bumps at most 50 points First check that the limit of 50 metric points is not surpassed. Otherwise, if you have an ethernet device (aspired 100, effective 130) and a MACSec devic (aspired 125, effective 155), activating a new ethernet device would bump it's metric to 155 -- more then the 50 points limit. It doesn't matter too much, because the cases where the limit of 50 could have been surpassed were very specific. Still, change it to ensure that the limit is always honored as one would expect. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-19 10:10:15 +01:00
* metric to be bumped. Hence, the naive O(n^2) search :(
*
* Well, technically, since we limit bumping the metric to 50, this entire
* loop runs at most 50 times, so it's still O(n). Let's just say, it's not
* very efficient. */
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
again:
g_hash_table_iter_init (&h_iter, priv->device_route_metrics);
while (g_hash_table_iter_next (&h_iter, NULL, (gpointer *) &d2)) {
if ( data->effective_metric < d2->aspired_metric
|| data->effective_metric > d2->effective_metric) {
/* no overlap. Skip. */
continue;
}
if ( !cleaned
&& !nm_platform_link_get (priv->platform, d2->ifindex)) {
/* the metric seems taken, but there is no such interface. This entry
* is stale, forget about it. */
g_hash_table_iter_remove (&h_iter);
continue;
}
core: ensure that the default route-metric bumps at most 50 points First check that the limit of 50 metric points is not surpassed. Otherwise, if you have an ethernet device (aspired 100, effective 130) and a MACSec devic (aspired 125, effective 155), activating a new ethernet device would bump it's metric to 155 -- more then the 50 points limit. It doesn't matter too much, because the cases where the limit of 50 could have been surpassed were very specific. Still, change it to ensure that the limit is always honored as one would expect. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-19 10:10:15 +01:00
if (d2->effective_metric == G_MAXUINT32) {
/* we cannot bump the metric any further. Done.
*
* Actually, this can currently not happen because the aspired_metric
* are small numbers and we limit the bumping to 50. Still, for
* completeness... */
data->effective_metric = G_MAXUINT32;
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
break;
}
core: ensure that the default route-metric bumps at most 50 points First check that the limit of 50 metric points is not surpassed. Otherwise, if you have an ethernet device (aspired 100, effective 130) and a MACSec devic (aspired 125, effective 155), activating a new ethernet device would bump it's metric to 155 -- more then the 50 points limit. It doesn't matter too much, because the cases where the limit of 50 could have been surpassed were very specific. Still, change it to ensure that the limit is always honored as one would expect. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-19 10:10:15 +01:00
if (d2->effective_metric - data->aspired_metric >= 50) {
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
/* as one active interface reserves an entire range of metrics
* (from aspired_metric to effective_metric), that means if you
* alternatingly activate two interfaces, their metric will
core: ensure that the default route-metric bumps at most 50 points First check that the limit of 50 metric points is not surpassed. Otherwise, if you have an ethernet device (aspired 100, effective 130) and a MACSec devic (aspired 125, effective 155), activating a new ethernet device would bump it's metric to 155 -- more then the 50 points limit. It doesn't matter too much, because the cases where the limit of 50 could have been surpassed were very specific. Still, change it to ensure that the limit is always honored as one would expect. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-19 10:10:15 +01:00
* bump each other.
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
*
core: ensure that the default route-metric bumps at most 50 points First check that the limit of 50 metric points is not surpassed. Otherwise, if you have an ethernet device (aspired 100, effective 130) and a MACSec devic (aspired 125, effective 155), activating a new ethernet device would bump it's metric to 155 -- more then the 50 points limit. It doesn't matter too much, because the cases where the limit of 50 could have been surpassed were very specific. Still, change it to ensure that the limit is always honored as one would expect. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-19 10:10:15 +01:00
* Limit this, bump the metric at most 50 points. */
data->effective_metric = data->aspired_metric + 50;
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
break;
}
/* bump the metric, and search again. */
core: ensure that the default route-metric bumps at most 50 points First check that the limit of 50 metric points is not surpassed. Otherwise, if you have an ethernet device (aspired 100, effective 130) and a MACSec devic (aspired 125, effective 155), activating a new ethernet device would bump it's metric to 155 -- more then the 50 points limit. It doesn't matter too much, because the cases where the limit of 50 could have been surpassed were very specific. Still, change it to ensure that the limit is always honored as one would expect. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-19 10:10:15 +01:00
data->effective_metric = d2->effective_metric + 1;
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
goto again;
}
_LOGT (LOGD_DEVICE, "default-route-metric: ifindex %d reserves metric %u (aspired %u)",
data->ifindex, data->effective_metric, data->aspired_metric);
all: require glib 2.40 RHEL 7.1 and Ubuntu 14.04 LTS both have this. https://bugzilla.gnome.org/show_bug.cgi?id=792323
2018-01-02 15:47:37 +01:00
if (!g_hash_table_add (priv->device_route_metrics, data))
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
nm_assert_not_reached ();
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
out:
NM_SET_OUT (out_aspired_metric, data->aspired_metric);
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
return data->effective_metric;
}
guint32
nm_manager_device_route_metric_reserve (NMManager *self,
int ifindex,
NMDeviceType device_type)
{
guint32 metric;
core: persist aspired default route-metric in device's state file NMManager tries to assign unique route-metrics in an increasing manner so that the device which activates first keeps to have the best routes. This information is also persisted in the device's state file, however we not only need to persist the effective route-metric which was eventually chosen by NMManager, but also the aspired metric. The reason is that when a metric is chosen for a device, the entire range between aspired and effective route-metric is reserved for that device. We must remember the entire range so that after restart the entire range is still considered to be in use. Fixes: 6a32c64d8fb2a9c1cfb78ab7e2f0bb3a269c81d7
2017-12-20 12:45:02 +01:00
metric = _device_route_metric_get (self, ifindex, device_type, FALSE, NULL);
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
nm_assert (metric != 0);
return metric;
}
void
nm_manager_device_route_metric_clear (NMManager *self,
int ifindex)
{
NMManagerPrivate *priv;
DeviceRouteMetricData data_lookup;
priv = NM_MANAGER_GET_PRIVATE (self);
if (!priv->device_route_metrics)
return;
data_lookup.ifindex = ifindex;
if (g_hash_table_remove (priv->device_route_metrics, &data_lookup)) {
_LOGT (LOGD_DEVICE, "default-route-metric: ifindex %d released",
ifindex);
}
}
/*****************************************************************************/
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
static void
_delete_volatile_connection_do (NMManager *self,
NMSettingsConnection *connection)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
if (!NM_FLAGS_HAS (nm_settings_connection_get_flags (connection),
core/trivial: rename "NMSettingsConnectionFlags" to "NMSettingsConnectionIntFlags" "NMSettingsConnectionFlags" was an internal enum. Soon, we will add such a type in libnm. Avoid the naming conflict by renaming. The "Int" stands for "internal".
2018-04-05 20:02:45 +02:00
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE))
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
return;
settings: reorder checks in _delete_volatile_connection_do() to perform cheaper check first Checking whether a settings connection is still tracked is a simple c_list_is_empty(). It's faster, so do it first.
2019-06-20 17:14:30 +02:00
if (!nm_settings_has_connection (priv->settings, connection))
return;
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
if (active_connection_find (self,
connection,
NULL,
NM_ACTIVE_CONNECTION_STATE_DEACTIVATED,
NULL))
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
return;
_LOGD (LOGD_DEVICE, "volatile connection disconnected. Deleting connection '%s' (%s)",
nm_settings_connection_get_id (connection), nm_settings_connection_get_uuid (connection));
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
nm_settings_connection_delete (connection, FALSE);
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
}
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
/* Returns: whether to notify D-Bus of the removal or not */
static gboolean
active_connection_remove (NMManager *self, NMActiveConnection *active)
core: fix handling of ActiveConnections on Policy dispose() The manager has already disposed of the ActiveConnections by the time the Policy is disposed, but the manager wasn't clearing the active_connections list, so the Policy got a stale list of freed objects. Next, the manager wasn't always emitting ACTIVE_CONNECTION_REMOVED when disposing of ActiveConnections, which the Policy listens to for cleanup. This lead to warnings on shutdown when the Policy attempted to clean up for already disposed objects Fix all this by ensuring the Manager signals when removing ActiveConnections, which the Policy then uses to clean up it's stuff, and ensuring the manager properly cleans up its ActiveConnection list.
2013-08-30 17:57:56 -05:00
{
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
gs_unref_object NMSettingsConnection *connection = NULL;
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
gboolean notify;
core: clean up nm-generated-assumed connections when assumption fails or connection disconnects https://bugzilla.gnome.org/show_bug.cgi?id=731937 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-20 20:13:14 +02:00
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
nm_assert (NM_IS_ACTIVE_CONNECTION (active));
nm_assert (c_list_contains (&priv->active_connections_lst_head, &active->active_connections_lst));
core: clean up nm-generated-assumed connections when assumption fails or connection disconnects https://bugzilla.gnome.org/show_bug.cgi?id=731937 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-20 20:13:14 +02:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
notify = nm_dbus_object_is_exported (NM_DBUS_OBJECT (active));
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
c-list: re-import latest version of c-list.h from upstream Most notably, it renames c_list_unlink_init() -> c_list_unlink() c_list_unlink() -> c_list_unlink_stale() $ sed -e 's/\<c_list_unlink\>/c_list_unlink_old/g' \ -e 's/\<c_list_unlink_init\>/c_list_unlink/g' \ -e 's/\<c_list_unlink_old\>/c_list_unlink_stale/g' \ $(git grep -l c_list_unlink -- ':(exclude)shared/nm-utils/c-list.h') \ -i
2017-11-28 11:22:01 +01:00
c_list_unlink (&active->active_connections_lst);
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
g_signal_emit (self, signals[ACTIVE_CONNECTION_REMOVED], 0, active);
g_signal_handlers_disconnect_by_func (active, active_connection_state_changed, self);
g_signal_handlers_disconnect_by_func (active, active_connection_default_changed, self);
g_signal_handlers_disconnect_by_func (active, active_connection_parent_active, self);
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
connection = nm_g_object_ref (nm_active_connection_get_settings_connection (active));
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_dbus_object_clear_and_unexport (&active);
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
if (connection)
_delete_volatile_connection_do (self, connection);
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
return notify;
core: fix handling of ActiveConnections on Policy dispose() The manager has already disposed of the ActiveConnections by the time the Policy is disposed, but the manager wasn't clearing the active_connections list, so the Policy got a stale list of freed objects. Next, the manager wasn't always emitting ACTIVE_CONNECTION_REMOVED when disposing of ActiveConnections, which the Policy listens to for cleanup. This lead to warnings on shutdown when the Policy attempted to clean up for already disposed objects Fix all this by ensuring the Manager signals when removing ActiveConnections, which the Policy then uses to clean up it's stuff, and ensuring the manager properly cleans up its ActiveConnection list.
2013-08-30 17:57:56 -05:00
}
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
static gboolean
_active_connection_cleanup (gpointer user_data)
{
NMManager *self = NM_MANAGER (user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
NMActiveConnection *ac, *ac_safe;
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
priv->ac_cleanup_id = 0;
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
g_object_freeze_notify (G_OBJECT (self));
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
c_list_for_each_entry_safe (ac, ac_safe, &priv->active_connections_lst_head, active_connections_lst) {
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
if (nm_active_connection_get_state (ac) == NM_ACTIVE_CONNECTION_STATE_DEACTIVATED) {
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
if (active_connection_remove (self, ac))
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
_notify (self, PROP_ACTIVE_CONNECTIONS);
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
}
}
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
g_object_thaw_notify (G_OBJECT (self));
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
return FALSE;
}
static void
active_connection_state_changed (NMActiveConnection *active,
GParamSpec *pspec,
NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMActiveConnectionState state;
manager: allow slave connection to auto-connect its slaves Since connection.autoconnect-slaves was introduced, we only allowed it to autoactivate slaves for connections that were not slave themselves. It seems useful to remove such limitation, but we must prevent an infinite loop if there is a circular dependency between connections. https://bugzilla.redhat.com/show_bug.cgi?id=1360386
2016-09-26 16:01:27 +02:00
NMSettingsConnection *con;
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
state = nm_active_connection_get_state (active);
if (state == NM_ACTIVE_CONNECTION_STATE_DEACTIVATED) {
/* Destroy active connections from an idle handler to ensure that
* their last property change notifications go out, which wouldn't
* happen if we destroyed them immediately when their state was set
* to DEACTIVATED.
*/
if (!priv->ac_cleanup_id)
priv->ac_cleanup_id = g_idle_add (_active_connection_cleanup, self);
manager: allow slave connection to auto-connect its slaves Since connection.autoconnect-slaves was introduced, we only allowed it to autoactivate slaves for connections that were not slave themselves. It seems useful to remove such limitation, but we must prevent an infinite loop if there is a circular dependency between connections. https://bugzilla.redhat.com/show_bug.cgi?id=1360386
2016-09-26 16:01:27 +02:00
con = nm_active_connection_get_settings_connection (active);
if (con)
g_object_set_qdata (G_OBJECT (con), autoconnect_root_quark (), NULL);
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
}
core: NMManager:state fixes for assumed connections, etc 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.
2013-11-08 12:23:43 -05:00
nm_manager_update_state (self);
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
}
core: fix lag in NMManager:state moving to CONNECTED_GLOBAL Something changed at some point so that NMManager was now recomputing its state after a connection was activated, but before NMPolicy had decided whether to give that connection the default route, meaning NMManager would set the state to CONNECTED_LOCAL rather than CONNECTED_GLOBAL. Fix this by watching the active connection :default and :default6 properties too, so we do the right thing regardless of what order the AC properties change in.
2014-06-06 15:30:24 -04:00
static void
active_connection_default_changed (NMActiveConnection *active,
GParamSpec *pspec,
NMManager *self)
{
nm_manager_update_state (self);
}
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
/**
* active_connection_add():
* @self: the #NMManager
* @active: the #NMActiveConnection to manage
*
* Begins to track and manage @active. Increases the refcount of @active.
*/
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
static void
manager: reorder adding active-connection and queueing activation Note how recheck_assume_connection() called: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); active_connection_add (self, active); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); That differs from the order during _internal_activate_generic(), where we would end up with: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); active_connection_add (self, active); It makes more sense to me to *first* add the connection, and only then starting the activation with nm_device_queue_activation(). Also, let active_connection_add() always export the new active connection object, if it is not already exported. All callers of active_connection_add() ensured that the new object is already exported.
2018-02-05 15:17:06 +01:00
active_connection_add (NMManager *self,
NMActiveConnection *active)
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
nm_assert (NM_IS_ACTIVE_CONNECTION (active));
nm_assert (!c_list_is_linked (&active->active_connections_lst));
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
c_list_link_front (&priv->active_connections_lst_head, &active->active_connections_lst);
g_object_ref (active);
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
g_signal_connect (active,
"notify::" NM_ACTIVE_CONNECTION_STATE,
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
G_CALLBACK (active_connection_state_changed),
self);
core: fix lag in NMManager:state moving to CONNECTED_GLOBAL Something changed at some point so that NMManager was now recomputing its state after a connection was activated, but before NMPolicy had decided whether to give that connection the default route, meaning NMManager would set the state to CONNECTED_LOCAL rather than CONNECTED_GLOBAL. Fix this by watching the active connection :default and :default6 properties too, so we do the right thing regardless of what order the AC properties change in.
2014-06-06 15:30:24 -04:00
g_signal_connect (active,
"notify::" NM_ACTIVE_CONNECTION_DEFAULT,
G_CALLBACK (active_connection_default_changed),
self);
g_signal_connect (active,
"notify::" NM_ACTIVE_CONNECTION_DEFAULT6,
G_CALLBACK (active_connection_default_changed),
self);
core: add manager active connection added/removed signals 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.
2012-08-22 18:33:17 -05:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
if (!nm_dbus_object_is_exported (NM_DBUS_OBJECT (active)))
nm_dbus_object_export (NM_DBUS_OBJECT (active));
manager: reorder adding active-connection and queueing activation Note how recheck_assume_connection() called: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); active_connection_add (self, active); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); That differs from the order during _internal_activate_generic(), where we would end up with: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); active_connection_add (self, active); It makes more sense to me to *first* add the connection, and only then starting the activation with nm_device_queue_activation(). Also, let active_connection_add() always export the new active connection object, if it is not already exported. All callers of active_connection_add() ensured that the new object is already exported.
2018-02-05 15:17:06 +01:00
core: add manager active connection added/removed signals 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.
2012-08-22 18:33:17 -05:00
g_signal_emit (self, signals[ACTIVE_CONNECTION_ADDED], 0, active);
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
manager: reorder adding active-connection and queueing activation Note how recheck_assume_connection() called: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); active_connection_add (self, active); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); That differs from the order during _internal_activate_generic(), where we would end up with: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); active_connection_add (self, active); It makes more sense to me to *first* add the connection, and only then starting the activation with nm_device_queue_activation(). Also, let active_connection_add() always export the new active connection object, if it is not already exported. All callers of active_connection_add() ensured that the new object is already exported.
2018-02-05 15:17:06 +01:00
_notify (self, PROP_ACTIVE_CONNECTIONS);
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
}
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
const CList *
vpn: kill nm_vpn_manager_get_active_connections() No longer needed now that the manager tracks active connections.
2012-08-22 17:21:56 -05:00
nm_manager_get_active_connections (NMManager *manager)
{
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
return &NM_MANAGER_GET_PRIVATE (manager)->active_connections_lst_head;
vpn: kill nm_vpn_manager_get_active_connections() No longer needed now that the manager tracks active connections.
2012-08-22 17:21:56 -05:00
}
core: don't allow activating the same connection twice (rh #997998) Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
2013-09-12 10:28:21 -04:00
static NMActiveConnection *
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
active_connection_find (NMManager *self,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
const char *uuid,
core: don't consider deactivating active-connection when checking for concurrent activations At various places we check whether we have an active-connection already. For example, when activating a new connection in _internal_activate_device(), we might want to "nm_device_steal_connection()" if the same profile is already active. However, the max-state argument was not accurate in several cases. For the purpose of finding concurrent activations, we don't care about active-connections that are already in state DEACTIVATING. Only those that are ACTIVATED or before.
2018-04-19 15:42:27 +02:00
NMActiveConnectionState max_state /* candidates in state @max_state will be found */,
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
GPtrArray **out_all_matching)
core: don't allow activating the same connection twice (rh #997998) Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
2013-09-12 10:28:21 -04:00
{
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMActiveConnection *ac;
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
NMActiveConnection *best_ac = NULL;
GPtrArray *all = NULL;
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_assert (!sett_conn || NM_IS_SETTINGS_CONNECTION (sett_conn));
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
nm_assert (!out_all_matching || !*out_all_matching);
core: don't allow activating the same connection twice (rh #997998) Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
2013-09-12 10:28:21 -04:00
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
c_list_for_each_entry (ac, &priv->active_connections_lst_head, active_connections_lst) {
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *ac_conn;
core: don't allow activating the same connection twice (rh #997998) Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
2013-09-12 10:28:21 -04:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
ac_conn = nm_active_connection_get_settings_connection (ac);
if ( sett_conn
&& sett_conn != ac_conn)
manager: cleanup find_ac_for_connection() in "nm-manager.c" - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
2017-03-13 14:01:47 +01:00
continue;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if ( uuid
&& !nm_streq0 (uuid, nm_settings_connection_get_uuid (ac_conn)))
manager: cleanup find_ac_for_connection() in "nm-manager.c" - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
2017-03-13 14:01:47 +01:00
continue;
if (nm_active_connection_get_state (ac) > max_state)
continue;
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
if (!out_all_matching)
return ac;
if (!best_ac) {
best_ac = ac;
continue;
}
if (!all) {
all = g_ptr_array_new_with_free_func (g_object_unref);
g_ptr_array_add (all, g_object_ref (best_ac));
}
g_ptr_array_add (all, g_object_ref (ac));
core: don't allow activating the same connection twice (rh #997998) Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
2013-09-12 10:28:21 -04:00
}
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
if (!best_ac)
return NULL;
/* as an optimization, we only allocate out_all_matching, if there are more
* than one result. If there is only one result, we only return the single
* element and don't bother allocating an array. That's the common case.
*
* Also, in case we have multiple results, we return the *first* one
* as @best_ac. */
nm_assert ( !all
|| ( all->len >= 2
&& all->pdata[0] == best_ac));
*out_all_matching = all;
return best_ac;
core: don't allow activating the same connection twice (rh #997998) Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
2013-09-12 10:28:21 -04:00
}
manager: cleanup find_ac_for_connection() in "nm-manager.c" - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
2017-03-13 14:01:47 +01:00
static NMActiveConnection *
manager: minor refactoring of active_connection_find_by_connection() active_connection_find_by_connection() (or how it was called previously) is a simpler wrapper around active_connection_find(), which accepts a NMConnection argument, that may or may not be a NMSettingsConnection. It always passed NM_ACTIVE_CONNECTION_STATE_DEACTIVATING as max_state, and I think that one of the two callers don't should do that. A later commit will change that. So, we also want to pass @max_state as argument to active_connection_find_by_connection(). At that point, make active_connection_find_by_connection() identical to active_connection_find(), with the only exception, that it accepts a NMConnection and does automatically do the right thing (either lookup by pointer equality or by uuid).
2018-04-22 12:50:42 +02:00
active_connection_find_by_connection (NMManager *self,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
manager: minor refactoring of active_connection_find_by_connection() active_connection_find_by_connection() (or how it was called previously) is a simpler wrapper around active_connection_find(), which accepts a NMConnection argument, that may or may not be a NMSettingsConnection. It always passed NM_ACTIVE_CONNECTION_STATE_DEACTIVATING as max_state, and I think that one of the two callers don't should do that. A later commit will change that. So, we also want to pass @max_state as argument to active_connection_find_by_connection(). At that point, make active_connection_find_by_connection() identical to active_connection_find(), with the only exception, that it accepts a NMConnection and does automatically do the right thing (either lookup by pointer equality or by uuid).
2018-04-22 12:50:42 +02:00
NMConnection *connection,
NMActiveConnectionState max_state,
GPtrArray **out_all_matching)
manager: cleanup find_ac_for_connection() in "nm-manager.c" - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
2017-03-13 14:01:47 +01:00
{
nm_assert (NM_IS_MANAGER (self));
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_assert (!sett_conn || NM_IS_SETTINGS_CONNECTION (sett_conn));
nm_assert (!connection || NM_IS_CONNECTION (connection));
nm_assert (sett_conn || connection);
nm_assert (!connection || !sett_conn || connection == nm_settings_connection_get_connection (sett_conn));
manager: cleanup find_ac_for_connection() in "nm-manager.c" - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
2017-03-13 14:01:47 +01:00
/* Depending on whether connection is a settings connection,
* either lookup by object-identity of @connection, or compare the UUID */
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
return active_connection_find (self,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn,
sett_conn ? NULL : nm_connection_get_uuid (connection),
manager: minor refactoring of active_connection_find_by_connection() active_connection_find_by_connection() (or how it was called previously) is a simpler wrapper around active_connection_find(), which accepts a NMConnection argument, that may or may not be a NMSettingsConnection. It always passed NM_ACTIVE_CONNECTION_STATE_DEACTIVATING as max_state, and I think that one of the two callers don't should do that. A later commit will change that. So, we also want to pass @max_state as argument to active_connection_find_by_connection(). At that point, make active_connection_find_by_connection() identical to active_connection_find(), with the only exception, that it accepts a NMConnection and does automatically do the right thing (either lookup by pointer equality or by uuid).
2018-04-22 12:50:42 +02:00
max_state,
out_all_matching);
manager: cleanup find_ac_for_connection() in "nm-manager.c" - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
2017-03-13 14:01:47 +01:00
}
core: extend nm_manager_get_activatable_connections() for autoconnect and multi-connect In general, a activatable connection is one that is currently not active, or supports to be activatable multiple times according to multi-connect setting. In addition, during autoconnect, a profile which is marked as multi-connect=manual-multiple will not be avalable. Hence, add an argument "for_auto_activation". The code is mostly unused but will be used next (except for connections, which set connection.multi-connect=multiple).
2018-06-27 14:20:57 +02:00
typedef struct {
NMManager *self;
gboolean for_auto_activation;
} GetActivatableConnectionsFilterData;
core: refactor nm_manager_get_activatable_connections() to return an array ... instead of a GSList.
2017-02-03 15:13:03 +01:00
static gboolean
_get_activatable_connections_filter (NMSettings *settings,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
core: refactor nm_manager_get_activatable_connections() to return an array ... instead of a GSList.
2017-02-03 15:13:03 +01:00
gpointer user_data)
{
core: extend nm_manager_get_activatable_connections() for autoconnect and multi-connect In general, a activatable connection is one that is currently not active, or supports to be activatable multiple times according to multi-connect setting. In addition, during autoconnect, a profile which is marked as multi-connect=manual-multiple will not be avalable. Hence, add an argument "for_auto_activation". The code is mostly unused but will be used next (except for connections, which set connection.multi-connect=multiple).
2018-06-27 14:20:57 +02:00
const GetActivatableConnectionsFilterData *d = user_data;
NMConnectionMultiConnect multi_connect;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (NM_FLAGS_HAS (nm_settings_connection_get_flags (sett_conn),
core/trivial: rename "NMSettingsConnectionFlags" to "NMSettingsConnectionIntFlags" "NMSettingsConnectionFlags" was an internal enum. Soon, we will add such a type in libnm. Avoid the naming conflict by renaming. The "Int" stands for "internal".
2018-04-05 20:02:45 +02:00
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE))
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
return FALSE;
core: don't consider deactivating active-connection when checking for concurrent activations At various places we check whether we have an active-connection already. For example, when activating a new connection in _internal_activate_device(), we might want to "nm_device_steal_connection()" if the same profile is already active. However, the max-state argument was not accurate in several cases. For the purpose of finding concurrent activations, we don't care about active-connections that are already in state DEACTIVATING. Only those that are ACTIVATED or before.
2018-04-19 15:42:27 +02:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
multi_connect = _nm_connection_get_multi_connect (nm_settings_connection_get_connection (sett_conn));
core: extend nm_manager_get_activatable_connections() for autoconnect and multi-connect In general, a activatable connection is one that is currently not active, or supports to be activatable multiple times according to multi-connect setting. In addition, during autoconnect, a profile which is marked as multi-connect=manual-multiple will not be avalable. Hence, add an argument "for_auto_activation". The code is mostly unused but will be used next (except for connections, which set connection.multi-connect=multiple).
2018-06-27 14:20:57 +02:00
if ( multi_connect == NM_CONNECTION_MULTI_CONNECT_MULTIPLE
|| ( multi_connect == NM_CONNECTION_MULTI_CONNECT_MANUAL_MULTIPLE
&& !d->for_auto_activation))
return TRUE;
core: don't consider deactivating active-connection when checking for concurrent activations At various places we check whether we have an active-connection already. For example, when activating a new connection in _internal_activate_device(), we might want to "nm_device_steal_connection()" if the same profile is already active. However, the max-state argument was not accurate in several cases. For the purpose of finding concurrent activations, we don't care about active-connections that are already in state DEACTIVATING. Only those that are ACTIVATED or before.
2018-04-19 15:42:27 +02:00
/* the connection is activatable, if it has no active-connections that are in state
* activated, activating, or waiting to be activated. */
core: extend nm_manager_get_activatable_connections() for autoconnect and multi-connect In general, a activatable connection is one that is currently not active, or supports to be activatable multiple times according to multi-connect setting. In addition, during autoconnect, a profile which is marked as multi-connect=manual-multiple will not be avalable. Hence, add an argument "for_auto_activation". The code is mostly unused but will be used next (except for connections, which set connection.multi-connect=multiple).
2018-06-27 14:20:57 +02:00
return !active_connection_find (d->self,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn,
core: extend nm_manager_get_activatable_connections() for autoconnect and multi-connect In general, a activatable connection is one that is currently not active, or supports to be activatable multiple times according to multi-connect setting. In addition, during autoconnect, a profile which is marked as multi-connect=manual-multiple will not be avalable. Hence, add an argument "for_auto_activation". The code is mostly unused but will be used next (except for connections, which set connection.multi-connect=multiple).
2018-06-27 14:20:57 +02:00
NULL,
NM_ACTIVE_CONNECTION_STATE_ACTIVATED,
NULL);
core: refactor nm_manager_get_activatable_connections() to return an array ... instead of a GSList.
2017-02-03 15:13:03 +01:00
}
NMSettingsConnection **
core: extend nm_manager_get_activatable_connections() for autoconnect and multi-connect In general, a activatable connection is one that is currently not active, or supports to be activatable multiple times according to multi-connect setting. In addition, during autoconnect, a profile which is marked as multi-connect=manual-multiple will not be avalable. Hence, add an argument "for_auto_activation". The code is mostly unused but will be used next (except for connections, which set connection.multi-connect=multiple).
2018-06-27 14:20:57 +02:00
nm_manager_get_activatable_connections (NMManager *manager,
gboolean for_auto_activation,
gboolean sort,
guint *out_len)
core: don't allow activating the same connection twice (rh #997998) Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
2013-09-12 10:28:21 -04:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (manager);
core: extend nm_manager_get_activatable_connections() for autoconnect and multi-connect In general, a activatable connection is one that is currently not active, or supports to be activatable multiple times according to multi-connect setting. In addition, during autoconnect, a profile which is marked as multi-connect=manual-multiple will not be avalable. Hence, add an argument "for_auto_activation". The code is mostly unused but will be used next (except for connections, which set connection.multi-connect=multiple).
2018-06-27 14:20:57 +02:00
const GetActivatableConnectionsFilterData d = {
.self = manager,
.for_auto_activation = for_auto_activation,
};
core: don't allow activating the same connection twice (rh #997998) Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
2013-09-12 10:28:21 -04:00
core: merge nm_settings_get_connections_sorted() with nm_settings_get_connections_clone()
2017-11-22 12:46:58 +01:00
return nm_settings_get_connections_clone (priv->settings, out_len,
_get_activatable_connections_filter,
core: extend nm_manager_get_activatable_connections() for autoconnect and multi-connect In general, a activatable connection is one that is currently not active, or supports to be activatable multiple times according to multi-connect setting. In addition, during autoconnect, a profile which is marked as multi-connect=manual-multiple will not be avalable. Hence, add an argument "for_auto_activation". The code is mostly unused but will be used next (except for connections, which set connection.multi-connect=multiple).
2018-06-27 14:20:57 +02:00
(gpointer) &d,
core: merge nm_settings_get_connections_sorted() with nm_settings_get_connections_clone()
2017-11-22 12:46:58 +01:00
sort ? nm_settings_connection_cmp_autoconnect_priority_p_with_data : NULL,
NULL);
core: don't allow activating the same connection twice (rh #997998) Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
2013-09-12 10:28:21 -04:00
}
core: simplify looking up NMActiveConnection objects by object path
2012-09-14 15:21:29 -05:00
static NMActiveConnection *
core: rework lookup for exported objects by path to use index We already track an index of exported objects in NMDBusManager. Actually, that index was unused previously. We either could drop it, or use it. Let's use it.
2018-03-23 21:49:41 +01:00
active_connection_get_by_path (NMManager *self, const char *path)
core: simplify looking up NMActiveConnection objects by object path
2012-09-14 15:21:29 -05:00
{
core: rework lookup for exported objects by path to use index We already track an index of exported objects in NMDBusManager. Actually, that index was unused previously. We either could drop it, or use it. Let's use it.
2018-03-23 21:49:41 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
NMActiveConnection *ac;
core: simplify looking up NMActiveConnection objects by object path
2012-09-14 15:21:29 -05:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
ac = nm_dbus_manager_lookup_object (nm_dbus_object_get_manager (NM_DBUS_OBJECT (self)),
path);
core: rework lookup for exported objects by path to use index We already track an index of exported objects in NMDBusManager. Actually, that index was unused previously. We either could drop it, or use it. Let's use it.
2018-03-23 21:49:41 +01:00
if ( !ac
|| !NM_IS_ACTIVE_CONNECTION (ac)
|| c_list_is_empty (&ac->active_connections_lst))
return NULL;
core: simplify looking up NMActiveConnection objects by object path
2012-09-14 15:21:29 -05:00
core: rework lookup for exported objects by path to use index We already track an index of exported objects in NMDBusManager. Actually, that index was unused previously. We either could drop it, or use it. Let's use it.
2018-03-23 21:49:41 +01:00
nm_assert (c_list_contains (&priv->active_connections_lst_head, &ac->active_connections_lst));
return ac;
core: simplify looking up NMActiveConnection objects by object path
2012-09-14 15:21:29 -05:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
static void
config: use flags argument in config-changed signal instead of a hash table
2015-01-21 12:58:32 +01:00
_config_changed_cb (NMConfig *config, NMConfigData *config_data, NMConfigChangeFlags changes, NMConfigData *old_data, NMManager *self)
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
{
connectivity: emit properties-changed about connectivity settings
2018-04-10 15:55:16 +02:00
g_object_freeze_notify (G_OBJECT (self));
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
if (NM_FLAGS_HAS (changes, NM_CONFIG_CHANGE_GLOBAL_DNS_CONFIG))
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
_notify (self, PROP_GLOBAL_DNS_CONFIGURATION);
libnm,core: Add ConnectivityCheckUri property and accessors So that applications like GNOME Shell can hit the same URI to show the captive portal login page. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/209
2019-07-22 15:55:15 +01:00
if (!nm_streq0 (nm_config_data_get_connectivity_uri (config_data),
nm_config_data_get_connectivity_uri (old_data))) {
if ((!nm_config_data_get_connectivity_uri (config_data)) != (!nm_config_data_get_connectivity_uri (old_data)))
_notify (self, PROP_CONNECTIVITY_CHECK_AVAILABLE);
_notify (self, PROP_CONNECTIVITY_CHECK_URI);
}
connectivity: emit properties-changed about connectivity settings
2018-04-10 15:55:16 +02:00
g_object_thaw_notify (G_OBJECT (self));
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
}
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
static void
_reload_auth_cb (NMAuthChain *chain,
GDBusMethodInvocation *context,
gpointer user_data)
{
NMManager *self = NM_MANAGER (user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
GError *ret_error = NULL;
NMAuthCallResult result;
guint32 flags;
NMAuthSubject *subject;
char s_buf[60];
config,dns: support Reload flags to specify that only parts should be reloaded Support 3 new flags for Reload: - 0x01 (CONF): reload the configuration from disk - 0x02 (DNS_RC): write DNS configuration to resolv.conf - 0x04 (DNS_FULL): restart DNS plugin Omitting all flags is the same as reloading everything, thus SIGHUP.
2016-05-30 16:43:39 +02:00
NMConfigChangeFlags reload_type = NM_CONFIG_CHANGE_NONE;
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
nm_assert (G_IS_DBUS_METHOD_INVOCATION (context));
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_unlink (nm_auth_chain_parent_lst_list (chain));
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
flags = GPOINTER_TO_UINT (nm_auth_chain_get_data (chain, "flags"));
subject = nm_auth_chain_get_subject (chain);
result = nm_auth_chain_get_result (chain, NM_AUTH_PERMISSION_RELOAD);
core: remove unused error argument from NMAuthChainResultFunc NMAuthChain usually requests several permissions at once. Hence, an error argument in the overall callback does not make sense, because you wouldn't know which request failed. If at all, it could only mean that the overall request failed (like an D-Bus failure communicating to D-Bus *for all permisssions*), but we don't need to handle that specially. In fact, we don't really care why permission was not granted, whether it's due to an error or legitimate reasons. The error in the callback was always set to %NULL. Remove it.
2019-05-04 09:37:54 +02:00
if (result != NM_AUTH_CALL_RESULT_YES) {
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
ret_error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
"Not authorized to reload configuration");
config,dns: support Reload flags to specify that only parts should be reloaded Support 3 new flags for Reload: - 0x01 (CONF): reload the configuration from disk - 0x02 (DNS_RC): write DNS configuration to resolv.conf - 0x04 (DNS_FULL): restart DNS plugin Omitting all flags is the same as reloading everything, thus SIGHUP.
2016-05-30 16:43:39 +02:00
} else {
libnm: export reload flags Flags to the manager Reload() method are stable API but not exposed in a public header. Export them.
2019-09-05 14:54:22 +02:00
if (NM_FLAGS_ANY (flags, ~NM_MANAGER_RELOAD_FLAG_ALL)) {
config,dns: support Reload flags to specify that only parts should be reloaded Support 3 new flags for Reload: - 0x01 (CONF): reload the configuration from disk - 0x02 (DNS_RC): write DNS configuration to resolv.conf - 0x04 (DNS_FULL): restart DNS plugin Omitting all flags is the same as reloading everything, thus SIGHUP.
2016-05-30 16:43:39 +02:00
/* invalid flags */
} else if (flags == 0)
reload_type = NM_CONFIG_CHANGE_CAUSE_SIGHUP;
else {
libnm: export reload flags Flags to the manager Reload() method are stable API but not exposed in a public header. Export them.
2019-09-05 14:54:22 +02:00
if (NM_FLAGS_HAS (flags, NM_MANAGER_RELOAD_FLAG_CONF))
config,dns: support Reload flags to specify that only parts should be reloaded Support 3 new flags for Reload: - 0x01 (CONF): reload the configuration from disk - 0x02 (DNS_RC): write DNS configuration to resolv.conf - 0x04 (DNS_FULL): restart DNS plugin Omitting all flags is the same as reloading everything, thus SIGHUP.
2016-05-30 16:43:39 +02:00
reload_type |= NM_CONFIG_CHANGE_CAUSE_CONF;
libnm: export reload flags Flags to the manager Reload() method are stable API but not exposed in a public header. Export them.
2019-09-05 14:54:22 +02:00
if (NM_FLAGS_HAS (flags, NM_MANAGER_RELOAD_FLAG_DNS_RC))
config,dns: support Reload flags to specify that only parts should be reloaded Support 3 new flags for Reload: - 0x01 (CONF): reload the configuration from disk - 0x02 (DNS_RC): write DNS configuration to resolv.conf - 0x04 (DNS_FULL): restart DNS plugin Omitting all flags is the same as reloading everything, thus SIGHUP.
2016-05-30 16:43:39 +02:00
reload_type |= NM_CONFIG_CHANGE_CAUSE_DNS_RC;
libnm: export reload flags Flags to the manager Reload() method are stable API but not exposed in a public header. Export them.
2019-09-05 14:54:22 +02:00
if (NM_FLAGS_HAS (flags, NM_MANAGER_RELOAD_FLAG_DNS_FULL))
config,dns: support Reload flags to specify that only parts should be reloaded Support 3 new flags for Reload: - 0x01 (CONF): reload the configuration from disk - 0x02 (DNS_RC): write DNS configuration to resolv.conf - 0x04 (DNS_FULL): restart DNS plugin Omitting all flags is the same as reloading everything, thus SIGHUP.
2016-05-30 16:43:39 +02:00
reload_type |= NM_CONFIG_CHANGE_CAUSE_DNS_FULL;
}
if (reload_type == NM_CONFIG_CHANGE_NONE) {
ret_error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_INVALID_ARGUMENTS,
"Invalid flags for reload");
}
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
}
nm_audit_log_control_op (NM_AUDIT_OP_RELOAD,
nm_sprintf_buf (s_buf, "%u", flags),
ret_error == NULL, subject,
ret_error ? ret_error->message : NULL);
if (ret_error) {
g_dbus_method_invocation_take_error (context, ret_error);
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
return;
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
}
config: warn about unknown keys in config files Emit a warning when we find an unsupported option in a configuration file.
2018-11-09 18:06:32 +01:00
nm_config_reload (priv->config, reload_type, TRUE);
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
g_dbus_method_invocation_return_value (context, NULL);
}
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_reload (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
NMAuthChain *chain;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
guint32 flags;
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_variant_get (parameters, "(u)", &flags);
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
chain = nm_auth_chain_new_context (invocation, _reload_auth_cb, self);
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
if (!chain) {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_return_error_literal (invocation,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_AUTH_FAILED);
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
return;
}
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
manager: add Reload() D-Bus command Add new Reload D-Bus command to reload NetworkManager configuration. For now, this is like sending SIGHUP to the process. There are several advantages here: - it is guarded via PolicyKit authentication while signals can only be sent by root. - the user can wait for the reload to be complete instead of sending an asynchronous signal. For now, we operation completes after nm_config_reload() returns, but later we could delay the response further until specific parts are fully reloaded. - SIGHUP reloads everything including re-reading configuration from disk while SIGUSR1 reloads just certain parts such as writing out DNS configuration anew. Now, the Reload command has a flags argument which is more granular in selecting parts which are to be reloaded. For example, via signals the user can: 1) send SIGUSR1: this writes out the DNS configuration to resolv.conf and possibly reloads other parts without re-reading configuration and without restarting the DNS plugin. 2) send SIGHUP: this reloads configuration from disk, writes out resolv.conf and restarts the DNS plugin. There is no way, to only restart the DNS plugin without also reloading everything else.
2016-05-30 15:42:44 +02:00
nm_auth_chain_set_data (chain, "flags", GUINT_TO_POINTER (flags), NULL);
nm_auth_chain_add_call (chain, NM_AUTH_PERMISSION_RELOAD, TRUE);
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
NMDevice *
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
nm_manager_get_device_by_path (NMManager *self, const char *path)
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
{
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMDevice *device;
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
g_return_val_if_fail (path, NULL);
core: allow NULL device path in ActivateConnection
2011-03-15 17:04:35 -05:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
device = nm_dbus_manager_lookup_object (nm_dbus_object_get_manager (NM_DBUS_OBJECT (self)),
path);
core: rework lookup for exported objects by path to use index We already track an index of exported objects in NMDBusManager. Actually, that index was unused previously. We either could drop it, or use it. Let's use it.
2018-03-23 21:49:41 +01:00
if ( !device
|| !NM_IS_DEVICE (device)
|| c_list_is_empty (&device->devices_lst))
return NULL;
nm_assert (c_list_contains (&priv->devices_lst_head, &device->devices_lst));
return device;
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
}
platform, devices: add support for veth devices https://bugzilla.gnome.org/show_bug.cgi?id=687254
2013-05-03 13:55:51 -04:00
NMDevice *
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
nm_manager_get_device_by_ifindex (NMManager *self, int ifindex)
platform, devices: add support for veth devices https://bugzilla.gnome.org/show_bug.cgi?id=687254
2013-05-03 13:55:51 -04:00
{
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMDevice *device;
platform, devices: add support for veth devices https://bugzilla.gnome.org/show_bug.cgi?id=687254
2013-05-03 13:55:51 -04:00
manager: return NULL for invalid ifindex in nm_manager_get_device_by_ifindex() Internally, the device migth have negative or zero ifindex. When calling nm_manager_get_device_by_ifindex(), the caller wants to find a device with a valid ifindex, hence filter out non-positive values.
2018-06-22 15:47:41 +02:00
if (ifindex > 0) {
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
if (nm_device_get_ifindex (device) == ifindex)
return device;
}
platform, devices: add support for veth devices https://bugzilla.gnome.org/show_bug.cgi?id=687254
2013-05-03 13:55:51 -04:00
}
return NULL;
}
trivial: move code
2015-04-29 10:56:36 +02:00
static NMDevice *
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
find_device_by_permanent_hw_addr (NMManager *self, const char *hwaddr)
trivial: move code
2015-04-29 10:56:36 +02:00
{
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMDevice *device;
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
const char *device_addr;
manager: convert hwaddr to binary once in find_device_by_permanent_hw_addr() For comparing MAC addresses, they anyway have to be normalized to binary. Convert it once outside the loop and pass the binary form to nm_utils_hwaddr_matches(). Otherwise, we need to re-convert it every time.
2018-03-24 11:31:29 +01:00
guint8 hwaddr_bin[NM_UTILS_HWADDR_LEN_MAX];
gsize hwaddr_len;
trivial: move code
2015-04-29 10:56:36 +02:00
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
g_return_val_if_fail (hwaddr != NULL, NULL);
trivial: move code
2015-04-29 10:56:36 +02:00
manager: convert hwaddr to binary once in find_device_by_permanent_hw_addr() For comparing MAC addresses, they anyway have to be normalized to binary. Convert it once outside the loop and pass the binary form to nm_utils_hwaddr_matches(). Otherwise, we need to re-convert it every time.
2018-03-24 11:31:29 +01:00
if (!_nm_utils_hwaddr_aton (hwaddr, hwaddr_bin, sizeof (hwaddr_bin), &hwaddr_len))
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
return NULL;
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
device_addr = nm_device_get_permanent_hw_address (device);
if ( device_addr
manager: convert hwaddr to binary once in find_device_by_permanent_hw_addr() For comparing MAC addresses, they anyway have to be normalized to binary. Convert it once outside the loop and pass the binary form to nm_utils_hwaddr_matches(). Otherwise, we need to re-convert it every time.
2018-03-24 11:31:29 +01:00
&& nm_utils_hwaddr_matches (hwaddr_bin, hwaddr_len, device_addr, -1))
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
return device;
trivial: move code
2015-04-29 10:56:36 +02:00
}
return NULL;
}
static NMDevice *
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
find_device_by_ip_iface (NMManager *self, const char *iface)
trivial: move code
2015-04-29 10:56:36 +02:00
{
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMDevice *device;
trivial: move code
2015-04-29 10:56:36 +02:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
g_return_val_if_fail (iface, NULL);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
if ( nm_device_is_real (device)
&& nm_streq0 (nm_device_get_ip_iface (device), iface))
return device;
trivial: move code
2015-04-29 10:56:36 +02:00
}
return NULL;
}
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
/**
* find_device_by_iface:
* @self: the #NMManager
* @iface: the device interface to find
* @connection: a connection to ensure the returned device is compatible with
* @slave: a slave connection to ensure a master is compatible with
*
* Finds a device by interface name, preferring realized devices. If @slave
* is given, this function will only return master devices and will ensure
* @slave, when activated, can be a slave of the returned master device. If
* @connection is given, this function will only consider devices that are
* compatible with @connection.
*
* Returns: the matching #NMDevice
*/
core: check duplicate devices by interface name not UDI We can't have devices with duplicate interface names so we might as well use that for dupe checking instead of the (mostly useless) UDI.
2014-09-24 14:57:14 -05:00
static NMDevice *
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
find_device_by_iface (NMManager *self,
const char *iface,
NMConnection *connection,
NMConnection *slave)
core: check duplicate devices by interface name not UDI We can't have devices with duplicate interface names so we might as well use that for dupe checking instead of the (mostly useless) UDI.
2014-09-24 14:57:14 -05:00
{
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMDevice *fallback = NULL;
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *candidate;
core: check duplicate devices by interface name not UDI We can't have devices with duplicate interface names so we might as well use that for dupe checking instead of the (mostly useless) UDI.
2014-09-24 14:57:14 -05:00
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
g_return_val_if_fail (iface != NULL, NULL);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (candidate, &priv->devices_lst_head, devices_lst) {
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
if (strcmp (nm_device_get_iface (candidate), iface))
continue;
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
if (connection && !nm_device_check_connection_compatible (candidate, connection, NULL))
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
continue;
if (slave) {
if (!nm_device_is_master (candidate))
continue;
if (!nm_device_check_slave_connection_compatible (candidate, slave))
continue;
}
if (nm_device_is_real (candidate))
return candidate;
else if (!fallback)
fallback = candidate;
core: check duplicate devices by interface name not UDI We can't have devices with duplicate interface names so we might as well use that for dupe checking instead of the (mostly useless) UDI.
2014-09-24 14:57:14 -05:00
}
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
return fallback;
core: check duplicate devices by interface name not UDI We can't have devices with duplicate interface names so we might as well use that for dupe checking instead of the (mostly useless) UDI.
2014-09-24 14:57:14 -05:00
}
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
static gboolean
manager_sleeping (NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
if (priv->sleeping || !priv->net_enabled)
return TRUE;
return FALSE;
}
core: refactor NMManager by adding function for converting NMState to string This will be especially nice, with lazy evaluation for NM logging. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-15 17:55:17 +02:00
static const char *
_nm_state_to_string (NMState state)
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
{
switch (state) {
case NM_STATE_ASLEEP:
core: refactor NMManager by adding function for converting NMState to string This will be especially nice, with lazy evaluation for NM logging. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-15 17:55:17 +02:00
return "ASLEEP";
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
case NM_STATE_DISCONNECTED:
core: refactor NMManager by adding function for converting NMState to string This will be especially nice, with lazy evaluation for NM logging. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-15 17:55:17 +02:00
return "DISCONNECTED";
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
case NM_STATE_DISCONNECTING:
core: refactor NMManager by adding function for converting NMState to string This will be especially nice, with lazy evaluation for NM logging. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-15 17:55:17 +02:00
return "DISCONNECTING";
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
case NM_STATE_CONNECTING:
core: refactor NMManager by adding function for converting NMState to string This will be especially nice, with lazy evaluation for NM logging. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-15 17:55:17 +02:00
return "CONNECTING";
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
case NM_STATE_CONNECTED_LOCAL:
core: refactor NMManager by adding function for converting NMState to string This will be especially nice, with lazy evaluation for NM logging. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-15 17:55:17 +02:00
return "CONNECTED_LOCAL";
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
case NM_STATE_CONNECTED_SITE:
core: refactor NMManager by adding function for converting NMState to string This will be especially nice, with lazy evaluation for NM logging. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-15 17:55:17 +02:00
return "CONNECTED_SITE";
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
case NM_STATE_CONNECTED_GLOBAL:
core: refactor NMManager by adding function for converting NMState to string This will be especially nice, with lazy evaluation for NM logging. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-15 17:55:17 +02:00
return "CONNECTED_GLOBAL";
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
case NM_STATE_UNKNOWN:
default:
core: refactor NMManager by adding function for converting NMState to string This will be especially nice, with lazy evaluation for NM logging. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-15 17:55:17 +02:00
return "UNKNOWN";
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
}
core: refactor NMManager by adding function for converting NMState to string This will be especially nice, with lazy evaluation for NM logging. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-15 17:55:17 +02:00
}
core: NMManager:state fixes for assumed connections, etc 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.
2013-11-08 12:23:43 -05:00
static NMState
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
find_best_device_state (NMManager *manager)
core: NMManager:state fixes for assumed connections, etc 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.
2013-11-08 12:23:43 -05:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (manager);
NMState best_state = NM_STATE_DISCONNECTED;
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
NMActiveConnection *ac;
core: NMManager:state fixes for assumed connections, etc 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.
2013-11-08 12:23:43 -05:00
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
c_list_for_each_entry (ac, &priv->active_connections_lst_head, active_connections_lst) {
core: NMManager:state fixes for assumed connections, etc 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.
2013-11-08 12:23:43 -05:00
NMActiveConnectionState ac_state = nm_active_connection_get_state (ac);
switch (ac_state) {
case NM_ACTIVE_CONNECTION_STATE_ACTIVATED:
core: merge IPv4 and IPv6 versions of nm_active_connection_get_default()
2017-11-23 21:53:04 +01:00
if (nm_active_connection_get_default (ac, AF_UNSPEC)) {
manager: fix evaluation of manager state The state should be set to CONNECTED_GLOBAL only when there is full connectivity. Fixes: 9d43869e473b47542520c807dace93a6f9520964 https://bugzilla.gnome.org/show_bug.cgi?id=785281
2017-10-20 10:37:11 +02:00
if (priv->connectivity_state == NM_CONNECTIVITY_FULL)
core: NMManager:state fixes for assumed connections, etc 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.
2013-11-08 12:23:43 -05:00
return NM_STATE_CONNECTED_GLOBAL;
connectivity: fix manager state during connectivity check (bgo #742823) When a connection has finished activating, but we don't know yet that we have full connectivity, then find_best_device_state() should return CONNECTED_SITE, not CONNECTING. Fixes a bug where the manager state would repeatedly switch between those two states.
2015-01-13 14:48:29 -05:00
best_state = NM_STATE_CONNECTED_SITE;
core: NMManager:state fixes for assumed connections, etc 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.
2013-11-08 12:23:43 -05:00
} else {
if (best_state < NM_STATE_CONNECTING)
best_state = NM_STATE_CONNECTED_LOCAL;
}
break;
case NM_ACTIVE_CONNECTION_STATE_ACTIVATING:
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (!NM_IN_SET (nm_active_connection_get_activation_type (ac),
NM_ACTIVATION_TYPE_EXTERNAL,
NM_ACTIVATION_TYPE_ASSUME)) {
core: NMManager:state fixes for assumed connections, etc 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.
2013-11-08 12:23:43 -05:00
if (best_state != NM_STATE_CONNECTED_GLOBAL)
best_state = NM_STATE_CONNECTING;
}
break;
case NM_ACTIVE_CONNECTION_STATE_DEACTIVATING:
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (!NM_IN_SET (nm_active_connection_get_activation_type (ac),
NM_ACTIVATION_TYPE_EXTERNAL,
NM_ACTIVATION_TYPE_ASSUME)) {
core: NMManager:state fixes for assumed connections, etc 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.
2013-11-08 12:23:43 -05:00
if (best_state < NM_STATE_DISCONNECTING)
best_state = NM_STATE_DISCONNECTING;
}
break;
default:
break;
}
}
return best_state;
}
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
static void
manager: use logging helpers
2016-03-02 11:38:26 +01:00
nm_manager_update_metered (NMManager *self)
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
{
NMManagerPrivate *priv;
NMDevice *device;
NMMetered value = NM_METERED_UNKNOWN;
manager: use logging helpers
2016-03-02 11:38:26 +01:00
g_return_if_fail (NM_IS_MANAGER (self));
priv = NM_MANAGER_GET_PRIVATE (self);
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
if (priv->primary_connection) {
device = nm_active_connection_get_device (priv->primary_connection);
if (device)
value = nm_device_get_metered (device);
}
if (value != priv->metered) {
priv->metered = value;
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGD (LOGD_CORE, "new metered value: %d", (int) priv->metered);
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
_notify (self, PROP_METERED);
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
}
}
device/shared: set ANDROID_METERED option 43 for shared connections The problem is that updating the metered value of a shared connection is not implemented. The user needs to fully reactivate the profile for changes to take effect. That is unfortunate, especially because reapplying the route metric works in other other cases.
2018-11-29 10:58:59 +01:00
NMMetered
nm_manager_get_metered (NMManager *self)
{
g_return_val_if_fail (NM_IS_MANAGER (self), NM_METERED_UNKNOWN);
return NM_MANAGER_GET_PRIVATE (self)->metered;
}
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
static void
manager: merge set_state() in nm_manager_update_state() function
2018-04-11 11:44:47 +02:00
nm_manager_update_state (NMManager *self)
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
{
NMManagerPrivate *priv;
NMState new_state = NM_STATE_DISCONNECTED;
manager: merge set_state() in nm_manager_update_state() function
2018-04-11 11:44:47 +02:00
g_return_if_fail (NM_IS_MANAGER (self));
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
manager: merge set_state() in nm_manager_update_state() function
2018-04-11 11:44:47 +02:00
priv = NM_MANAGER_GET_PRIVATE (self);
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
manager: merge set_state() in nm_manager_update_state() function
2018-04-11 11:44:47 +02:00
if (manager_sleeping (self))
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
new_state = NM_STATE_ASLEEP;
core: NMManager:state fixes for assumed connections, etc 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.
2013-11-08 12:23:43 -05:00
else
manager: merge set_state() in nm_manager_update_state() function
2018-04-11 11:44:47 +02:00
new_state = find_best_device_state (self);
manager: retrigger the connectivity check if we loose a default route Update the connectivity state if we go from CONNECTED_GLOBAL to CONNECTED_LOCAL. It will likely fail immediately (unless there's a default route we're not aware of or the check URL is routable locally), keeping the Connectivity property up-to-date.
2017-02-16 10:07:10 +01:00
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
if ( new_state >= NM_STATE_CONNECTED_LOCAL
&& priv->connectivity_state == NM_CONNECTIVITY_FULL) {
new_state = NM_STATE_CONNECTED_GLOBAL;
connectivity: simplify redundant code Merge the two nm_connectivity_set_online() calls into one, after tweaking NMConnectivity to always update its internal state before alerting callers to the new state.
2015-01-13 15:35:10 -05:00
}
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
manager: merge set_state() in nm_manager_update_state() function
2018-04-11 11:44:47 +02:00
if (priv->state == new_state)
return;
priv->state = new_state;
_LOGI (LOGD_CORE, "NetworkManager state is now %s", _nm_state_to_string (new_state));
_notify (self, PROP_STATE);
nm_dbus_object_emit_signal (NM_DBUS_OBJECT (self),
&interface_info_manager,
&signal_info_state_changed,
"(u)",
(guint32) priv->state);
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
}
static void
manager_device_state_changed (NMDevice *device,
NMDeviceState new_state,
NMDeviceState old_state,
NMDeviceStateReason reason,
gpointer user_data)
{
core: fix up connectivity state checks We want to start the connectivity checks when any device gets activated, and stop them when all devices get deactivated. We also want to make sure it's running if a device gets deactivated but other devices are still active. If multiple devices are activated and if the default device gets deactivated, the other device may become the default device and we'll need a connectivity check for that device since we can't do per-device checks yet. Also, if connectivity checking is enabled at compile-time but not enabled at runtime, the connectivity bits should always report "connected" to preserve previous behavior, and this code makes it clearer how that is handled.
2011-12-14 13:41:57 -06:00
NMManager *self = NM_MANAGER (user_data);
core: simplify generation of default connection for new devices 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 b3b0b4625053 ("device: retry creation of default connection after link is initialized").
2015-12-13 22:08:23 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
manager: retry activating devices when the parent becomes managed Since commit ed640f857a1a ("manager: ignore unmanaged devices when looking for parent by UUID"), unmanaged devices are ignored when looking for potential parent connection matches. Therefore, a software device can fail autoactivation because the parent is not managed yet and NM never tries to reactivate it. Ensure that we retry other devices when a parent device becomes managed. Fixes: ed640f857a1a1eae45d92cce35ea8dcfd8aba08d https://bugzilla.redhat.com/show_bug.cgi?id=1553595
2018-03-19 14:15:56 +01:00
if ( old_state == NM_DEVICE_STATE_UNMANAGED
&& new_state > NM_DEVICE_STATE_UNMANAGED)
retry_connections_for_parent_device (self, device);
manager: use NM_IN_SET() No functional change.
2018-07-06 21:44:06 +02:00
if (NM_IN_SET (new_state,
NM_DEVICE_STATE_UNMANAGED,
NM_DEVICE_STATE_UNAVAILABLE,
NM_DEVICE_STATE_DISCONNECTED,
NM_DEVICE_STATE_PREPARE,
NM_DEVICE_STATE_FAILED))
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
_notify (self, PROP_ACTIVE_CONNECTIONS);
core: simplify generation of default connection for new devices 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 b3b0b4625053 ("device: retry creation of default connection after link is initialized").
2015-12-13 22:08:23 +01:00
manager: update the device state file upon (dis)connection Update the device state file every time the device is connected, disconnected, or becomes unmanaged. In this way, NM becomes more robust against crashes or forced terminations because it can resume the previous device state seamlessly.
2018-07-06 21:35:04 +02:00
if (NM_IN_SET (new_state,
NM_DEVICE_STATE_UNMANAGED,
NM_DEVICE_STATE_DISCONNECTED,
NM_DEVICE_STATE_ACTIVATED))
nm_manager_write_device_state (self, device);
manager: use NM_IN_SET() No functional change.
2018-07-06 21:44:06 +02:00
if (NM_IN_SET (new_state,
NM_DEVICE_STATE_UNAVAILABLE,
NM_DEVICE_STATE_DISCONNECTED))
core: simplify generation of default connection for new devices 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 b3b0b4625053 ("device: retry creation of default connection after link is initialized").
2015-12-13 22:08:23 +01:00
nm_settings_device_added (priv->settings, device);
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
}
core: add NMManager:startup property Add a property on NMManager indicating that it is currently starting up and activating startup-time/boot-time network connections. "startup" is initially TRUE, and becomes FALSE once all NMDevices report that they have no pending activity (eg, trying to activate, waiting for a wifi scan to complete, etc). This is tracked via a new NMDevice:has-pending-activity property, which is maintained partially by the device itself, and partially by other parts of the code.
2013-08-13 17:45:34 -04:00
static void device_has_pending_action_changed (NMDevice *device,
GParamSpec *pspec,
NMManager *self);
static void
check_if_startup_complete (NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *device;
core: improve logging why startup-complete is blocked Before: "manager: check_if_startup_complete returns FALSE because of eth0" Now: "manager: startup complete is waiting for device 'eth0' (autoactivate)" Also, the logging line is now more a human readable sentence, but still follows the same pattern as later "manager: startup complete" Meaning: grepping for "startup complete" becomes more helpful because one first finds the reasons why startup-complete is not yet reached, followed by the moment when it is reached.
2018-09-19 17:22:50 +02:00
const char *reason;
core: add NMManager:startup property Add a property on NMManager indicating that it is currently starting up and activating startup-time/boot-time network connections. "startup" is initially TRUE, and becomes FALSE once all NMDevices report that they have no pending activity (eg, trying to activate, waiting for a wifi scan to complete, etc). This is tracked via a new NMDevice:has-pending-activity property, which is maintained partially by the device itself, and partially by other parts of the code.
2013-08-13 17:45:34 -04:00
if (!priv->startup)
return;
core: don't set "startup complete" until devices have been added (rh #1256772) 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
2015-08-25 13:32:53 +02:00
if (!priv->devices_inited)
return;
core: improve logging why startup-complete is blocked Before: "manager: check_if_startup_complete returns FALSE because of eth0" Now: "manager: startup complete is waiting for device 'eth0' (autoactivate)" Also, the logging line is now more a human readable sentence, but still follows the same pattern as later "manager: startup complete" Meaning: grepping for "startup complete" becomes more helpful because one first finds the reasons why startup-complete is not yet reached, followed by the moment when it is reached.
2018-09-19 17:22:50 +02:00
reason = nm_settings_get_startup_complete_blocked_reason (priv->settings);
if (reason) {
_LOGD (LOGD_CORE, "startup complete is waiting for connection (%s)",
reason);
core: allow connections to participate in NMManager:startup-complete Add an NMSettingsConnection:ready property, which indicates if the connection is ready to use. Add NMSettings:startup-complete, which is TRUE when all connections are ready. Make NMManager:startup-complete take NMSettings:startup-complete into account.
2014-12-18 16:04:07 -05:00
return;
}
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
core: improve logging why startup-complete is blocked Before: "manager: check_if_startup_complete returns FALSE because of eth0" Now: "manager: startup complete is waiting for device 'eth0' (autoactivate)" Also, the logging line is now more a human readable sentence, but still follows the same pattern as later "manager: startup complete" Meaning: grepping for "startup complete" becomes more helpful because one first finds the reasons why startup-complete is not yet reached, followed by the moment when it is reached.
2018-09-19 17:22:50 +02:00
reason = nm_device_has_pending_action_reason (device);
if (reason) {
_LOGD (LOGD_CORE, "startup complete is waiting for device '%s' (%s)",
nm_device_get_iface (device),
reason);
core: add NMManager:startup property Add a property on NMManager indicating that it is currently starting up and activating startup-time/boot-time network connections. "startup" is initially TRUE, and becomes FALSE once all NMDevices report that they have no pending activity (eg, trying to activate, waiting for a wifi scan to complete, etc). This is tracked via a new NMDevice:has-pending-activity property, which is maintained partially by the device itself, and partially by other parts of the code.
2013-08-13 17:45:34 -04:00
return;
}
}
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGI (LOGD_CORE, "startup complete");
core: add NMManager:startup property Add a property on NMManager indicating that it is currently starting up and activating startup-time/boot-time network connections. "startup" is initially TRUE, and becomes FALSE once all NMDevices report that they have no pending activity (eg, trying to activate, waiting for a wifi scan to complete, etc). This is tracked via a new NMDevice:has-pending-activity property, which is maintained partially by the device itself, and partially by other parts of the code.
2013-08-13 17:45:34 -04:00
priv->startup = FALSE;
manager: disconnect NMSetting's startup-complete notification in check_if_startup_complete() This doesn't really matter, because NMSetting's startup-complete never switches back to FALSE once reached. Still, cleanup our signal handlers when no longer needed. And disconnect the signals before emitting "notify::startup".
2017-03-14 17:39:26 +01:00
/* we no longer care about these signals. Startup-complete only
* happens once. */
g_signal_handlers_disconnect_by_func (priv->settings, G_CALLBACK (settings_startup_complete_changed), self);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
g_signal_handlers_disconnect_by_func (device,
manager: disconnect NMSetting's startup-complete notification in check_if_startup_complete() This doesn't really matter, because NMSetting's startup-complete never switches back to FALSE once reached. Still, cleanup our signal handlers when no longer needed. And disconnect the signals before emitting "notify::startup".
2017-03-14 17:39:26 +01:00
G_CALLBACK (device_has_pending_action_changed),
self);
core: add NMManager:startup property Add a property on NMManager indicating that it is currently starting up and activating startup-time/boot-time network connections. "startup" is initially TRUE, and becomes FALSE once all NMDevices report that they have no pending activity (eg, trying to activate, waiting for a wifi scan to complete, etc). This is tracked via a new NMDevice:has-pending-activity property, which is maintained partially by the device itself, and partially by other parts of the code.
2013-08-13 17:45:34 -04:00
}
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
manager: disconnect NMSetting's startup-complete notification in check_if_startup_complete() This doesn't really matter, because NMSetting's startup-complete never switches back to FALSE once reached. Still, cleanup our signal handlers when no longer needed. And disconnect the signals before emitting "notify::startup".
2017-03-14 17:39:26 +01:00
_notify (self, PROP_STARTUP);
manager: use priv->config instead of singleton getter nm_config_get()
2016-07-01 14:30:00 +02:00
if (nm_config_get_configure_and_quit (priv->config))
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
g_signal_emit (self, signals[CONFIGURE_QUIT], 0);
core: add NMManager:startup property Add a property on NMManager indicating that it is currently starting up and activating startup-time/boot-time network connections. "startup" is initially TRUE, and becomes FALSE once all NMDevices report that they have no pending activity (eg, trying to activate, waiting for a wifi scan to complete, etc). This is tracked via a new NMDevice:has-pending-activity property, which is maintained partially by the device itself, and partially by other parts of the code.
2013-08-13 17:45:34 -04:00
}
static void
device_has_pending_action_changed (NMDevice *device,
GParamSpec *pspec,
NMManager *self)
{
check_if_startup_complete (self);
}
core: allow connections to participate in NMManager:startup-complete Add an NMSettingsConnection:ready property, which indicates if the connection is ready to use. Add NMSettings:startup-complete, which is TRUE when all connections are ready. Make NMManager:startup-complete take NMSettings:startup-complete into account.
2014-12-18 16:04:07 -05:00
static void
settings_startup_complete_changed (NMSettings *settings,
GParamSpec *pspec,
NMManager *self)
{
check_if_startup_complete (self);
}
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
static void
_parent_notify_changed (NMManager *self,
NMDevice *device,
gboolean device_removed)
{
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMDevice *candidate;
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
nm_assert (NM_IS_DEVICE (device));
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
again:
c_list_for_each_entry (candidate, &priv->devices_lst_head, devices_lst) {
if (nm_device_parent_notify_changed (candidate, device, device_removed)) {
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
/* in the unlikely event that this changes anything, we start iterating
* again, to be sure that the device list is up-to-date. */
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
goto again;
}
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
}
}
core: don't shutdown interfaces if they have wowlan enabled This is to support the S5 case, where usually the NM process is stopped. If we are stopping and WoWLAN is set for the interface, we do not deconfigure it and keep the connection alive so we can receive packages that will potentially wake up the system. Note that for this work, wpa_supplicant needs to be modified too so it does not deconfigure the wireless interface either when stopped. The needed patches for wpa_supplicant can be found in http://lists.infradead.org/pipermail/hostap/2018-June/038644.html
2018-05-25 17:46:33 +02:00
static gboolean
device_is_wake_on_lan (NMPlatform *platform, NMDevice *device)
{
core: avoid assertion when removing devices remove_device() is also called when the device has no longer a valid ifindex and so device_is_wake_on_lan() must do an extra check to avoid the following assertion: nmp_cache_lookup_entry_link: assertion 'ifindex > 0' failed 0 _g_log_abort () from target:/lib64/libglib-2.0.so.0 1 g_logv () from target:/lib64/libglib-2.0.so.0 2 g_log () from target:/lib64/libglib-2.0.so.0 3 nmp_cache_lookup_entry_link (cache=0xb858f0, ifindex=ifindex@entry=0) at ../src/platform/nmp-object.c:1713 4 nmp_cache_lookup_link (cache=<optimized out>, ifindex=ifindex@entry=0) at ../src/platform/nmp-object.c:1728 5 nm_platform_link_get_obj (self=self@entry=0xb85840, ifindex=ifindex@entry=0, visible_only=visible_only@entry=1) at ../src/platform/nm-platform.c:759 6 nm_platform_link_get (self=self@entry=0xb85840, ifindex=ifindex@entry=0) at ../src/platform/nm-platform.c:784 7 nm_platform_link_get_type (self=self@entry=0xb85840, ifindex=ifindex@entry=0) at ../src/platform/nm-platform.c:1065 8 link_get_wake_on_lan (platform=0xb85840, ifindex=0) at ../src/platform/nm-linux-platform.c:6963 9 nm_platform_link_get_wake_on_lan (self=self@entry=0xb85840, ifindex=0) at ../src/platform/nm-platform.c:1705 10 device_is_wake_on_lan (platform=0xb85840, device=<optimized out>) at ../src/nm-manager.c:1617 11 remove_device (self=0xbd0060, device=<optimized out>, device@entry=0xd298c0, quitting=quitting@entry=0, allow_unmanage=allow_unmanage@entry=1) 12 device_removed_cb (device=0xd298c0, user_data=0xbd0060) at ../src/nm-manager.c:1698 13 _g_closure_invoke_va () from target:/lib64/libgobject-2.0.so.0 14 g_signal_emit_valist () from target:/lib64/libgobject-2.0.so.0 15 g_signal_emit () from target:/lib64/libgobject-2.0.so.0 16 available_connections_check_delete_unrealized_on_idle (user_data=0xd298c0) at ../src/devices/nm-device.c:4446 Fixes: ca3bbede746a7d7031ba6a011c69ad7adb1dca3e
2018-12-04 19:05:27 +01:00
int ifindex;
ifindex = nm_device_get_ip_ifindex (device);
if (ifindex <= 0)
return FALSE;
return nm_platform_link_get_wake_on_lan (platform, ifindex);
core: don't shutdown interfaces if they have wowlan enabled This is to support the S5 case, where usually the NM process is stopped. If we are stopping and WoWLAN is set for the interface, we do not deconfigure it and keep the connection alive so we can receive packages that will potentially wake up the system. Note that for this work, wpa_supplicant needs to be modified too so it does not deconfigure the wireless interface either when stopped. The needed patches for wpa_supplicant can be found in http://lists.infradead.org/pipermail/hostap/2018-June/038644.html
2018-05-25 17:46:33 +02:00
}
core: minor device removal simplification/fix nm-manager.c:remove_one_device() took a GSList as an argument and returned that GSList with the device removed; but every caller passed in priv->devices and assigned the result to priv->devices, so just make it always do that. Also, rename it to remove_device() to match add_device(). Also, when removing a device, NMManager was only disconnecting one of the several signal handlers it connected in add_device(). This generally wasn't a problem since the device would normally be destroyed immediately after this, but it's good to be correct.
2013-08-15 12:58:22 -04:00
static void
manager: use logging helpers
2016-03-02 11:38:26 +01:00
remove_device (NMManager *self,
core: remove child devices without deconfiguring them (bgo #738479) When a child device is found and an IP configuration already exists for it even though it is under NM control (like when pppd applies IP config to a WWAN device before NM gets the IP details from the pppd plugin), don't deconfigure the child device when removing it from the device list, because this breaks the device's configuration. https://bugzilla.gnome.org/show_bug.cgi?id=738479
2014-10-13 11:58:26 -05:00
NMDevice *device,
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
gboolean quitting)
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
{
manager: use logging helpers
2016-03-02 11:38:26 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
manager: fix wrongly removing DNS configuration on shutdown When NetworkManager exits, it must preserve the DNS configuration of devices that are left up. Fixes: 9498ea507eb1d5042736c4351337e91b9c13bdf6
2016-04-20 17:46:41 +02:00
gboolean unmanage = FALSE;
system-settings: resurrect auto-wired-default behavior Dropped due to time during the udev conversion.
2009-07-09 11:06:31 -04:00
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
_LOG2D (LOGD_DEVICE, device, "removing device (managed %d, wol %d)",
nm_device_get_managed (device, FALSE),
core: don't shutdown interfaces if they have wowlan enabled This is to support the S5 case, where usually the NM process is stopped. If we are stopping and WoWLAN is set for the interface, we do not deconfigure it and keep the connection alive so we can receive packages that will potentially wake up the system. Note that for this work, wpa_supplicant needs to be modified too so it does not deconfigure the wireless interface either when stopped. The needed patches for wpa_supplicant can be found in http://lists.infradead.org/pipermail/hostap/2018-June/038644.html
2018-05-25 17:46:33 +02:00
device_is_wake_on_lan (priv->platform, device));
trivial: add some debug messages on device destruction/removal
2014-12-18 10:23:06 -06:00
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
if (nm_device_get_managed (device, FALSE)) {
core: don't deactivate assumed connections when quitting 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.
2013-11-08 15:07:20 -06:00
core: don't shutdown interfaces if they have wowlan enabled This is to support the S5 case, where usually the NM process is stopped. If we are stopping and WoWLAN is set for the interface, we do not deconfigure it and keep the connection alive so we can receive packages that will potentially wake up the system. Note that for this work, wpa_supplicant needs to be modified too so it does not deconfigure the wireless interface either when stopped. The needed patches for wpa_supplicant can be found in http://lists.infradead.org/pipermail/hostap/2018-June/038644.html
2018-05-25 17:46:33 +02:00
if (quitting) {
/* Leave configured if wo(w)lan and quitting */
if (device_is_wake_on_lan (priv->platform, device))
unmanage = FALSE;
else
unmanage = nm_device_unmanage_on_quit (device);
} else {
manager: don't unmanage devices without L3 config on shutdown Use the following logic when quitting, if the device is managed: 1) if the connection is assumed, leave it up 2) if the device has no connection (eg, !req) leave it up 3) if the device only has L2 leave it up [thaller@redhat.com: original patch reworked by bgalvani@redhat.com and me] https://bugzilla.redhat.com/show_bug.cgi?id=1311988 https://bugzilla.redhat.com/show_bug.cgi?id=1333983
2016-04-01 11:04:34 +02:00
/* the device is already gone. Unmanage it. */
core: refactor unmanaging devices on shutdown and unmanage Wi-Fi devices Add new virtual function nm_device_unmanage_on_quit() to determine whether to unmanage the device on shutdown. This allows Wi-Fi devices to always be unmanaged. We want that to reset the initial MAC address.
2016-06-21 11:04:38 +02:00
unmanage = TRUE;
manager: don't unmanage devices without L3 config on shutdown Use the following logic when quitting, if the device is managed: 1) if the connection is assumed, leave it up 2) if the device has no connection (eg, !req) leave it up 3) if the device only has L2 leave it up [thaller@redhat.com: original patch reworked by bgalvani@redhat.com and me] https://bugzilla.redhat.com/show_bug.cgi?id=1311988 https://bugzilla.redhat.com/show_bug.cgi?id=1333983
2016-04-01 11:04:34 +02:00
}
core: fix deactivation of assumed connections on device removal (bgo #729833) The following procedure leaves an NMActiveConnection around for a deactivated device, which causes errors in libnm-glib clients when they cannot create the GObject for the non-existent device of the AC. 1) allow a device which can assume connections to be activated 2) stop NM, which should leave the device's IP configuration up 3) start NM and allow it to assume the device's existing connection 4) remove the device, either by unplugging it or 'rmmod' The device is removed by nm-manager.c::remove_device(), but the device object is not moved to UNMANAGED state, leaving the NMActiveConnection completely unaware the device has gone away. The nm-manager.c::remove_device() code did not correctly handle moving a forcibly removed (eg, by unplugging or 'ip link del' or 'rmmod') device to the UNMANAGED state when the device was active with an assumed connection. To fix this, make the conditions when the device should be deactivated on removal much more explicit. A device should be deactivated on removal if: 1) it is forcibly removed, eg by the kernel network interface being removed due to 'ip link del' or hotplugging, or internally by NM due to a parent WWAN interface taking priority over a WWAN ethernet interface 2) if the device cannot assume connections, in which case NetworkManager must have activated the device and since we cannot assume the connection on restart, we should deactivate it 3) if the device is not activated, to ensure that its IPv6 parameters and other things get reset to the pre-NetworkManager values https://bugzilla.gnome.org/show_bug.cgi?id=729833
2014-05-08 14:32:02 -05:00
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
if (unmanage) {
if (quitting)
device/trivial: rename nm_device_set_unmanaged_flags()
2016-01-13 12:03:47 +01:00
nm_device_set_unmanaged_by_quitting (device);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
else {
nm_device_sys_iface_state_set (device, NM_DEVICE_SYS_IFACE_STATE_REMOVED);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_by_flags (device, NM_UNMANAGED_PLATFORM_INIT, TRUE, NM_DEVICE_STATE_REASON_REMOVED);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
}
config: add --configure-and-quit=initrd mode We need a mode that: * doesn't leave processes behind * doesn't force an internal dhclient * doesn't auto-generate default connections * doesn't write out files into libdir, only /run The original configure-and-quit mode doesn't really fit the initrd use. But it's proobably not a good idea to just change its behavior.
2018-01-30 18:01:18 +01:00
} else if (quitting && nm_config_get_configure_and_quit (priv->config) == NM_CONFIG_CONFIGURE_AND_QUIT_ENABLED) {
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
nm_device_spawn_iface_helper (device);
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
}
core: base infrastructure for connection assumption Figure out what connections can be assumed when a device is added, and on shutdown don't blow away connections that can be assumed on NM restart.
2009-08-03 17:15:03 -04:00
}
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
manager: use logging helpers
2016-03-02 11:38:26 +01:00
g_signal_handlers_disconnect_matched (device, G_SIGNAL_MATCH_DATA, 0, 0, NULL, NULL, self);
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
core: allow default wired connections to stay up when quitting 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.
2013-11-14 11:33:12 -06:00
nm_settings_device_removed (priv->settings, device, quitting);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_unlink (&device->devices_lst);
core: update NMManager:devices before emitting notify::devices (rh #1078720) NMClient's "devices" property was getting out of sync because the daemon was emitting "notify" before actually changing the property value. This resulted in problems with re-activating virtual devices that had previously been deactivated in gnome-control-center and anaconda. (And probably gnome-shell and nm-applet?)
2014-03-27 12:16:46 -04:00
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
_parent_notify_changed (self, device, TRUE);
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
if (nm_device_is_real (device)) {
manager: fix wrongly removing DNS configuration on shutdown When NetworkManager exits, it must preserve the DNS configuration of devices that are left up. Fixes: 9498ea507eb1d5042736c4351337e91b9c13bdf6
2016-04-20 17:46:41 +02:00
gboolean unconfigure_ip_config = !quitting || unmanage;
/* When we don't unmanage the device on shutdown, we want to preserve the DNS
* configuration in resolv.conf. For that, we must leak the configuration
* in NMPolicy/NMDnsManager. We do that, by emitting the device-removed signal
* with device's ip-config object still uncleared. In that case, NMPolicy
* never learns to unconfigure the ip-config objects and does not remove them
* from DNS on shutdown (which is ugly, because we don't cleanup the memory
* properly).
*
* Control that by passing @unconfigure_ip_config. */
nm_device_removed (device, unconfigure_ip_config);
manager: ensure IP config of device is cleared before removal If the manager removes the device, the IP config objects must be cleared. The reason is that NMPolicy registers to the IP config changed signal and passes these object on to NMDnsManager. If the INTERNAL_DEVICE_REMOVED signal is emited with IP configuration object pending, those objects will be leaked. This partly redoes commit f72816bf108cf3fa52ae267e3622a1f19db28b21, which was reverted. Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=764483
2016-04-04 16:58:33 +02:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
_emit_device_added_removed (self, device, FALSE);
manager: ensure proper disposal of unrealized devices When remove_device() is called on an already unrealized device, we should release it from master if necessary and clear its IP configurations to avoid leaks. https://bugzilla.redhat.com/show_bug.cgi?id=1433303
2017-03-17 23:30:43 +01:00
} else {
/* unrealize() does not release a slave device from master and
* clear IP configurations, do it here */
nm_device_removed (device, TRUE);
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
}
manager: ensure proper disposal of unrealized devices When remove_device() is called on an already unrealized device, we should release it from master if necessary and clear its IP configurations to avoid leaks. https://bugzilla.redhat.com/show_bug.cgi?id=1433303
2017-03-17 23:30:43 +01:00
manager: use logging helpers
2016-03-02 11:38:26 +01:00
g_signal_emit (self, signals[INTERNAL_DEVICE_REMOVED], 0, device);
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
_notify (self, PROP_ALL_DEVICES);
core: unregister removed devices from D-Bus Instead of waiting until the device is disposed and dbus-glib does it for us, remove them when the Manager is done with them. If something (like pending D-Bus calls) holds a reference to the device when the Manager removes it, the device would previously still service method calls until all references are released. When the device is removed, it's dead, and it shouldn't be exported anymore.
2014-04-09 12:31:08 -05:00
Update connectivity value on device removal When a device is removed (like when the user unplugs a usb network device) the device object is removed, so it doesn't emit a notify signal for a change in its connectivity and so, device_connectivity_changed is not called. This means that nobody updates the global connectivity value which is potentially wrong if the device was the one providing network connectivity. Since device_connectivity_changed's first two parameters aren't actually used and are there just for the signal to be able to be connected, I moved the code from device_connectivity_changed to a new update_connectivity_value function that just takes a NMManager parameter and also call it from remove_device. [thaller@redhat.com: fix coding style regarding whitespace] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/141 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/101
2019-03-21 11:32:32 +01:00
update_connectivity_value (self);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_dbus_object_clear_and_unexport (&device);
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
manager: use logging helpers
2016-03-02 11:38:26 +01:00
check_if_startup_complete (self);
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
}
core: allow devices to indicate when they should be removed Devices created by plugins will use this to indicate when their backing resources have disappeared, at which point the manager should remove them.
2014-02-10 08:49:47 -06:00
static void
device_removed_cb (NMDevice *device, gpointer user_data)
{
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
remove_device (NM_MANAGER (user_data), device, FALSE);
core: allow devices to indicate when they should be removed Devices created by plugins will use this to indicate when their backing resources have disappeared, at which point the manager should remove them.
2014-02-10 08:49:47 -06:00
}
2007-09-25 Dan Williams <dcbw@redhat.com> * src/nm-manager.c - (nm_manager_update_state): new function; updates state and emits appropriate signals ensuring a state-change signal for the same state never gets emitted twice in a row. - (manager_device_state_changed): handle more device state to get a better picture of the overall NM state git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2882 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-25 16:47:53 +00:00
NMState
nm_manager_get_state (NMManager *manager)
{
g_return_val_if_fail (NM_IS_MANAGER (manager), NM_STATE_UNKNOWN);
return NM_MANAGER_GET_PRIVATE (manager)->state;
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
all: standardize on NMSettingWired:mac-address for all VLANs Currently, ethernet-based VLANs can specify the hardware address of the parent device (and, in theory, the cloned hardware address and MTU of the VLAN device) by using an NMSettingWired in addition to the NMSettingVlan. The theory was that non-ethernet-based VLANs, when we eventually supported them, would likewise use the setting type corresponding to their parent device. However, this turns out to be both complicated (the settings plugins and connection editor would have a hard-to-impossible time figuring out which setting type to use in some cases) and incorrect (for most L2 settings [eg, BSSID, bond mode, etc], the VLAN can't have its own values separate from the parent device). What we should have done was just have :mac-address, :cloned-mac-address, and :mtu properties on NMSettingVlan. However, at this point, for backward-compatibility, we will just stick with using a combination of NMSettingVlan and NMSettingWired, but we will use NMSettingWired regardless of the underlying hardware type.
2013-09-09 09:40:40 -04:00
static NMDevice *
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
find_parent_device_for_connection (NMManager *self,
NMConnection *connection,
NMDeviceFactory *cached_factory,
const char **out_parent_spec)
core: automatically create VLAN interfaces when needed
2012-02-12 14:48:44 -06:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
NMDeviceFactory *factory;
const char *parent_name = NULL;
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
NMSettingsConnection *parent_connection;
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
NMDevice *parent, *first_compatible = NULL;
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *candidate;
core: automatically create VLAN interfaces when needed
2012-02-12 14:48:44 -06:00
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
g_return_val_if_fail (NM_IS_CONNECTION (connection), NULL);
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
NM_SET_OUT (out_parent_spec, NULL);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
manager: reused the factory looked up in nm_manager_get_connection_iface() Only lookup the factory once and pass it down to find_parent_device_for_connection().
2016-02-17 15:18:37 +01:00
if (!cached_factory) {
factory = nm_device_factory_manager_find_factory_for_connection (connection);
if (!factory)
return NULL;
} else
factory = cached_factory;
core: automatically create VLAN interfaces when needed
2012-02-12 14:48:44 -06:00
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
parent_name = nm_device_factory_get_connection_parent (factory, connection);
if (!parent_name)
return NULL;
core: automatically create VLAN interfaces when needed
2012-02-12 14:48:44 -06:00
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
NM_SET_OUT (out_parent_spec, parent_name);
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
/* Try as an interface name of a parent device */
parent = find_device_by_iface (self, parent_name, NULL, NULL);
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
if (parent)
return parent;
core: automatically create VLAN interfaces when needed
2012-02-12 14:48:44 -06:00
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
/* Maybe a hardware address */
device: fix matching MAC address for VLAN and MACVLAN devices VLAN and MACVLAN devices consider an ethernet.mac-address setting to find the parent device. This setting shall be the permanent MAC address of the device, not the current.
2016-06-15 13:43:34 +02:00
parent = find_device_by_permanent_hw_addr (self, parent_name);
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
if (parent)
return parent;
/* Maybe a connection UUID */
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
parent_connection = nm_settings_get_connection_by_uuid (priv->settings, parent_name);
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
if (!parent_connection)
return NULL;
docs: misc. typos pt2 Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
2018-09-15 07:20:54 -04:00
/* Check if the parent connection is currently activated or is compatible
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
* with some known device.
*/
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (candidate, &priv->devices_lst_head, devices_lst) {
manager: ignore unmanaged devices when looking for parent by UUID If the device is unmanaged, it is not compatible with any connection. https://mail.gnome.org/archives/networkmanager-list/2017-September/msg00032.html
2017-09-27 09:25:16 +02:00
/* Unmanaged devices are not compatible with any connection */
if (!nm_device_get_managed (candidate, FALSE))
continue;
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
if (nm_device_get_settings_connection (candidate) == parent_connection)
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
return candidate;
core: initial InfiniBand partition support
2013-06-10 17:32:23 -03:00
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
if ( !first_compatible
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
&& nm_device_check_connection_compatible (candidate,
nm_settings_connection_get_connection (parent_connection),
NULL))
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
first_compatible = candidate;
core: initial InfiniBand partition support
2013-06-10 17:32:23 -03:00
}
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
return first_compatible;
core: initial InfiniBand partition support
2013-06-10 17:32:23 -03:00
}
core: don't create virtual interfaces we already have Make sure we don't already have an NMDevice for this interface before creating it, and also when creating the interface, make a new NMDevice for it immediately to prevent a race between telling the kernel to create the interface via netlink, and when udev later tells us about it. In between there we could be triggered to try creating the interface again.
2012-02-10 13:25:39 -06:00
/**
manager: export nm_manager_get_connection_iface() We'll need the actual device name that should be used for a connection activated on a given device when checking the connection availability.
2016-02-16 15:07:49 +01:00
* nm_manager_get_connection_iface:
core: don't create virtual interfaces we already have Make sure we don't already have an NMDevice for this interface before creating it, and also when creating the interface, make a new NMDevice for it immediately to prevent a race between telling the kernel to create the interface via netlink, and when udev later tells us about it. In between there we could be triggered to try creating the interface again.
2012-02-10 13:25:39 -06:00
* @self: the #NMManager
manager: export nm_manager_get_connection_iface() We'll need the actual device name that should be used for a connection activated on a given device when checking the connection availability.
2016-02-16 15:07:49 +01:00
* @connection: the #NMConnection to get the interface for
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
* @out_parent: on success, the parent device if any
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
* @out_parent_spec: on return, a string specifying the parent device
* in the connection. This can be a device name, a MAC address or a
* connection UUID.
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
* @error: an error if determining the virtual interface name failed
core: don't create virtual interfaces we already have Make sure we don't already have an NMDevice for this interface before creating it, and also when creating the interface, make a new NMDevice for it immediately to prevent a race between telling the kernel to create the interface via netlink, and when udev later tells us about it. In between there we could be triggered to try creating the interface again.
2012-02-10 13:25:39 -06:00
*
* Given @connection, returns the interface name that the connection
manager: export nm_manager_get_connection_iface() We'll need the actual device name that should be used for a connection activated on a given device when checking the connection availability.
2016-02-16 15:07:49 +01:00
* would need to use when activated. %NULL is returned if the name
* is not specified in connection or a the name for a virtual device
* could not be generated.
core: don't create virtual interfaces we already have Make sure we don't already have an NMDevice for this interface before creating it, and also when creating the interface, make a new NMDevice for it immediately to prevent a race between telling the kernel to create the interface via netlink, and when udev later tells us about it. In between there we could be triggered to try creating the interface again.
2012-02-10 13:25:39 -06:00
*
* Returns: the expected interface name (caller takes ownership), or %NULL
*/
manager: export nm_manager_get_connection_iface() We'll need the actual device name that should be used for a connection activated on a given device when checking the connection availability.
2016-02-16 15:07:49 +01:00
char *
nm_manager_get_connection_iface (NMManager *self,
NMConnection *connection,
NMDevice **out_parent,
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
const char **out_parent_spec,
manager: export nm_manager_get_connection_iface() We'll need the actual device name that should be used for a connection activated on a given device when checking the connection availability.
2016-02-16 15:07:49 +01:00
GError **error)
core: don't create virtual interfaces we already have Make sure we don't already have an NMDevice for this interface before creating it, and also when creating the interface, make a new NMDevice for it immediately to prevent a race between telling the kernel to create the interface via netlink, and when udev later tells us about it. In between there we could be triggered to try creating the interface again.
2012-02-10 13:25:39 -06:00
{
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
NMDeviceFactory *factory;
char *iface = NULL;
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
NMDevice *parent = NULL;
core: automatically create VLAN interfaces when needed
2012-02-12 14:48:44 -06:00
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
NM_SET_OUT (out_parent, NULL);
NM_SET_OUT (out_parent_spec, NULL);
core: automatically create VLAN interfaces when needed
2012-02-12 14:48:44 -06:00
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
factory = nm_device_factory_manager_find_factory_for_connection (connection);
if (!factory) {
device: fix restricting Generic connection by interface-name NMDeviceGeneric:check_connection_compatible() doesn't check for a matching interface name. It relies on the parent implementation to do that. The parent implementation calls nm_manager_get_connection_iface(). That fails for NM_SETTING_GENERIC_SETTING_NAME, because that one has no factory. Maybe this imbalance of having no factory for the Generic device is wrong, but usually factories only match a distinct set of device types, while the generic factory would handle them all (as last resort). Without this, activating a generic connection might activate the wrong interface. (cherry picked from commit 3876b10a4749638c3dcfa7e65b12bfee8030334c)
2017-04-26 19:05:54 +02:00
if (nm_streq0 (nm_connection_get_connection_type (connection), NM_SETTING_GENERIC_SETTING_NAME)) {
/* the generic type doesn't have a factory. */
goto return_ifname_fom_connection;
}
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
g_set_error (error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_FAILED,
"NetworkManager plugin for '%s' unavailable",
nm_connection_get_connection_type (connection));
return NULL;
}
libnm-core: add nm_connection_is_virtual() Add a method to determine if a connection applies to a virtual device. Perhaps eventually the logic should be spread across the NMSetting classes, but for now it's better off having it in NMConnection than once in NMManager and once in nmcli.
2014-08-04 16:27:43 -04:00
device: optimize nm_manager_get_connection_iface()
2016-02-17 16:12:46 +01:00
if ( !out_parent
device: make NMDeviceFactory a class instead of an interface An interface would make sense to allow the actual device-factory to inherit from another type. However, glib interfaces make code much harder to follow and less efficient. The device factory shall be a very simple type with meta data about supported device types and the ability to create device instances. There is no need to make this an interface implementation, instead just let the factories inherit from NM_TYPE_DEVICE_FACTORY directly.
2016-10-07 16:05:43 +02:00
&& !NM_DEVICE_FACTORY_GET_CLASS (factory)->get_connection_iface) {
device: optimize nm_manager_get_connection_iface()
2016-02-17 16:12:46 +01:00
/* optimization. Shortcut lookup of the partent device. */
device: fix restricting Generic connection by interface-name NMDeviceGeneric:check_connection_compatible() doesn't check for a matching interface name. It relies on the parent implementation to do that. The parent implementation calls nm_manager_get_connection_iface(). That fails for NM_SETTING_GENERIC_SETTING_NAME, because that one has no factory. Maybe this imbalance of having no factory for the Generic device is wrong, but usually factories only match a distinct set of device types, while the generic factory would handle them all (as last resort). Without this, activating a generic connection might activate the wrong interface. (cherry picked from commit 3876b10a4749638c3dcfa7e65b12bfee8030334c)
2017-04-26 19:05:54 +02:00
goto return_ifname_fom_connection;
device: optimize nm_manager_get_connection_iface()
2016-02-17 16:12:46 +01:00
}
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
parent = find_parent_device_for_connection (self, connection, factory, out_parent_spec);
device-factory/trivial: rename get_virtual_iface_name() to get_connection_iface()
2016-02-17 15:11:02 +01:00
iface = nm_device_factory_get_connection_iface (factory,
connection,
parent ? nm_device_get_ip_iface (parent) : NULL,
error);
core: check generated virtual interfaceplatform name https://bugzilla.redhat.com/show_bug.cgi?id=1300755
2016-01-21 17:36:08 +01:00
if (!iface)
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
return NULL;
core: initial InfiniBand partition support
2013-06-10 17:32:23 -03:00
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
if (out_parent)
*out_parent = parent;
return iface;
device: fix restricting Generic connection by interface-name NMDeviceGeneric:check_connection_compatible() doesn't check for a matching interface name. It relies on the parent implementation to do that. The parent implementation calls nm_manager_get_connection_iface(). That fails for NM_SETTING_GENERIC_SETTING_NAME, because that one has no factory. Maybe this imbalance of having no factory for the Generic device is wrong, but usually factories only match a distinct set of device types, while the generic factory would handle them all (as last resort). Without this, activating a generic connection might activate the wrong interface. (cherry picked from commit 3876b10a4749638c3dcfa7e65b12bfee8030334c)
2017-04-26 19:05:54 +02:00
return_ifname_fom_connection:
iface = g_strdup (nm_connection_get_interface_name (connection));
if (!iface) {
g_set_error (error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_FAILED,
"failed to determine interface name: error determine name for %s",
nm_connection_get_connection_type (connection));
}
return iface;
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
}
ifcfg-rh: write the master device name even if the master property is an UUID We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the network.service did, confusing the legacy tooling. Let's do our best to write compatible configuration files: * Add *_UUID properties that won't clash with initscripts * Ignore non-*_UUID keys on read if *_UUID is present * If the connection.master is an UUID of a connection with a connection.interface-name, write the uuid into the *_UUID key while setting the non-*_UUID key to the interface name for compatibility https://bugzilla.redhat.com/show_bug.cgi?id=1369091
2016-11-28 12:32:03 +00:00
/**
* nm_manager_iface_for_uuid:
* @self: the #NMManager
* @uuid: the connection uuid
*
* Gets a link name for the given UUID. Useful for the settings plugins that
* wish to write configuration files compatible with tooling that can't
* interpret our UUIDs.
*
* Returns: An interface name; %NULL if none matches
*/
const char *
nm_manager_iface_for_uuid (NMManager *self, const char *uuid)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn;
ifcfg-rh: write the master device name even if the master property is an UUID We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the network.service did, confusing the legacy tooling. Let's do our best to write compatible configuration files: * Add *_UUID properties that won't clash with initscripts * Ignore non-*_UUID keys on read if *_UUID is present * If the connection.master is an UUID of a connection with a connection.interface-name, write the uuid into the *_UUID key while setting the non-*_UUID key to the interface name for compatibility https://bugzilla.redhat.com/show_bug.cgi?id=1369091
2016-11-28 12:32:03 +00:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn = nm_settings_get_connection_by_uuid (priv->settings, uuid);
if (!sett_conn)
ifcfg-rh: write the master device name even if the master property is an UUID We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the network.service did, confusing the legacy tooling. Let's do our best to write compatible configuration files: * Add *_UUID properties that won't clash with initscripts * Ignore non-*_UUID keys on read if *_UUID is present * If the connection.master is an UUID of a connection with a connection.interface-name, write the uuid into the *_UUID key while setting the non-*_UUID key to the interface name for compatibility https://bugzilla.redhat.com/show_bug.cgi?id=1369091
2016-11-28 12:32:03 +00:00
return NULL;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
return nm_connection_get_interface_name (nm_settings_connection_get_connection (sett_conn));
ifcfg-rh: write the master device name even if the master property is an UUID We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the network.service did, confusing the legacy tooling. Let's do our best to write compatible configuration files: * Add *_UUID properties that won't clash with initscripts * Ignore non-*_UUID keys on read if *_UUID is present * If the connection.master is an UUID of a connection with a connection.interface-name, write the uuid into the *_UUID key while setting the non-*_UUID key to the interface name for compatibility https://bugzilla.redhat.com/show_bug.cgi?id=1369091
2016-11-28 12:32:03 +00:00
}
manager: add a method to get a particular device of given type And also make the remove_device() method use it behind the scenes.
2017-10-10 15:00:59 +02:00
NMDevice *
nm_manager_get_device (NMManager *self, const char *ifname, NMDeviceType device_type)
core: implement activation of PPP devices Add code to NMPppDevice to activate new-style PPPoE connections. This is a bit tricky because we can't create the link as usual in create_and_realize(). Instead, we create a device without ifindex and start pppd in stage2; when pppd reports a new configuration, we rename the platform link to the correct name and set the ifindex into the device. This mechanism is inherently racy, but there is no way to tell pppd to create an arbitrary interface name.
2017-07-03 16:24:59 +02:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *device;
core: implement activation of PPP devices Add code to NMPppDevice to activate new-style PPPoE connections. This is a bit tricky because we can't create the link as usual in create_and_realize(). Instead, we create a device without ifindex and start pppd in stage2; when pppd reports a new configuration, we rename the platform link to the correct name and set the ifindex into the device. This mechanism is inherently racy, but there is no way to tell pppd to create an arbitrary interface name.
2017-07-03 16:24:59 +02:00
manager: add a method to get a particular device of given type And also make the remove_device() method use it behind the scenes.
2017-10-10 15:00:59 +02:00
g_return_val_if_fail (ifname, NULL);
g_return_val_if_fail (device_type != NM_DEVICE_TYPE_UNKNOWN, NULL);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
if ( nm_device_get_device_type (device) == device_type
&& nm_streq0 (nm_device_get_iface (device), ifname))
return device;
core: implement activation of PPP devices Add code to NMPppDevice to activate new-style PPPoE connections. This is a bit tricky because we can't create the link as usual in create_and_realize(). Instead, we create a device without ifindex and start pppd in stage2; when pppd reports a new configuration, we rename the platform link to the correct name and set the ifindex into the device. This mechanism is inherently racy, but there is no way to tell pppd to create an arbitrary interface name.
2017-07-03 16:24:59 +02:00
}
manager: add a method to get a particular device of given type And also make the remove_device() method use it behind the scenes.
2017-10-10 15:00:59 +02:00
return NULL;
}
gboolean
nm_manager_remove_device (NMManager *self, const char *ifname, NMDeviceType device_type)
{
NMDevice *d;
d = nm_manager_get_device (self, ifname, device_type);
if (!d)
return FALSE;
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
remove_device (self, d, FALSE);
manager: add a method to get a particular device of given type And also make the remove_device() method use it behind the scenes.
2017-10-10 15:00:59 +02:00
return TRUE;
core: implement activation of PPP devices Add code to NMPppDevice to activate new-style PPPoE connections. This is a bit tricky because we can't create the link as usual in create_and_realize(). Instead, we create a device without ifindex and start pppd in stage2; when pppd reports a new configuration, we rename the platform link to the correct name and set the ifindex into the device. This mechanism is inherently racy, but there is no way to tell pppd to create an arbitrary interface name.
2017-07-03 16:24:59 +02:00
}
core: don't create virtual interfaces we already have Make sure we don't already have an NMDevice for this interface before creating it, and also when creating the interface, make a new NMDevice for it immediately to prevent a race between telling the kernel to create the interface via netlink, and when udev later tells us about it. In between there we could be triggered to try creating the interface again.
2012-02-10 13:25:39 -06:00
/**
* system_create_virtual_device:
* @self: the #NMManager
* @connection: the connection which might require a virtual device
*
* If @connection requires a virtual device and one does not yet exist for it,
* creates that device.
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
*
* Returns: A #NMDevice that was just realized; %NULL if none
core: don't create virtual interfaces we already have Make sure we don't already have an NMDevice for this interface before creating it, and also when creating the interface, make a new NMDevice for it immediately to prevent a race between telling the kernel to create the interface via netlink, and when udev later tells us about it. In between there we could be triggered to try creating the interface again.
2012-02-10 13:25:39 -06:00
*/
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
static NMDevice *
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
system_create_virtual_device (NMManager *self, NMConnection *connection)
core: don't create virtual interfaces we already have Make sure we don't already have an NMDevice for this interface before creating it, and also when creating the interface, make a new NMDevice for it immediately to prevent a race between telling the kernel to create the interface via netlink, and when udev later tells us about it. In between there we could be triggered to try creating the interface again.
2012-02-10 13:25:39 -06:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: let device plugins advertise supported link and setting types Instead of looping over all plugins and asking each plugin whether it can handle a link or a connection, have them advertise the link and connection types they support, and use that when creating new devices.
2014-09-17 14:17:30 -05:00
NMDeviceFactory *factory;
core: refactor nm_settings_get_connections_sorted() to return array instead of GSList We call these functions a lot. A GSList is just the wrong tool for the job. Refactor the code to use instead a sorted array everywhere. This means, we malloc() one array for all connections instead slice-allocate a GSList item for each. Also, sorting an array is faster then sorting a GSList. Technically, the GSList implementation had the same big-O runtime complexity, but using an array is still faster. That is, sorting an array and a GSList is both O(n*log(n)). Actually, nm_settings_get_connections_sorted() used g_slist_insert_sorted() instead of g_slist_sort(). That results in O(n^2). That could have been fixed to have O(n*log(n)), but instead refactor the code to use an array.
2017-02-03 14:15:16 +01:00
gs_free NMSettingsConnection **connections = NULL;
guint i;
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
gs_free char *iface = NULL;
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
const char *parent_spec;
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
NMDevice *device = NULL, *parent = NULL;
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *dev_candidate;
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
GError *error = NULL;
manager: downgrade error message for missing dependencies At startup the manager tries to create virtual devices without a specific order and spits warnings when a device can't be realized because the parent device is not yet created. These failures are not something the user should worry about because the creation will be retried when the parent appears. A better approach is to return an error code from the device's create_and_realize() telling that it failed because the parent doesn't exist. In this way, the manager knows that the device isn't ready and can avoid printing warning messages.
2017-09-14 09:26:51 +02:00
NMLogLevel log_level;
core: don't create virtual interfaces we already have Make sure we don't already have an NMDevice for this interface before creating it, and also when creating the interface, make a new NMDevice for it immediately to prevent a race between telling the kernel to create the interface via netlink, and when udev later tells us about it. In between there we could be triggered to try creating the interface again.
2012-02-10 13:25:39 -06:00
manager: return values for a non-void function Fixes: d8e1590c5058de91126bfa790c27aea944a2b596
2015-12-18 12:09:38 +01:00
g_return_val_if_fail (NM_IS_MANAGER (self), NULL);
g_return_val_if_fail (NM_IS_CONNECTION (connection), NULL);
core: show better error for software device creation failures (rh #1182923) https://bugzilla.redhat.com/show_bug.cgi?id=1182923
2015-01-19 13:11:29 +01:00
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
iface = nm_manager_get_connection_iface (self, connection, &parent, &parent_spec, &error);
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
if (!iface) {
manager: add logging macro _NMLOG3() for logging connection messages It unifies the way how we print the logging prefix, but also it passes the con_uuid down for structured logging.
2017-06-07 12:46:10 +02:00
_LOG3D (LOGD_DEVICE, connection, "can't get a name of a virtual device: %s",
error->message);
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
g_error_free (error);
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
return NULL;
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
}
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
if (parent_spec && !parent) {
/* parent is not ready, wait */
return NULL;
}
manager: if there's an unrealized device that matches new connection, realize it 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
2015-12-11 15:40:34 +01:00
/* See if there's a device that is already compatible with this connection */
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (dev_candidate, &priv->devices_lst_head, devices_lst) {
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
if (nm_device_check_connection_compatible (dev_candidate, connection, NULL)) {
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
if (nm_device_is_real (dev_candidate)) {
manager: add logging macro _NMLOG3() for logging connection messages It unifies the way how we print the logging prefix, but also it passes the con_uuid down for structured logging.
2017-06-07 12:46:10 +02:00
_LOG3D (LOGD_DEVICE, connection, "already created virtual interface name %s",
iface);
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
return NULL;
manager: if there's an unrealized device that matches new connection, realize it 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
2015-12-11 15:40:34 +01:00
}
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
device = dev_candidate;
manager: if there's an unrealized device that matches new connection, realize it 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
2015-12-11 15:40:34 +01:00
break;
core: show better error for software device creation failures (rh #1182923) https://bugzilla.redhat.com/show_bug.cgi?id=1182923
2015-01-19 13:11:29 +01:00
}
core: don't create virtual interfaces we already have Make sure we don't already have an NMDevice for this interface before creating it, and also when creating the interface, make a new NMDevice for it immediately to prevent a race between telling the kernel to create the interface via netlink, and when udev later tells us about it. In between there we could be triggered to try creating the interface again.
2012-02-10 13:25:39 -06:00
}
manager: if there's an unrealized device that matches new connection, realize it 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
2015-12-11 15:40:34 +01:00
if (!device) {
/* No matching device found. Proceed creating a new one. */
factory = nm_device_factory_manager_find_factory_for_connection (connection);
if (!factory) {
manager: add logging macro _NMLOG3() for logging connection messages It unifies the way how we print the logging prefix, but also it passes the con_uuid down for structured logging.
2017-06-07 12:46:10 +02:00
_LOG3E (LOGD_DEVICE, connection, "(%s) NetworkManager plugin for '%s' unavailable",
iface,
manager: use logging helpers
2016-03-02 11:38:26 +01:00
nm_connection_get_connection_type (connection));
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
return NULL;
manager: if there's an unrealized device that matches new connection, realize it 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
2015-12-11 15:40:34 +01:00
}
core: let device plugins advertise supported link and setting types Instead of looping over all plugins and asking each plugin whether it can handle a link or a connection, have them advertise the link and connection types they support, and use that when creating new devices.
2014-09-17 14:17:30 -05:00
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
device = nm_device_factory_create_device (factory, iface, NULL, connection, NULL, &error);
if (!device) {
manager: add logging macro _NMLOG3() for logging connection messages It unifies the way how we print the logging prefix, but also it passes the con_uuid down for structured logging.
2017-06-07 12:46:10 +02:00
_LOG3W (LOGD_DEVICE, connection, "factory can't create the device: %s",
error->message);
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
g_error_free (error);
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
return NULL;
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
}
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
manager: add logging macro _NMLOG3() for logging connection messages It unifies the way how we print the logging prefix, but also it passes the con_uuid down for structured logging.
2017-06-07 12:46:10 +02:00
_LOG3D (LOGD_DEVICE, connection, "create virtual device %s",
core: downgrade warning logging message when creating virtual device This can regularly happen when a virtual device depends on a parent/master that is not yet created. We will retry later when the parent is ready, so logging a warning about it is wrong and confusing.
2016-03-29 15:39:05 +02:00
nm_device_get_iface (device));
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
if (!add_device (self, device, &error)) {
manager: add logging macro _NMLOG3() for logging connection messages It unifies the way how we print the logging prefix, but also it passes the con_uuid down for structured logging.
2017-06-07 12:46:10 +02:00
_LOG3W (LOGD_DEVICE, connection, "can't register the device with manager: %s",
error->message);
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
g_error_free (error);
manager: if there's an unrealized device that matches new connection, realize it 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
2015-12-11 15:40:34 +01:00
g_object_unref (device);
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
return NULL;
manager: if there's an unrealized device that matches new connection, realize it 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
2015-12-11 15:40:34 +01:00
}
/* Add device takes a reference that NMManager still owns, so it's
* safe to unref here and still return @device.
*/
manager: improve the add_device() error handling a bit Let it indicate that it didn't succeed adding a device to the global list and bail out.
2015-12-08 14:51:56 +01:00
g_object_unref (device);
}
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
core: don't realize unmanaged software devices Currently, if user configuration or settings specify that a software device is unmanaged, for example: [device-bond-unmanaged] match-device=interface-name:bond* managed=0 or [keyfile] unmanaged-devices=interface-name:bond* and there is a connection for the device with autoconnect=yes, NM creates the platform link and a realized device in unmanaged state. Fix this, the device should not be realized if it is unmanaged. https://bugzilla.redhat.com/show_bug.cgi?id=1679230
2019-04-08 09:26:05 +02:00
if (!nm_device_check_unrealized_device_managed (device)) {
_LOG3D (LOGD_DEVICE, connection,
"skip activation because virtual device '%s' is unmanaged",
nm_device_get_iface (device));
return device;
}
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
/* Create backing resources if the device has any autoconnect connections */
core: merge nm_settings_get_connections_sorted() with nm_settings_get_connections_clone()
2017-11-22 12:46:58 +01:00
connections = nm_settings_get_connections_clone (priv->settings, NULL,
NULL, NULL,
nm_settings_connection_cmp_autoconnect_priority_p_with_data, NULL);
core: refactor nm_settings_get_connections_sorted() to return array instead of GSList We call these functions a lot. A GSList is just the wrong tool for the job. Refactor the code to use instead a sorted array everywhere. This means, we malloc() one array for all connections instead slice-allocate a GSList item for each. Also, sorting an array is faster then sorting a GSList. Technically, the GSList implementation had the same big-O runtime complexity, but using an array is still faster. That is, sorting an array and a GSList is both O(n*log(n)). Actually, nm_settings_get_connections_sorted() used g_slist_insert_sorted() instead of g_slist_sort(). That results in O(n^2). That could have been fixed to have O(n*log(n)), but instead refactor the code to use an array.
2017-02-03 14:15:16 +01:00
for (i = 0; connections[i]; i++) {
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMConnection *candidate = nm_settings_connection_get_connection (connections[i]);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
NMSettingConnection *s_con;
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
if (!nm_device_check_connection_compatible (device, candidate, NULL))
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
continue;
s_con = nm_connection_get_setting_connection (candidate);
g_assert (s_con);
if (!nm_setting_connection_get_autoconnect (s_con))
continue;
manager: do not create software devices when device was manually disconnected 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).
2013-12-04 15:58:32 +01:00
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
/* Create any backing resources the device needs */
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
if (!nm_device_create_and_realize (device, connection, parent, &error)) {
manager: downgrade error message for missing dependencies At startup the manager tries to create virtual devices without a specific order and spits warnings when a device can't be realized because the parent device is not yet created. These failures are not something the user should worry about because the creation will be retried when the parent appears. A better approach is to return an error code from the device's create_and_realize() telling that it failed because the parent doesn't exist. In this way, the manager knows that the device isn't ready and can avoid printing warning messages.
2017-09-14 09:26:51 +02:00
log_level = g_error_matches (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_MISSING_DEPENDENCIES)
? LOGL_DEBUG
: LOGL_ERR;
_NMLOG3 (log_level, LOGD_DEVICE, connection,
"couldn't create the device: %s",
error->message);
manager: clean up the system_create_virtual_device() error handling 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.
2015-12-11 16:13:13 +01:00
g_error_free (error);
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
return NULL;
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
}
manager: try other connections only after the device is realized After a device is created in system_create_virtual_device(), the manager tries to activate connections that depend on the device even if the device isn't realized, as in the following log: # team0 gets created <info> manager: (team0): new Team device (/org/freedesktop/NetworkManager/Devices/7) # team0.23 gets created <debug> device[0x28079b0] (team0.23): constructed (NMDeviceVlan) <debug> manager: (team0-vlan23) create virtual device team0.23 <debug> device[0x28079b0] (team0.23): unmanaged: flags set to [platform-init,!sleeping=0x10/0x11/unmanaged/unrealized], set-managed [sleeping <info> manager: (team0.23): new VLAN device (/org/freedesktop/NetworkManager/Devices/8) # the manager tries to realize team0.23 <debug> device[0x28079b0] (team0.23): create (is nm-owned) <warn> manager: (team0-vlan23) couldn't create the device: cannot retrieve ifindex of interface team0 (Team): skip VLAN creation for now <debug> manager: (team0.23): removing device (allow_unmanage 1, managed 0) <debug> device[0x28079b0] (team0.23): ip4-config: update (commit=0, new-config=(nil)) <debug> device[0x28079b0] (team0.23): ip6-config: update (commit=0, new-config=(nil)) <debug> device[0x28079b0] (team0.23): disposing <debug> device[0x28079b0] (team0.23): ip4-config: update (commit=1, new-config=(nil)) <debug> device[0x28079b0] (team0.23): ip6-config: update (commit=1, new-config=(nil)) <debug> device[0x28079b0] (team0.23): finalize(): NMDeviceVlan # the manager realizes team0 <debug> device[0x2800870] (team0): create (is nm-owned) <debug> platform: link: add link 'team0' of type 'team' (196610) Change the order of operations and try the child connection only after the parent has been realized.
2017-09-13 18:38:59 +02:00
retry_connections_for_parent_device (self, device);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
break;
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
}
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
return device;
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
}
manager: retry virtual connections when a device is added or changes 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 d8e1590c5058 ("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
2016-01-07 17:54:38 +01:00
static void
retry_connections_for_parent_device (NMManager *self, NMDevice *device)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: refactor nm_settings_get_connections_sorted() to return array instead of GSList We call these functions a lot. A GSList is just the wrong tool for the job. Refactor the code to use instead a sorted array everywhere. This means, we malloc() one array for all connections instead slice-allocate a GSList item for each. Also, sorting an array is faster then sorting a GSList. Technically, the GSList implementation had the same big-O runtime complexity, but using an array is still faster. That is, sorting an array and a GSList is both O(n*log(n)). Actually, nm_settings_get_connections_sorted() used g_slist_insert_sorted() instead of g_slist_sort(). That results in O(n^2). That could have been fixed to have O(n*log(n)), but instead refactor the code to use an array.
2017-02-03 14:15:16 +01:00
gs_free NMSettingsConnection **connections = NULL;
guint i;
manager: retry virtual connections when a device is added or changes 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 d8e1590c5058 ("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
2016-01-07 17:54:38 +01:00
g_return_if_fail (device);
core: merge nm_settings_get_connections_sorted() with nm_settings_get_connections_clone()
2017-11-22 12:46:58 +01:00
connections = nm_settings_get_connections_clone (priv->settings, NULL,
NULL, NULL,
nm_settings_connection_cmp_autoconnect_priority_p_with_data, NULL);
core: refactor nm_settings_get_connections_sorted() to return array instead of GSList We call these functions a lot. A GSList is just the wrong tool for the job. Refactor the code to use instead a sorted array everywhere. This means, we malloc() one array for all connections instead slice-allocate a GSList item for each. Also, sorting an array is faster then sorting a GSList. Technically, the GSList implementation had the same big-O runtime complexity, but using an array is still faster. That is, sorting an array and a GSList is both O(n*log(n)). Actually, nm_settings_get_connections_sorted() used g_slist_insert_sorted() instead of g_slist_sort(). That results in O(n^2). That could have been fixed to have O(n*log(n)), but instead refactor the code to use an array.
2017-02-03 14:15:16 +01:00
for (i = 0; connections[i]; i++) {
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn = connections[i];
NMConnection *connection = nm_settings_connection_get_connection (sett_conn);
manager: fix assumption of child connections with autoconnect=no During startup, when a link is detected (enp0s25 in the example below) we try to create also virtual devices (ipip1) on it through system_create_virtual_device(), however this realizes only devices for connections which can autoactivate. To support the assumption of child devices with autoconnect=no, we should take in consideration in retry_connections_for_parent_device() only connections for which the link does not exist, and let existing links be handled by platform_link_added(), which also realizes them. Reproducer: $ nmcli c add type ip-tunnel ifname ipip1 con-name ipip1+ autoconnect no \ mode ipip remote 172.25.16.1 dev enp0s25 ip4 1.2.3.4/31 $ nmcli c up ipip1+ $ systemctl restart NetworkManager Result: * before: ipip1+ is not assumed, ipip1 is not present in 'nmcli d' output * after: ipip1+ is assumed, ipip1 detected
2016-03-08 12:02:54 +01:00
gs_free_error GError *error = NULL;
gs_free char *ifname = NULL;
manager: retry virtual connections when a device is added or changes 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 d8e1590c5058 ("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
2016-01-07 17:54:38 +01:00
NMDevice *parent;
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
parent = find_parent_device_for_connection (self, connection, NULL, NULL);
manager: fix assumption of child connections with autoconnect=no During startup, when a link is detected (enp0s25 in the example below) we try to create also virtual devices (ipip1) on it through system_create_virtual_device(), however this realizes only devices for connections which can autoactivate. To support the assumption of child devices with autoconnect=no, we should take in consideration in retry_connections_for_parent_device() only connections for which the link does not exist, and let existing links be handled by platform_link_added(), which also realizes them. Reproducer: $ nmcli c add type ip-tunnel ifname ipip1 con-name ipip1+ autoconnect no \ mode ipip remote 172.25.16.1 dev enp0s25 ip4 1.2.3.4/31 $ nmcli c up ipip1+ $ systemctl restart NetworkManager Result: * before: ipip1+ is not assumed, ipip1 is not present in 'nmcli d' output * after: ipip1+ is assumed, ipip1 detected
2016-03-08 12:02:54 +01:00
if (parent == device) {
/* Only try to activate devices that don't already exist */
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
ifname = nm_manager_get_connection_iface (self, connection, &parent, NULL, &error);
manager: fix assumption of child connections with autoconnect=no During startup, when a link is detected (enp0s25 in the example below) we try to create also virtual devices (ipip1) on it through system_create_virtual_device(), however this realizes only devices for connections which can autoactivate. To support the assumption of child devices with autoconnect=no, we should take in consideration in retry_connections_for_parent_device() only connections for which the link does not exist, and let existing links be handled by platform_link_added(), which also realizes them. Reproducer: $ nmcli c add type ip-tunnel ifname ipip1 con-name ipip1+ autoconnect no \ mode ipip remote 172.25.16.1 dev enp0s25 ip4 1.2.3.4/31 $ nmcli c up ipip1+ $ systemctl restart NetworkManager Result: * before: ipip1+ is not assumed, ipip1 is not present in 'nmcli d' output * after: ipip1+ is assumed, ipip1 detected
2016-03-08 12:02:54 +01:00
if (ifname) {
if (!nm_platform_link_get_by_ifname (NM_PLATFORM_GET, ifname))
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
connection_changed (self, sett_conn);
manager: fix assumption of child connections with autoconnect=no During startup, when a link is detected (enp0s25 in the example below) we try to create also virtual devices (ipip1) on it through system_create_virtual_device(), however this realizes only devices for connections which can autoactivate. To support the assumption of child devices with autoconnect=no, we should take in consideration in retry_connections_for_parent_device() only connections for which the link does not exist, and let existing links be handled by platform_link_added(), which also realizes them. Reproducer: $ nmcli c add type ip-tunnel ifname ipip1 con-name ipip1+ autoconnect no \ mode ipip remote 172.25.16.1 dev enp0s25 ip4 1.2.3.4/31 $ nmcli c up ipip1+ $ systemctl restart NetworkManager Result: * before: ipip1+ is not assumed, ipip1 is not present in 'nmcli d' output * after: ipip1+ is assumed, ipip1 detected
2016-03-08 12:02:54 +01:00
}
}
manager: retry virtual connections when a device is added or changes 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 d8e1590c5058 ("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
2016-01-07 17:54:38 +01:00
}
}
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
static void
settings: merge "connection-updated" and "connection-updated-by-user" signals This is mostly interesting of NMPolicy, which no longer needs to subscribe to two almost identical signals (where the by-user signal was always invoked together with the plain "updated" signal).
2016-04-13 16:03:06 +02:00
connection_changed (NMManager *self,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn)
2008-04-29 Dan Williams <dcbw@redhat.com> Handle HAL dropouts better; allow NM to start up even if HAL isn't up yet. * marshallers/nm-marshal.list - Add marshaller * src/NetworkManager.c - (main): let the NMManager handle the NMHalManager * src/nm-hal-manager.c src/nm-hal-manager.h - convert to a GObject, and emit singals when stuff changes. Let the NMManager handle the signals, instead of the NMHalManager calling into the NMManager. * src/nm-manager.c src/nm-manager.h - (remove_one_device): consolidate device removals here - (dispose): use remove_one_device() - (nm_manager_get_device_by_udi): make static - (deferred_hal_manager_query_devices): idle handler to query the HAL manager for devices at startup or wakeup time - (nm_manager_new): create and monitor the HAL manager - (hal_manager_udi_added_cb): new function; do what nm_manager_add_device() used to do when signalled by the hal manager - (hal_manager_udi_removed_cb): new function; do what nm_manager_remove_device() used to do when signalled by the hal manager - (hal_manager_rfkill_changed_cb): handle rfkill changes from the hal manager - (hal_manager_hal_reappeared_cb): when HAL comes back, remove devices in our device list that aren't known to HAL - (impl_manager_sleep): on wakeup, re-add devices from an idle handler; see comments on nm-hal-manager.c::nm_manager_state_changed() a few commits ago - (nm_manager_get_device_by_path, nm_manager_is_udi_managed, nm_manager_activation_pending, nm_manager_wireless_enabled, nm_manager_wireless_hardware_enabled, nm_manager_set_wireless_hardware_enabled): remove, unused git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3619 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 23:03:00 +00:00
{
core: create virtual device on settings changes in idle handler The callback from NMSettings about adding/updating a settings comes from a deep call-stack already. We don't know the context of it, and we shouldn't just right away create the profile. Instead, schedule an action to create it in an idle handler.
2019-06-30 10:33:28 +02:00
NMManagerPrivate *priv;
manager: don't consider by-user change flag for creating unrealized device This effectively reverts commit [1]. The by-user argument is not very clear what it means. Is a "nmcli connection load $FILENAME" a user-action? How about reload? I don't know whether the problem that this was supposed to fix is still present. But in any case, the condition here seems not right. It's already hard to understand when and how we generate unrealized devices. If the condition from commit [1] should be prevented, then it must happen somehow differently. In the example, the offending connection is a generated volatile profile with the device being sys-face-state "external". Of course, we should not generate devices for such profiles nor autoactivating them. So adding a device for a volatile connection is always wrong. Don't do that, which should avoid the original problem. [1] commit a8a4eb14183b ('manager: don't create the virtual devices on all connection changes')
2019-06-20 09:07:45 +02:00
NMConnection *connection;
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
NMDevice *device;
manager: don't consider by-user change flag for creating unrealized device This effectively reverts commit [1]. The by-user argument is not very clear what it means. Is a "nmcli connection load $FILENAME" a user-action? How about reload? I don't know whether the problem that this was supposed to fix is still present. But in any case, the condition here seems not right. It's already hard to understand when and how we generate unrealized devices. If the condition from commit [1] should be prevented, then it must happen somehow differently. In the example, the offending connection is a generated volatile profile with the device being sys-face-state "external". Of course, we should not generate devices for such profiles nor autoactivating them. So adding a device for a volatile connection is always wrong. Don't do that, which should avoid the original problem. [1] commit a8a4eb14183b ('manager: don't create the virtual devices on all connection changes')
2019-06-20 09:07:45 +02:00
if (NM_FLAGS_HAS (nm_settings_connection_get_flags (sett_conn),
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE))
return;
core: create virtual device on settings changes in idle handler The callback from NMSettings about adding/updating a settings comes from a deep call-stack already. We don't know the context of it, and we shouldn't just right away create the profile. Instead, schedule an action to create it in an idle handler.
2019-06-30 10:33:28 +02:00
priv = NM_MANAGER_GET_PRIVATE (self);
if (!nm_settings_has_connection (priv->settings, sett_conn))
return;
manager: don't consider by-user change flag for creating unrealized device This effectively reverts commit [1]. The by-user argument is not very clear what it means. Is a "nmcli connection load $FILENAME" a user-action? How about reload? I don't know whether the problem that this was supposed to fix is still present. But in any case, the condition here seems not right. It's already hard to understand when and how we generate unrealized devices. If the condition from commit [1] should be prevented, then it must happen somehow differently. In the example, the offending connection is a generated volatile profile with the device being sys-face-state "external". Of course, we should not generate devices for such profiles nor autoactivating them. So adding a device for a volatile connection is always wrong. Don't do that, which should avoid the original problem. [1] commit a8a4eb14183b ('manager: don't create the virtual devices on all connection changes')
2019-06-20 09:07:45 +02:00
connection = nm_settings_connection_get_connection (sett_conn);
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
if (!nm_connection_is_virtual (connection))
return;
settings: merge "connection-updated" and "connection-updated-by-user" signals This is mostly interesting of NMPolicy, which no longer needs to subscribe to two almost identical signals (where the by-user signal was always invoked together with the plain "updated" signal).
2016-04-13 16:03:06 +02:00
device = system_create_virtual_device (self, connection);
manager: retry device creation for connection that would use a newly created device The VLANs (unrealized) can depend on the devices that are not around yet. We need to retry their creation when the potential parents appear.
2015-12-17 18:40:36 +01:00
if (!device)
return;
/* Maybe the device that was created was needed by some other
* connection's device (parent of a VLAN). Let the connections
* can use the newly created device as a parent know. */
settings: merge "connection-updated" and "connection-updated-by-user" signals This is mostly interesting of NMPolicy, which no longer needs to subscribe to two almost identical signals (where the by-user signal was always invoked together with the plain "updated" signal).
2016-04-13 16:03:06 +02:00
retry_connections_for_parent_device (self, device);
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
}
core: create virtual device on settings changes in idle handler The callback from NMSettings about adding/updating a settings comes from a deep call-stack already. We don't know the context of it, and we shouldn't just right away create the profile. Instead, schedule an action to create it in an idle handler.
2019-06-30 10:33:28 +02:00
static gboolean
connection_changed_on_idle_cb (gpointer user_data)
{
NMManager *self = user_data;
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMCListElem *elem;
priv->connection_changed_on_idle_id = 0;
while ((elem = c_list_first_entry (&priv->connection_changed_on_idle_lst, NMCListElem, lst))) {
gs_unref_object NMSettingsConnection *sett_conn = NULL;
sett_conn = nm_c_list_elem_free_steal (elem);
connection_changed (self, sett_conn);
}
return G_SOURCE_REMOVE;
}
static void
connection_changed_on_idle (NMManager *self,
NMSettingsConnection *sett_conn)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
if (priv->connection_changed_on_idle_id == 0)
priv->connection_changed_on_idle_id = g_idle_add (connection_changed_on_idle_cb, self);
shared: add nm_c_list_elem_find_first() helper macro - add nm_c_list_elem_find_first() macro that takes a predicate and returns the first match. This macro has a non-function-like behavior, which we often try to avoid because macros should behave like functions. In this case it's however convenient, so let's do it. Also, despite being non-function-like, it should be pretty hard to use wrongly. - rename nm_c_list_elem_find_first() to nm_c_list_elem_find_first_ptr().
2019-08-03 19:24:12 +02:00
if (!nm_c_list_elem_find_first_ptr (&priv->connection_changed_on_idle_lst, sett_conn)) {
core: create virtual device on settings changes in idle handler The callback from NMSettings about adding/updating a settings comes from a deep call-stack already. We don't know the context of it, and we shouldn't just right away create the profile. Instead, schedule an action to create it in an idle handler.
2019-06-30 10:33:28 +02:00
c_list_link_tail (&priv->connection_changed_on_idle_lst,
&nm_c_list_elem_new_stale (g_object_ref (sett_conn))->lst);
}
}
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
static void
settings: merge "connection-updated" and "connection-updated-by-user" signals This is mostly interesting of NMPolicy, which no longer needs to subscribe to two almost identical signals (where the by-user signal was always invoked together with the plain "updated" signal).
2016-04-13 16:03:06 +02:00
connection_added_cb (NMSettings *settings,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
settings: merge "connection-updated" and "connection-updated-by-user" signals This is mostly interesting of NMPolicy, which no longer needs to subscribe to two almost identical signals (where the by-user signal was always invoked together with the plain "updated" signal).
2016-04-13 16:03:06 +02:00
NMManager *self)
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
{
core: create virtual device on settings changes in idle handler The callback from NMSettings about adding/updating a settings comes from a deep call-stack already. We don't know the context of it, and we shouldn't just right away create the profile. Instead, schedule an action to create it in an idle handler.
2019-06-30 10:33:28 +02:00
connection_changed_on_idle (self, sett_conn);
settings: merge "connection-updated" and "connection-updated-by-user" signals This is mostly interesting of NMPolicy, which no longer needs to subscribe to two almost identical signals (where the by-user signal was always invoked together with the plain "updated" signal).
2016-04-13 16:03:06 +02:00
}
static void
connection_updated_cb (NMSettings *settings,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
guint update_reason_u,
settings: merge "connection-updated" and "connection-updated-by-user" signals This is mostly interesting of NMPolicy, which no longer needs to subscribe to two almost identical signals (where the by-user signal was always invoked together with the plain "updated" signal).
2016-04-13 16:03:06 +02:00
NMManager *self)
{
core: create virtual device on settings changes in idle handler The callback from NMSettings about adding/updating a settings comes from a deep call-stack already. We don't know the context of it, and we shouldn't just right away create the profile. Instead, schedule an action to create it in an idle handler.
2019-06-30 10:33:28 +02:00
connection_changed_on_idle (self, sett_conn);
2008-05-22 Tambet Ingo <tambet@gmail.com> Don't remove all devices on waking up, sync with HAL. * src/nm-manager.c (nm_manager_udi_is_managed): Implement. (sync_devices): Implement, based on hal_manager_hal_reappeared_cb. (hal_manager_hal_reappeared_cb): Just call sync_devices. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3680 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-05-22 14:22:31 +00:00
}
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
/*****************************************************************************/
static void
_delete_volatile_connection_all (NMManager *self, gboolean do_delete)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
settings: use NMCListElem instead of DeleteVolatileConnectionData for tracking connections to delete For tracking a CList of one pointer we have NMCListElem API. We don't need to implement our own struct to hold the list pointers and the data pointer.
2019-06-20 17:12:48 +02:00
NMCListElem *elem;
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
settings: use NMCListElem instead of DeleteVolatileConnectionData for tracking connections to delete For tracking a CList of one pointer we have NMCListElem API. We don't need to implement our own struct to hold the list pointers and the data pointer.
2019-06-20 17:12:48 +02:00
while ((elem = c_list_first_entry (&priv->delete_volatile_connection_lst_head, NMCListElem, lst))) {
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
gs_unref_object NMSettingsConnection *connection = NULL;
core: use nm_c_list_elem_free_steal() in _delete_volatile_connection_all ()
2019-07-02 16:25:33 +02:00
connection = nm_c_list_elem_free_steal (elem);
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
if (do_delete)
_delete_volatile_connection_do (self, connection);
}
}
static gboolean
_delete_volatile_connection_cb (gpointer user_data)
{
NMManager *self = user_data;
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
priv->delete_volatile_connection_idle_id = 0;
_delete_volatile_connection_all (self, TRUE);
return G_SOURCE_REMOVE;
}
static void
connection_flags_changed (NMSettings *settings,
NMSettingsConnection *connection,
gpointer user_data)
{
NMManager *self = user_data;
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
if (!NM_FLAGS_HAS (nm_settings_connection_get_flags (connection),
core/trivial: rename "NMSettingsConnectionFlags" to "NMSettingsConnectionIntFlags" "NMSettingsConnectionFlags" was an internal enum. Soon, we will add such a type in libnm. Avoid the naming conflict by renaming. The "Int" stands for "internal".
2018-04-05 20:02:45 +02:00
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE))
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
return;
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
if (active_connection_find (self, connection, NULL, NM_ACTIVE_CONNECTION_STATE_DEACTIVATED, NULL)) {
core: don't consider deactivating active-connection when checking for concurrent activations At various places we check whether we have an active-connection already. For example, when activating a new connection in _internal_activate_device(), we might want to "nm_device_steal_connection()" if the same profile is already active. However, the max-state argument was not accurate in several cases. For the purpose of finding concurrent activations, we don't care about active-connections that are already in state DEACTIVATING. Only those that are ACTIVATED or before.
2018-04-19 15:42:27 +02:00
/* the connection still has an active-connection. It will be purged
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
* when the active connection(s) get(s) removed. */
return;
}
settings: use NMCListElem instead of DeleteVolatileConnectionData for tracking connections to delete For tracking a CList of one pointer we have NMCListElem API. We don't need to implement our own struct to hold the list pointers and the data pointer.
2019-06-20 17:12:48 +02:00
c_list_link_tail (&priv->delete_volatile_connection_lst_head,
&nm_c_list_elem_new_stale (g_object_ref (connection))->lst);
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
if (!priv->delete_volatile_connection_idle_id)
priv->delete_volatile_connection_idle_id = g_idle_add (_delete_volatile_connection_cb, self);
}
/*****************************************************************************/
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
static void
settings: rename NMSysconfigSettings to NMSettings
2010-10-27 20:05:23 -05:00
system_unmanaged_devices_changed_cb (NMSettings *settings,
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
GParamSpec *pspec,
gpointer user_data)
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
{
settings: rename NMSysconfigSettings to NMSettings
2010-10-27 20:05:23 -05:00
NMManager *self = NM_MANAGER (user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *device;
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst)
nm_device_set_unmanaged_by_user_settings (device);
2008-09-18 Dan Williams <dcbw@redhat.com> Implement support for honoring configured and automatic hostnames, and for setting the configured hostname. * introspection/nm-ip4-config.xml src/nm-ip4-config.c src/nm-ip4-config.h src/dhcp-manager/nm-dhcp-manager.c - Remove useless hostname property; it's not really part of the IPv4 config * introspection/nm-settings-system.xml libnm-glib/nm-dbus-settings-system.c libnm-glib/nm-dbus-settings-system.h - Add SetHostname() call to system settings D-Bus interface - Add Hostname property to system settings D-Bus interface - (nm_dbus_settings_system_save_hostname, nm_dbus_settings_system_get_hostname): implement * src/nm-device.c src/nm-device.h - (nm_device_get_dhcp4_config): implement * src/nm-manager.c src/nm-manager.h - Fetch and track system settings service hostname changes, and proxy the changes via a GObject property of the manager * system-settings/src/nm-system-config-interface.c system-settings/src/nm-system-config-interface.h - Replace nm_system_config_interface_supports_add() with a capabilities bitfield * system-settings/src/nm-system-config-error.c system-settings/src/nm-system-config-error.h - Add additional errors * system-settings/src/dbus-settings.c system-settings/src/dbus-settings.h - (get_property, nm_sysconfig_settings_class_init): add hostname property; first plugin returning a hostname wins - (impl_settings_add_connection): use plugin capabilities instead of nm_system_config_interface_supports_add() - (impl_settings_save_hostname): implement hostname saving * src/NetworkManagerPolicy.c - (lookup_thread_run_cb, lookup_thread_worker, lookup_thread_new, lookup_thread_die): implement an asynchronous hostname lookup thread which given an IPv4 address tries to look up the hostname for that address with reverse DNS - (get_best_device): split out best device code from update_routing_and_dns() - (update_etc_hosts): update /etc/hosts with the machine's new hostname to preserve the 127.0.0.1 reverse mapping that so many things require - (set_system_hostname): set a given hostname - (update_system_hostname): implement hostname policy; a configured hostname (from the system settings service) is used if available, otherwise an automatically determined hostname from DHCP, VPN, etc. If there was no automatically determined hostname, reverse DNS of the best device's IP address will be used, and as a last resort the hostname 'localhost.localdomain' is set. - (update_routing_and_dns): use get_best_device(); update the system hostname when the network config changes - (hostname_changed): update system hostname if the system settings service signals a hostname change - (nm_policy_new): list for system settings service hostname changes - (nm_policy_destroy): ensure that an in-progress hostname lookup thread gets told to die * system-settings/plugins/keyfile/plugin.c system-settings/plugins/ifcfg-suse/plugin.c - (get_property, sc_plugin_ifcfg_class_init): implement hostname and capabilities properties * system-settings/plugins/ifcfg-fedora/shvar.c - (svOpenFile): re-enable R/W access of ifcfg files since the plugin writes out /etc/sysconfig/network now * system-settings/plugins/ifcfg-fedora/plugin.c - (plugin_get_hostname): get hostname from /etc/sysconfig/network - (plugin_set_hostname): save hostname to /etc/sysconfig/network - (sc_network_changed_cb): handle changes to /etc/sysconfig/network - (sc_plugin_ifcfg_init): monitor /etc/sysconfig/network for changes - (get_property, set_property, sc_plugin_ifcfg_class_init): implement hostname get/set and capabilities get git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4077 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-09-18 15:16:44 +00:00
}
static void
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
hostname_changed_cb (NMHostnameManager *hostname_manager,
GParamSpec *pspec,
NMManager *self)
2008-09-18 Dan Williams <dcbw@redhat.com> Implement support for honoring configured and automatic hostnames, and for setting the configured hostname. * introspection/nm-ip4-config.xml src/nm-ip4-config.c src/nm-ip4-config.h src/dhcp-manager/nm-dhcp-manager.c - Remove useless hostname property; it's not really part of the IPv4 config * introspection/nm-settings-system.xml libnm-glib/nm-dbus-settings-system.c libnm-glib/nm-dbus-settings-system.h - Add SetHostname() call to system settings D-Bus interface - Add Hostname property to system settings D-Bus interface - (nm_dbus_settings_system_save_hostname, nm_dbus_settings_system_get_hostname): implement * src/nm-device.c src/nm-device.h - (nm_device_get_dhcp4_config): implement * src/nm-manager.c src/nm-manager.h - Fetch and track system settings service hostname changes, and proxy the changes via a GObject property of the manager * system-settings/src/nm-system-config-interface.c system-settings/src/nm-system-config-interface.h - Replace nm_system_config_interface_supports_add() with a capabilities bitfield * system-settings/src/nm-system-config-error.c system-settings/src/nm-system-config-error.h - Add additional errors * system-settings/src/dbus-settings.c system-settings/src/dbus-settings.h - (get_property, nm_sysconfig_settings_class_init): add hostname property; first plugin returning a hostname wins - (impl_settings_add_connection): use plugin capabilities instead of nm_system_config_interface_supports_add() - (impl_settings_save_hostname): implement hostname saving * src/NetworkManagerPolicy.c - (lookup_thread_run_cb, lookup_thread_worker, lookup_thread_new, lookup_thread_die): implement an asynchronous hostname lookup thread which given an IPv4 address tries to look up the hostname for that address with reverse DNS - (get_best_device): split out best device code from update_routing_and_dns() - (update_etc_hosts): update /etc/hosts with the machine's new hostname to preserve the 127.0.0.1 reverse mapping that so many things require - (set_system_hostname): set a given hostname - (update_system_hostname): implement hostname policy; a configured hostname (from the system settings service) is used if available, otherwise an automatically determined hostname from DHCP, VPN, etc. If there was no automatically determined hostname, reverse DNS of the best device's IP address will be used, and as a last resort the hostname 'localhost.localdomain' is set. - (update_routing_and_dns): use get_best_device(); update the system hostname when the network config changes - (hostname_changed): update system hostname if the system settings service signals a hostname change - (nm_policy_new): list for system settings service hostname changes - (nm_policy_destroy): ensure that an in-progress hostname lookup thread gets told to die * system-settings/plugins/keyfile/plugin.c system-settings/plugins/ifcfg-suse/plugin.c - (get_property, sc_plugin_ifcfg_class_init): implement hostname and capabilities properties * system-settings/plugins/ifcfg-fedora/shvar.c - (svOpenFile): re-enable R/W access of ifcfg files since the plugin writes out /etc/sysconfig/network now * system-settings/plugins/ifcfg-fedora/plugin.c - (plugin_get_hostname): get hostname from /etc/sysconfig/network - (plugin_set_hostname): save hostname to /etc/sysconfig/network - (sc_network_changed_cb): handle changes to /etc/sysconfig/network - (sc_plugin_ifcfg_init): monitor /etc/sysconfig/network for changes - (get_property, set_property, sc_plugin_ifcfg_class_init): implement hostname get/set and capabilities get git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4077 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-09-18 15:16:44 +00:00
{
settings: rename NMSysconfigSettings to NMSettings
2010-10-27 20:05:23 -05:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
const char *hostname;
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
hostname = nm_hostname_manager_get_hostname (priv->hostname_manager);
2008-09-18 Dan Williams <dcbw@redhat.com> Implement support for honoring configured and automatic hostnames, and for setting the configured hostname. * introspection/nm-ip4-config.xml src/nm-ip4-config.c src/nm-ip4-config.h src/dhcp-manager/nm-dhcp-manager.c - Remove useless hostname property; it's not really part of the IPv4 config * introspection/nm-settings-system.xml libnm-glib/nm-dbus-settings-system.c libnm-glib/nm-dbus-settings-system.h - Add SetHostname() call to system settings D-Bus interface - Add Hostname property to system settings D-Bus interface - (nm_dbus_settings_system_save_hostname, nm_dbus_settings_system_get_hostname): implement * src/nm-device.c src/nm-device.h - (nm_device_get_dhcp4_config): implement * src/nm-manager.c src/nm-manager.h - Fetch and track system settings service hostname changes, and proxy the changes via a GObject property of the manager * system-settings/src/nm-system-config-interface.c system-settings/src/nm-system-config-interface.h - Replace nm_system_config_interface_supports_add() with a capabilities bitfield * system-settings/src/nm-system-config-error.c system-settings/src/nm-system-config-error.h - Add additional errors * system-settings/src/dbus-settings.c system-settings/src/dbus-settings.h - (get_property, nm_sysconfig_settings_class_init): add hostname property; first plugin returning a hostname wins - (impl_settings_add_connection): use plugin capabilities instead of nm_system_config_interface_supports_add() - (impl_settings_save_hostname): implement hostname saving * src/NetworkManagerPolicy.c - (lookup_thread_run_cb, lookup_thread_worker, lookup_thread_new, lookup_thread_die): implement an asynchronous hostname lookup thread which given an IPv4 address tries to look up the hostname for that address with reverse DNS - (get_best_device): split out best device code from update_routing_and_dns() - (update_etc_hosts): update /etc/hosts with the machine's new hostname to preserve the 127.0.0.1 reverse mapping that so many things require - (set_system_hostname): set a given hostname - (update_system_hostname): implement hostname policy; a configured hostname (from the system settings service) is used if available, otherwise an automatically determined hostname from DHCP, VPN, etc. If there was no automatically determined hostname, reverse DNS of the best device's IP address will be used, and as a last resort the hostname 'localhost.localdomain' is set. - (update_routing_and_dns): use get_best_device(); update the system hostname when the network config changes - (hostname_changed): update system hostname if the system settings service signals a hostname change - (nm_policy_new): list for system settings service hostname changes - (nm_policy_destroy): ensure that an in-progress hostname lookup thread gets told to die * system-settings/plugins/keyfile/plugin.c system-settings/plugins/ifcfg-suse/plugin.c - (get_property, sc_plugin_ifcfg_class_init): implement hostname and capabilities properties * system-settings/plugins/ifcfg-fedora/shvar.c - (svOpenFile): re-enable R/W access of ifcfg files since the plugin writes out /etc/sysconfig/network now * system-settings/plugins/ifcfg-fedora/plugin.c - (plugin_get_hostname): get hostname from /etc/sysconfig/network - (plugin_set_hostname): save hostname to /etc/sysconfig/network - (sc_network_changed_cb): handle changes to /etc/sysconfig/network - (sc_plugin_ifcfg_init): monitor /etc/sysconfig/network for changes - (get_property, set_property, sc_plugin_ifcfg_class_init): implement hostname get/set and capabilities get git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4077 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-09-18 15:16:44 +00:00
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
nm_dispatcher_call_hostname (NULL, NULL, NULL);
nm_dhcp_manager_set_default_hostname (nm_dhcp_manager_get (), hostname);
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
/* General NMManager stuff */
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
static gboolean
core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002) This commit changes rfkill state handling slightly in the following ways: - when checking whether a user toggle request can change radio state, ignore states we can change in radio_enabled_for_rstate() as a result of the toggle; this fixes WiMAX enable/disable because a softblock can be changed by telling wimaxd to enable the radio. As a side-effect this also fixes handling of WiFi when altering the rfkill state as well. - make WiFi user toggle requests change wifi killswitch state; this has been long requested and on the TODO list for a while and it turns out to be a lot easier to do these days. This provides the expected behavior when disabling wireless from user agent menus since there's not an easy way to do this other than dropping to shell and running rfkill.
2011-04-22 14:56:31 -05:00
radio_enabled_for_rstate (RadioState *rstate, gboolean check_changeable)
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
{
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
gboolean enabled;
core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002) This commit changes rfkill state handling slightly in the following ways: - when checking whether a user toggle request can change radio state, ignore states we can change in radio_enabled_for_rstate() as a result of the toggle; this fixes WiMAX enable/disable because a softblock can be changed by telling wimaxd to enable the radio. As a side-effect this also fixes handling of WiFi when altering the rfkill state as well. - make WiFi user toggle requests change wifi killswitch state; this has been long requested and on the TODO list for a while and it turns out to be a lot easier to do these days. This provides the expected behavior when disabling wireless from user agent menus since there's not an easy way to do this other than dropping to shell and running rfkill.
2011-04-22 14:56:31 -05:00
enabled = rstate->user_enabled && rstate->hw_enabled;
core: ignore modem management service state in rfkill handling rfkill handling should only pay attention to actual rfkill, since rfkill is global but the modem management service state is per-device. Thus calculating a global state from multiple devices is very likely to get things wrong. Remove all of the code that used to handle that sort of thing, which means removing the 'enable-changed' signal from the Modem device, since now nothing external to the modem device should need to care whether it's enabled internally or not.
2013-05-31 14:28:16 -05:00
if (check_changeable)
core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002) This commit changes rfkill state handling slightly in the following ways: - when checking whether a user toggle request can change radio state, ignore states we can change in radio_enabled_for_rstate() as a result of the toggle; this fixes WiMAX enable/disable because a softblock can be changed by telling wimaxd to enable the radio. As a side-effect this also fixes handling of WiFi when altering the rfkill state as well. - make WiFi user toggle requests change wifi killswitch state; this has been long requested and on the TODO list for a while and it turns out to be a lot easier to do these days. This provides the expected behavior when disabling wireless from user agent menus since there's not an easy way to do this other than dropping to shell and running rfkill.
2011-04-22 14:56:31 -05:00
enabled &= rstate->sw_enabled;
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
return enabled;
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
}
static gboolean
core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002) This commit changes rfkill state handling slightly in the following ways: - when checking whether a user toggle request can change radio state, ignore states we can change in radio_enabled_for_rstate() as a result of the toggle; this fixes WiMAX enable/disable because a softblock can be changed by telling wimaxd to enable the radio. As a side-effect this also fixes handling of WiFi when altering the rfkill state as well. - make WiFi user toggle requests change wifi killswitch state; this has been long requested and on the TODO list for a while and it turns out to be a lot easier to do these days. This provides the expected behavior when disabling wireless from user agent menus since there's not an easy way to do this other than dropping to shell and running rfkill.
2011-04-22 14:56:31 -05:00
radio_enabled_for_type (NMManager *self, RfKillType rtype, gboolean check_changeable)
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002) This commit changes rfkill state handling slightly in the following ways: - when checking whether a user toggle request can change radio state, ignore states we can change in radio_enabled_for_rstate() as a result of the toggle; this fixes WiMAX enable/disable because a softblock can be changed by telling wimaxd to enable the radio. As a side-effect this also fixes handling of WiFi when altering the rfkill state as well. - make WiFi user toggle requests change wifi killswitch state; this has been long requested and on the TODO list for a while and it turns out to be a lot easier to do these days. This provides the expected behavior when disabling wireless from user agent menus since there's not an easy way to do this other than dropping to shell and running rfkill.
2011-04-22 14:56:31 -05:00
return radio_enabled_for_rstate (&priv->radio_states[rtype], check_changeable);
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
}
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
static void
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
manager_update_radio_enabled (NMManager *self,
RadioState *rstate,
gboolean enabled)
2008-02-06 Dan Williams <dcbw@redhat.com> * src/nm-manager.c - (finalize): remove devices a bit earlier; clean up system settings poke - (nm_manager_name_owner_changed): clean up system settings poke when the service appears, and try to restart it if it fails - (poke_system_settings_daemon_cb): try to get the system settings service started through D-Bus service activation - (initial_get_connections): start the system settings daemon if it's not already running git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3293 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-02-06 16:50:43 +00:00
{
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *device;
2008-02-06 Dan Williams <dcbw@redhat.com> * src/nm-manager.c - (finalize): remove devices a bit earlier; clean up system settings poke - (nm_manager_name_owner_changed): clean up system settings poke when the service appears, and try to restart it if it fails - (poke_system_settings_daemon_cb): try to get the system settings service started through D-Bus service activation - (initial_get_connections): start the system settings daemon if it's not already running git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3293 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-02-06 16:50:43 +00:00
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
/* Do nothing for radio types not yet implemented */
if (!rstate->prop)
return;
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
g_object_notify (G_OBJECT (self), rstate->prop);
core: preserve wifi and networking enabled/disabled states (bgo #582447) With modifications by dcbw to create the state file if it doesn't exist, and a couple cleanups and formatting fixes.
2009-11-02 17:29:53 -08:00
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
/* Don't touch devices if asleep/networking disabled */
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
if (manager_sleeping (self))
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
return;
2007-09-02 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h libnm-glib/nm-settings.c - defines for the user settings daemon D-Bus bits * src/NetworkManager.c - Remove stuff that referred to the old NetworkManagerInfo service * src/vpn-manager/nm-dbus-vpn.h - Move old NMI defines to the only place they are used still * libnm-util/nm-connection.c libnm-util/nm-connection.h src/nm-activation-request.c - Make NMConnection a GObject subclass so we can do spiffy stuff with it * src/nm-manager.c src/nm-manager.h - Get connections and their settings from the user settings daemon at the appropriate times git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2763 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-03 01:12:23 +00:00
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
/* enable/disable wireless devices as required */
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
core: clean up per-device rfkill handling Add an accessor for device rfkill type and use that instead of GObject properties, and also use that accessor when claiming a new device instead of checking NM_IS_DEVICE_xxxx(). Allows us to move one step closer to making WiMAX a plugin.
2011-11-18 12:02:58 -06:00
if (nm_device_get_rfkill_type (device) == rstate->rtype) {
manager: add "rfkill" prefix to related logging messages
2017-06-07 13:13:55 +02:00
_LOG2D (LOGD_RFKILL, device, "rfkill: setting radio %s", enabled ? "enabled" : "disabled");
core: clean up per-device rfkill handling Add an accessor for device rfkill type and use that instead of GObject properties, and also use that accessor when claiming a new device instead of checking NM_IS_DEVICE_xxxx(). Allows us to move one step closer to making WiMAX a plugin.
2011-11-18 12:02:58 -06:00
nm_device_set_enabled (device, enabled);
core: more manager debug logging
2010-04-07 14:55:43 -07:00
}
2008-02-06 Dan Williams <dcbw@redhat.com> * src/nm-manager.c - (finalize): remove devices a bit earlier; clean up system settings poke - (nm_manager_name_owner_changed): clean up system settings poke when the service appears, and try to restart it if it fails - (poke_system_settings_daemon_cb): try to get the system settings service started through D-Bus service activation - (initial_get_connections): start the system settings daemon if it's not already running git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3293 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-02-06 16:50:43 +00:00
}
2007-09-02 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h libnm-glib/nm-settings.c - defines for the user settings daemon D-Bus bits * src/NetworkManager.c - Remove stuff that referred to the old NetworkManagerInfo service * src/vpn-manager/nm-dbus-vpn.h - Move old NMI defines to the only place they are used still * libnm-util/nm-connection.c libnm-util/nm-connection.h src/nm-activation-request.c - Make NMConnection a GObject subclass so we can do spiffy stuff with it * src/nm-manager.c src/nm-manager.h - Get connections and their settings from the user settings daemon at the appropriate times git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2763 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-03 01:12:23 +00:00
}
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
static void
wifi: remove old ipw rfkill polling functionality Older Intel "ipw" devices (ipw2100, ipw2200, and ipw2915) only gained kernel rfkill subsystem integration with 2.6.33. Before then their custom rfkill functionality had to be polled via sysfs. Since we now require at least a 3.x kernel, remove this old code.
2014-04-15 16:25:39 -05:00
update_rstate_from_rfkill (NMRfkillManager *rfkill_mgr, RadioState *rstate)
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
{
wifi: remove old ipw rfkill polling functionality Older Intel "ipw" devices (ipw2100, ipw2200, and ipw2915) only gained kernel rfkill subsystem integration with 2.6.33. Before then their custom rfkill functionality had to be polled via sysfs. Since we now require at least a 3.x kernel, remove this old code.
2014-04-15 16:25:39 -05:00
switch (nm_rfkill_manager_get_rfkill_state (rfkill_mgr, rstate->rtype)) {
case RFKILL_UNBLOCKED:
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
rstate->sw_enabled = TRUE;
rstate->hw_enabled = TRUE;
wifi: remove old ipw rfkill polling functionality Older Intel "ipw" devices (ipw2100, ipw2200, and ipw2915) only gained kernel rfkill subsystem integration with 2.6.33. Before then their custom rfkill functionality had to be polled via sysfs. Since we now require at least a 3.x kernel, remove this old code.
2014-04-15 16:25:39 -05:00
break;
case RFKILL_SOFT_BLOCKED:
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
rstate->sw_enabled = FALSE;
rstate->hw_enabled = TRUE;
wifi: remove old ipw rfkill polling functionality Older Intel "ipw" devices (ipw2100, ipw2200, and ipw2915) only gained kernel rfkill subsystem integration with 2.6.33. Before then their custom rfkill functionality had to be polled via sysfs. Since we now require at least a 3.x kernel, remove this old code.
2014-04-15 16:25:39 -05:00
break;
case RFKILL_HARD_BLOCKED:
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
rstate->sw_enabled = FALSE;
rstate->hw_enabled = FALSE;
wifi: remove old ipw rfkill polling functionality Older Intel "ipw" devices (ipw2100, ipw2200, and ipw2915) only gained kernel rfkill subsystem integration with 2.6.33. Before then their custom rfkill functionality had to be polled via sysfs. Since we now require at least a 3.x kernel, remove this old code.
2014-04-15 16:25:39 -05:00
break;
default:
g_warn_if_reached ();
break;
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
}
}
wifi: poll rfkill status for ipw2x00 devices The ipw2x00 drivers won't be converted over to the kernel's rfkill subsystem until 2.6.33, and thus listening for udev rfkill change events on these devices doesn't work. So until then, poll rfkill state for ipw2x00 devices every few seconds in addition to listening to other rfkill sources.
2009-11-24 10:43:43 -08:00
static void
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
manager_rfkill_update_one_type (NMManager *self,
RadioState *rstate,
RfKillType rtype)
wifi: poll rfkill status for ipw2x00 devices The ipw2x00 drivers won't be converted over to the kernel's rfkill subsystem until 2.6.33, and thus listening for udev rfkill change events on these devices doesn't work. So until then, poll rfkill state for ipw2x00 devices every few seconds in addition to listening to other rfkill sources.
2009-11-24 10:43:43 -08:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: ignore modem management service state in rfkill handling rfkill handling should only pay attention to actual rfkill, since rfkill is global but the modem management service state is per-device. Thus calculating a global state from multiple devices is very likely to get things wrong. Remove all of the code that used to handle that sort of thing, which means removing the 'enable-changed' signal from the Modem device, since now nothing external to the modem device should need to care whether it's enabled internally or not.
2013-05-31 14:28:16 -05:00
gboolean old_enabled, new_enabled, old_rfkilled, new_rfkilled, old_hwe;
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
old_enabled = radio_enabled_for_rstate (rstate, TRUE);
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
old_rfkilled = rstate->hw_enabled && rstate->sw_enabled;
old_hwe = rstate->hw_enabled;
wifi: poll rfkill status for ipw2x00 devices The ipw2x00 drivers won't be converted over to the kernel's rfkill subsystem until 2.6.33, and thus listening for udev rfkill change events on these devices doesn't work. So until then, poll rfkill state for ipw2x00 devices every few seconds in addition to listening to other rfkill sources.
2009-11-24 10:43:43 -08:00
wifi: remove old ipw rfkill polling functionality Older Intel "ipw" devices (ipw2100, ipw2200, and ipw2915) only gained kernel rfkill subsystem integration with 2.6.33. Before then their custom rfkill functionality had to be polled via sysfs. Since we now require at least a 3.x kernel, remove this old code.
2014-04-15 16:25:39 -05:00
/* recheck kernel rfkill state */
update_rstate_from_rfkill (priv->rfkill_mgr, rstate);
wifi: poll rfkill status for ipw2x00 devices The ipw2x00 drivers won't be converted over to the kernel's rfkill subsystem until 2.6.33, and thus listening for udev rfkill change events on these devices doesn't work. So until then, poll rfkill state for ipw2x00 devices every few seconds in addition to listening to other rfkill sources.
2009-11-24 10:43:43 -08:00
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
/* Print out all states affecting device enablement */
wifi: fix disabled wifi devices on resume (rh #578141) RFKILL_TYPE_WLAN is 0, and we while we had allocated the structure for WIMAX rfkill in the manager's priv->radio_states, we hadn't filled it in. That meant that priv->radio_states[RFKILL_TYPE_WIMAX].rtype was 0, and thus various operations thought that wifi devices were wimax devices, and since WiMAX rfkill is never updated because it's not yet used, wifi would never be enabled after resume.
2010-04-08 18:23:43 -07:00
if (rstate->desc) {
manager: add "rfkill" prefix to related logging messages
2017-06-07 13:13:55 +02:00
_LOGD (LOGD_RFKILL, "rfkill: %s hw-enabled %d sw-enabled %d",
manager: use logging helpers
2016-03-02 11:38:26 +01:00
rstate->desc, rstate->hw_enabled, rstate->sw_enabled);
wifi: fix disabled wifi devices on resume (rh #578141) RFKILL_TYPE_WLAN is 0, and we while we had allocated the structure for WIMAX rfkill in the manager's priv->radio_states, we hadn't filled it in. That meant that priv->radio_states[RFKILL_TYPE_WIMAX].rtype was 0, and thus various operations thought that wifi devices were wimax devices, and since WiMAX rfkill is never updated because it's not yet used, wifi would never be enabled after resume.
2010-04-08 18:23:43 -07:00
}
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
/* Log new killswitch state */
new_rfkilled = rstate->hw_enabled && rstate->sw_enabled;
if (old_rfkilled != new_rfkilled) {
manager: add "rfkill" prefix to related logging messages
2017-06-07 13:13:55 +02:00
_LOGI (LOGD_RFKILL, "rfkill: %s now %s by radio killswitch",
manager: use logging helpers
2016-03-02 11:38:26 +01:00
rstate->desc,
new_rfkilled ? "enabled" : "disabled");
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
}
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
/* Send out property changed signal for HW enabled */
if (rstate->hw_enabled != old_hwe) {
wifi: fix disabled wifi devices on resume (rh #578141) RFKILL_TYPE_WLAN is 0, and we while we had allocated the structure for WIMAX rfkill in the manager's priv->radio_states, we hadn't filled it in. That meant that priv->radio_states[RFKILL_TYPE_WIMAX].rtype was 0, and thus various operations thought that wifi devices were wimax devices, and since WiMAX rfkill is never updated because it's not yet used, wifi would never be enabled after resume.
2010-04-08 18:23:43 -07:00
if (rstate->hw_prop)
g_object_notify (G_OBJECT (self), rstate->hw_prop);
wifi: poll rfkill status for ipw2x00 devices The ipw2x00 drivers won't be converted over to the kernel's rfkill subsystem until 2.6.33, and thus listening for udev rfkill change events on these devices doesn't work. So until then, poll rfkill state for ipw2x00 devices every few seconds in addition to listening to other rfkill sources.
2009-11-24 10:43:43 -08:00
}
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
/* And finally update the actual device radio state itself; respect the
* daemon state here because this is never called from user-triggered
* radio changes and we only want to ignore the daemon enabled state when
* handling user radio change requests.
*/
new_enabled = radio_enabled_for_rstate (rstate, TRUE);
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
if (new_enabled != old_enabled)
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
manager_update_radio_enabled (self, rstate, new_enabled);
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
}
static void
nm_manager_rfkill_update (NMManager *self, RfKillType rtype)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
guint i;
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
if (rtype != RFKILL_TYPE_UNKNOWN)
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
manager_rfkill_update_one_type (self, &priv->radio_states[rtype], rtype);
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
else {
/* Otherwise sync all radio types */
for (i = 0; i < RFKILL_TYPE_MAX; i++)
manager_rfkill_update_one_type (self, &priv->radio_states[i], i);
wifi: poll rfkill status for ipw2x00 devices The ipw2x00 drivers won't be converted over to the kernel's rfkill subsystem until 2.6.33, and thus listening for udev rfkill change events on these devices doesn't work. So until then, poll rfkill state for ipw2x00 devices every few seconds in addition to listening to other rfkill sources.
2009-11-24 10:43:43 -08:00
}
}
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
static void
device_auth_done_cb (NMAuthChain *chain,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
gpointer user_data)
{
NMManager *self = NM_MANAGER (user_data);
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
gs_free_error GError *error = NULL;
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
NMAuthCallResult result;
NMDevice *device;
const char *permission;
NMDeviceAuthRequestFunc callback;
device: add audit support
2015-07-14 10:19:19 +02:00
NMAuthSubject *subject;
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
nm_assert (G_IS_DBUS_METHOD_INVOCATION (context));
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_unlink (nm_auth_chain_parent_lst_list (chain));
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
manager: use "perm" name for nm_auth_chain_set_data() tag in device_auth_request_cb() There are two similar cases where the caller attaches the requested permission to the auth-chain. There the tag "perm" is used. Rename for consistency.
2019-05-06 09:53:26 +02:00
permission = nm_auth_chain_get_data (chain, "perm");
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
nm_assert (permission);
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
callback = nm_auth_chain_get_data (chain, "callback");
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
nm_assert (callback);
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
device = nm_auth_chain_get_data (chain, "device");
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
nm_assert (NM_IS_DEVICE (device));
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
core: use same codepaths for root and non-root during authentication 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.
2012-10-08 12:52:15 -05:00
result = nm_auth_chain_get_result (chain, permission);
device: add audit support
2015-07-14 10:19:19 +02:00
subject = nm_auth_chain_get_subject (chain);
core: use same codepaths for root and non-root during authentication 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.
2012-10-08 12:52:15 -05:00
core: remove unused error argument from NMAuthChainResultFunc NMAuthChain usually requests several permissions at once. Hence, an error argument in the overall callback does not make sense, because you wouldn't know which request failed. If at all, it could only mean that the overall request failed (like an D-Bus failure communicating to D-Bus *for all permisssions*), but we don't need to handle that specially. In fact, we don't really care why permission was not granted, whether it's due to an error or legitimate reasons. The error in the callback was always set to %NULL. Remove it.
2019-05-04 09:37:54 +02:00
if (result != NM_AUTH_CALL_RESULT_YES) {
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGD (LOGD_CORE, "%s request failed: not authorized", permission);
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
error = g_error_new (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
"%s request failed: not authorized",
permission);
}
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
nm_assert (error || (result == NM_AUTH_CALL_RESULT_YES));
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
callback (device,
context,
device: add audit support
2015-07-14 10:19:19 +02:00
subject,
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
error,
nm_auth_chain_get_data (chain, "user-data"));
}
static void
device_auth_request_cb (NMDevice *device,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
NMConnection *connection,
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
const char *permission,
gboolean allow_interaction,
NMDeviceAuthRequestFunc callback,
gpointer user_data,
NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
GError *error = NULL;
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
NMAuthSubject *subject = NULL;
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
NMAuthChain *chain;
auth-chain: don't clone the permission string for AuthChain Out of the 33 callers of nm_auth_chain_add_call(), the permission argument is: - 29 times a C string literal like NM_AUTH_PERMISSION_NETWORK_CONTROL. - 3 times assign a string that is in fact a static string (it's just not a string literal) - only NMManager's device_auth_request_cb() passes a permission of (possibly) non static origin. But it already duplicates the string for it's own purposes and attaches it as user-data to the NMAuthChain. There really is no need to duplicate the string. Replace nm_auth_chain_add_call() by a macro that ensures that the permission string is a C literal. Rename nm_auth_chain_add_call() to nm_auth_chain_add_call_unsafe() to indicate that the lifetime of the permission argument is now the responsibility of the caller.
2019-05-04 10:31:18 +02:00
char *permission_dup;
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
/* Validate the caller */
auth: rework polkit autorization to use DBUS interface directly This makes NetworkManager independent of <polkit/polkit.h> development headers and libpolkit-gobject-1.so library. Instead communicate directly with polkit using its DBUS interface. PolicyKit support is now always compiled in. You can control polkit authorization with the configuration option [main] auth-polkit=yes|no If the configure option is omitted, a build time default value is used. This default value can be set with the configure option --enable-polkit. This commit adds a new class NMAuthManager that reimplements the relevant DBUS client parts. It takes source code from the polkit library. https://bugzilla.gnome.org/show_bug.cgi?id=734146 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-14 13:34:57 +02:00
subject = nm_auth_subject_new_unix_process_from_context (context);
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
if (!subject) {
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_UID_UKNOWN);
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
goto done;
}
/* Ensure the subject has permissions for this connection */
core: cleanup code by using nm_auth_is_subject_in_acl_set_error()
2018-04-12 09:48:16 +02:00
if ( connection
&& !nm_auth_is_subject_in_acl_set_error (connection,
subject,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
&error))
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
goto done;
auth: move common nm_dbus_manager_get_caller_info() functionality into nm_auth_chain_new() 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.
2012-12-16 12:30:41 -06:00
/* Validate the request */
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
chain = nm_auth_chain_new_subject (subject, context, device_auth_done_cb, self);
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
if (!chain) {
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_AUTH_FAILED);
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
goto done;
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
}
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
auth-chain: don't clone the permission string for AuthChain Out of the 33 callers of nm_auth_chain_add_call(), the permission argument is: - 29 times a C string literal like NM_AUTH_PERMISSION_NETWORK_CONTROL. - 3 times assign a string that is in fact a static string (it's just not a string literal) - only NMManager's device_auth_request_cb() passes a permission of (possibly) non static origin. But it already duplicates the string for it's own purposes and attaches it as user-data to the NMAuthChain. There really is no need to duplicate the string. Replace nm_auth_chain_add_call() by a macro that ensures that the permission string is a C literal. Rename nm_auth_chain_add_call() to nm_auth_chain_add_call_unsafe() to indicate that the lifetime of the permission argument is now the responsibility of the caller.
2019-05-04 10:31:18 +02:00
permission_dup = g_strdup (permission);
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
nm_auth_chain_set_data (chain, "device", g_object_ref (device), g_object_unref);
nm_auth_chain_set_data (chain, "callback", callback, NULL);
nm_auth_chain_set_data (chain, "user-data", user_data, NULL);
manager: use "perm" name for nm_auth_chain_set_data() tag in device_auth_request_cb() There are two similar cases where the caller attaches the requested permission to the auth-chain. There the tag "perm" is used. Rename for consistency.
2019-05-06 09:53:26 +02:00
nm_auth_chain_set_data (chain, "perm", permission_dup /* transfer ownership */, g_free);
auth-chain: don't clone the permission string for AuthChain Out of the 33 callers of nm_auth_chain_add_call(), the permission argument is: - 29 times a C string literal like NM_AUTH_PERMISSION_NETWORK_CONTROL. - 3 times assign a string that is in fact a static string (it's just not a string literal) - only NMManager's device_auth_request_cb() passes a permission of (possibly) non static origin. But it already duplicates the string for it's own purposes and attaches it as user-data to the NMAuthChain. There really is no need to duplicate the string. Replace nm_auth_chain_add_call() by a macro that ensures that the permission string is a C literal. Rename nm_auth_chain_add_call() to nm_auth_chain_add_call_unsafe() to indicate that the lifetime of the permission argument is now the responsibility of the caller.
2019-05-04 10:31:18 +02:00
nm_auth_chain_add_call_unsafe (chain, permission_dup, allow_interaction);
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
done:
if (error)
device: add audit support
2015-07-14 10:19:19 +02:00
callback (device, context, subject, error, user_data);
g_clear_object (&subject);
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
g_clear_error (&error);
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
}
manager: fix assuming multi-connect connections When assuming existing connections, allow the same connection to be activated on a different device if the connection is multi-connect capable. Otherwise, when a connection is active on multiple devices and NM is restarted, we assume only the first instance, and create in-memory connections for others.
2018-08-08 11:33:31 +02:00
static gboolean
new_activation_allowed_for_connection (NMManager *self,
NMSettingsConnection *connection)
{
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (NM_IN_SET (_nm_connection_get_multi_connect (nm_settings_connection_get_connection (connection)),
manager: fix assuming multi-connect connections When assuming existing connections, allow the same connection to be activated on a different device if the connection is multi-connect capable. Otherwise, when a connection is active on multiple devices and NM is restarted, we assume only the first instance, and create in-memory connections for others.
2018-08-08 11:33:31 +02:00
NM_CONNECTION_MULTI_CONNECT_MANUAL_MULTIPLE,
NM_CONNECTION_MULTI_CONNECT_MULTIPLE))
return TRUE;
return !active_connection_find (self, connection, NULL,
NM_ACTIVE_CONNECTION_STATE_ACTIVATED,
NULL);
}
core: match connections to connections instead of devices This backwards compatible patch adds the possibility to use new nm_device_generate_connection() API via update_connection() virtual method implementations in NMDevice subclasses. Compatibility is achieved by first trying to use the older API and match_l2_config() virtual method and only then moving on to update_connection(). The nm_device_generate_connection() calls update_connection() to create type-specific NMSetting instances and verifies the connection before returning it. To avoid tinkering with NMSettingConnection in update_connection() we use a class attribute called connection_type which is used by nm_device_generate_connection() itself. Known issues: * nm_device_generate_connection() method doesn't implement DHCP lease configuration matching. We shouldn't actually need it but if a use case for that will come out, we can fix it later. * nm_device_generate_connection() doesn't fill in the slave-specific options. * update_connection() is not implemented and connection_type is not set in the subclasses. This will be fixed in individual patches. * NMSetting's compare_property() implementations in combination with NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering false negatives in some cases. Same as above. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-06-27 14:39:13 +02:00
/**
core: clean up legacy connection matching; remove match_l2_config All previous users of this API are gone, so remove it.
2013-11-02 10:40:58 -05:00
* get_existing_connection:
core: match connections to connections instead of devices This backwards compatible patch adds the possibility to use new nm_device_generate_connection() API via update_connection() virtual method implementations in NMDevice subclasses. Compatibility is achieved by first trying to use the older API and match_l2_config() virtual method and only then moving on to update_connection(). The nm_device_generate_connection() calls update_connection() to create type-specific NMSetting instances and verifies the connection before returning it. To avoid tinkering with NMSettingConnection in update_connection() we use a class attribute called connection_type which is used by nm_device_generate_connection() itself. Known issues: * nm_device_generate_connection() method doesn't implement DHCP lease configuration matching. We shouldn't actually need it but if a use case for that will come out, we can fix it later. * nm_device_generate_connection() doesn't fill in the slave-specific options. * update_connection() is not implemented and connection_type is not set in the subclasses. This will be fixed in individual patches. * NMSetting's compare_property() implementations in combination with NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering false negatives in some cases. Same as above. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-06-27 14:39:13 +02:00
* @manager: #NMManager instance
* @device: #NMDevice instance
core: clean up nm-generated-assumed connections when assumption fails or connection disconnects https://bugzilla.gnome.org/show_bug.cgi?id=731937 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-20 20:13:14 +02:00
* @out_generated: (allow-none): return TRUE, if the connection was generated.
core: match connections to connections instead of devices This backwards compatible patch adds the possibility to use new nm_device_generate_connection() API via update_connection() virtual method implementations in NMDevice subclasses. Compatibility is achieved by first trying to use the older API and match_l2_config() virtual method and only then moving on to update_connection(). The nm_device_generate_connection() calls update_connection() to create type-specific NMSetting instances and verifies the connection before returning it. To avoid tinkering with NMSettingConnection in update_connection() we use a class attribute called connection_type which is used by nm_device_generate_connection() itself. Known issues: * nm_device_generate_connection() method doesn't implement DHCP lease configuration matching. We shouldn't actually need it but if a use case for that will come out, we can fix it later. * nm_device_generate_connection() doesn't fill in the slave-specific options. * update_connection() is not implemented and connection_type is not set in the subclasses. This will be fixed in individual patches. * NMSetting's compare_property() implementations in combination with NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering false negatives in some cases. Same as above. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-06-27 14:39:13 +02:00
*
core: clean up legacy connection matching; remove match_l2_config All previous users of this API are gone, so remove it.
2013-11-02 10:40:58 -05:00
* Returns: a #NMSettingsConnection to be assumed by the device, or %NULL if
* the device does not support assuming existing connections.
core: match connections to connections instead of devices This backwards compatible patch adds the possibility to use new nm_device_generate_connection() API via update_connection() virtual method implementations in NMDevice subclasses. Compatibility is achieved by first trying to use the older API and match_l2_config() virtual method and only then moving on to update_connection(). The nm_device_generate_connection() calls update_connection() to create type-specific NMSetting instances and verifies the connection before returning it. To avoid tinkering with NMSettingConnection in update_connection() we use a class attribute called connection_type which is used by nm_device_generate_connection() itself. Known issues: * nm_device_generate_connection() method doesn't implement DHCP lease configuration matching. We shouldn't actually need it but if a use case for that will come out, we can fix it later. * nm_device_generate_connection() doesn't fill in the slave-specific options. * update_connection() is not implemented and connection_type is not set in the subclasses. This will be fixed in individual patches. * NMSetting's compare_property() implementations in combination with NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering false negatives in some cases. Same as above. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-06-27 14:39:13 +02:00
*/
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
static NMSettingsConnection *
core: only assume connections that were managed in a previous run of NetworkManager Before, we would have the concept of assumed connections, which is used for (1) externally configured device that NetworkManager should not touch and (2) connections that NetworkManager should gracefully take over after a restart (seamlessly, non-destructively). The behavior was unclear and mixed. It wasn't clear whether the device is in no-touch mode (1) or gracefully take-over (2). Previous commits already introduce separate activation types EXTERNAL (1) and ASSUME (2). Also, previously, we would for both (1) and (2) try to find a matching connection and use it. That doesn't make sense for either. In the external case (1), we should not pretend that an existing connection is active. Let's always create a new in-memory connection for these cases. Note that this means, external devices now will always generate a connection, instead of pretending an existing one is active. For the assume case (2), we shall not use nm_utils_match_connection() to guess which connection might be active. It can only the one that was active on a previous run of NetworkManager. So, use the information from the state file and try to activate it. If that fails, it is not an assume activation type. Note, that this means we now most of the time don't do ASSUME anymore. Most of the time we do EXTERNAL activation That is because the state information is only available after restart of NetworkManager.
2017-03-08 08:45:11 +01:00
get_existing_connection (NMManager *self,
NMDevice *device,
gboolean *out_generated)
core: match connections to connections instead of devices This backwards compatible patch adds the possibility to use new nm_device_generate_connection() API via update_connection() virtual method implementations in NMDevice subclasses. Compatibility is achieved by first trying to use the older API and match_l2_config() virtual method and only then moving on to update_connection(). The nm_device_generate_connection() calls update_connection() to create type-specific NMSetting instances and verifies the connection before returning it. To avoid tinkering with NMSettingConnection in update_connection() we use a class attribute called connection_type which is used by nm_device_generate_connection() itself. Known issues: * nm_device_generate_connection() method doesn't implement DHCP lease configuration matching. We shouldn't actually need it but if a use case for that will come out, we can fix it later. * nm_device_generate_connection() doesn't fill in the slave-specific options. * update_connection() is not implemented and connection_type is not set in the subclasses. This will be fixed in individual patches. * NMSetting's compare_property() implementations in combination with NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering false negatives in some cases. Same as above. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-06-27 14:39:13 +02:00
{
manager: use logging helpers
2016-03-02 11:38:26 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
Revert "core: merge branch 'bg/restart-assume-rh1551958'" This reverts commit cc1920d71470042c4e0837848da9183526b663d0, reversing changes made to eb8257dea5802a004af9cccacb30af98440e2172. This breaks restart, at least for Wi-Fi devices: #0 0x00007ffff5ee8771 in _g_log_abort (breakpoint=breakpoint@entry=1) at gmessages.c:554 #1 0x00007ffff5ee9a5b in g_logv (log_domain=0x7ffff671a738 "GLib-GIO", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd720) at gmessages.c:1362 #2 0x00007ffff5ee9baf in g_log (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff5f347ea "%s: assertion '%s' failed") at gmessages.c:1403 #3 0x00007ffff5eea0f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", pretty_function=pretty_function@entry=0x7ffff673fc10 <__func__.25628> "g_dbus_proxy_call_internal", expression=expression@entry=0x7ffff673fb1c "G_IS_DBUS_PROXY (proxy)") at gmessages.c:2702 #4 0x00007ffff66cdc5f in g_dbus_proxy_call_internal (proxy=0x0, method_name=method_name@entry=0x555555810510 "Scan", parameters=0x555555c7a530, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, fd_list=fd_list@entry=0x0, cancellable=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2664 #5 0x00007ffff66cf686 in g_dbus_proxy_call (proxy=<optimized out>, method_name=method_name@entry=0x555555810510 "Scan", parameters=<optimized out>, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, cancellable=cancellable@entry=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2970 #6 0x000055555574e026 in nm_supplicant_interface_request_scan (self=0x555555ac2220 [NMSupplicantInterface], ssids=ssids@entry=0x0) at src/supplicant/nm-supplicant-interface.c:1821 #7 0x00007fffe1038276 in request_wireless_scan (self=self@entry=0x555555c6ee60 [NMDeviceWifi], periodic=periodic@entry=0, force_if_scanning=force_if_scanning@entry=0, ssids=<optimized out>, ssids@entry=0x0) at src/devices/wifi/nm-device-wifi.c:1347 #8 0x00007fffe1039011 in device_state_changed (device=0x555555c6ee60 [NMDeviceWifi], new_state=NM_DEVICE_STATE_DISCONNECTED, old_state=<optimized out>, reason=<optimized out>) at src/devices/wifi/nm-device-wifi.c:2998 #9 0x00007ffff432ed1e in ffi_call_unix64 () at ../src/x86/unix64.S:76 #10 0x00007ffff432e68f in ffi_call (cif=cif@entry=0x7fffffffdc70, fn=fn@entry=0x7fffe1038e1e <device_state_changed>, rvalue=<optimized out>, avalue=avalue@entry=0x7fffffffdb60) at ../src/x86/ffi64.c:525 #15 0x00007ffff63db66f in <emit signal ??? on instance 0x555555c6ee60 [NMDeviceWifi]> (instance=instance@entry=0x555555c6ee60, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3447 #11 0x00007ffff63bff39 in g_cclosure_marshal_generic (closure=0x555555c22ea0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gclosure.c:1490 #12 0x00007ffff63bf73d in g_closure_invoke (closure=0x555555c22ea0, return_value=0x0, n_param_values=4, param_values=0x7fffffffdea0, invocation_hint=0x7fffffffde20) at gclosure.c:804 #13 0x00007ffff63d1f30 in signal_emit_unlocked_R (node=node@entry=0x555555c22750, detail=detail@entry=0, instance=instance@entry=0x555555c6ee60, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffdea0) at gsignal.c:3673 #14 0x00007ffff63dad05 in g_signal_emit_valist (instance=0x555555c6ee60, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffe0b0) at gsignal.c:3391 #16 0x00005555556f0f18 in _set_state_full (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED, quitting=quitting@entry=0) at src/devices/nm-device.c:13268 #17 0x00005555556f1774 in nm_device_state_changed (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED) at src/devices/nm-device.c:13435 #18 0x00005555555bcf95 in recheck_assume_connection (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi]) at src/nm-manager.c:2297 #19 0x00005555555bd53e in _device_realize_finish (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi], plink=plink@entry=0x555555ae43d8) at src/nm-manager.c:2473 #20 0x00005555555c01d0 in platform_link_added (self=self@entry=0x555555b09140 [NMManager], ifindex=<optimized out>, plink=plink@entry=0x555555ae43d8, guess_assume=<optimized out>, dev_state=<optimized out>) at src/nm-manager.c:2789 #21 0x00005555555c0cec in platform_query_devices (self=self@entry=0x555555b09140 [NMManager]) at src/nm-manager.c:2901 #22 0x00005555555c439e in nm_manager_start (self=0x555555b09140 [NMManager], error=<optimized out>) at src/nm-manager.c:5632 #23 0x000055555558498e in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:413
2018-04-04 14:48:52 +02:00
gs_unref_object NMConnection *connection = NULL;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *added;
core: add device-generated connection to settings 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>
2013-08-23 15:45:17 +02:00
GError *error = NULL;
manager: trust the state file more when assuming connections If we can't generate a connection and maybe_later is TRUE, it means that the device can generate/assume connections but it failed for the moment due to missing master/slaves/addresses. In this case, just assume the connection from state file. https://bugzilla.redhat.com/show_bug.cgi?id=1551958
2018-04-05 11:19:54 +02:00
gs_free_error GError *gen_error = NULL;
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
NMDevice *master = NULL;
int ifindex = nm_device_get_ifindex (device);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *matched = NULL;
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
NMSettingsConnection *connection_checked = NULL;
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
gboolean assume_state_guess_assume = FALSE;
const char *assume_state_connection_uuid = NULL;
manager: trust the state file more when assuming connections If we can't generate a connection and maybe_later is TRUE, it means that the device can generate/assume connections but it failed for the moment due to missing master/slaves/addresses. In this case, just assume the connection from state file. https://bugzilla.redhat.com/show_bug.cgi?id=1551958
2018-04-05 11:19:54 +02:00
gboolean maybe_later, only_by_uuid = FALSE;
core: match connections to connections instead of devices This backwards compatible patch adds the possibility to use new nm_device_generate_connection() API via update_connection() virtual method implementations in NMDevice subclasses. Compatibility is achieved by first trying to use the older API and match_l2_config() virtual method and only then moving on to update_connection(). The nm_device_generate_connection() calls update_connection() to create type-specific NMSetting instances and verifies the connection before returning it. To avoid tinkering with NMSettingConnection in update_connection() we use a class attribute called connection_type which is used by nm_device_generate_connection() itself. Known issues: * nm_device_generate_connection() method doesn't implement DHCP lease configuration matching. We shouldn't actually need it but if a use case for that will come out, we can fix it later. * nm_device_generate_connection() doesn't fill in the slave-specific options. * update_connection() is not implemented and connection_type is not set in the subclasses. This will be fixed in individual patches. * NMSetting's compare_property() implementations in combination with NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering false negatives in some cases. Same as above. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-06-27 14:39:13 +02:00
core: clean up nm-generated-assumed connections when assumption fails or connection disconnects https://bugzilla.gnome.org/show_bug.cgi?id=731937 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-20 20:13:14 +02:00
if (out_generated)
*out_generated = FALSE;
core: capture initial device DHCP IP configuration At least gives us DNS servers and definite gateway.
2013-11-02 10:38:23 -05:00
nm_device_capture_initial_config (device);
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
if (ifindex) {
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
int master_ifindex = nm_platform_link_get_master (priv->platform, ifindex);
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
manager: ignore ovs-system master when assuming connections This change allows NM to assume after a restart a device that has been enslaved externally to an ovs bridge. https://bugzilla.redhat.com/show_bug.cgi?id=1676551 (cherry picked from commit 93bbe436958264d5f720ce095b3f390ce50fc732)
2019-02-26 10:07:36 +01:00
/* Check that the master is activating before assuming a
* slave connection. However, ignore ovs-system master as
* we never manage it.
*/
if ( master_ifindex
&& nm_platform_link_get_type (priv->platform, master_ifindex) != NM_LINK_TYPE_OPENVSWITCH) {
manager: use logging helpers
2016-03-02 11:38:26 +01:00
master = nm_manager_get_device_by_ifindex (self, master_ifindex);
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
if (!master) {
manager: cleanup logging message during recheck_assume_connection()/get_existing_connection() recheck_assume_connection() calls get_existing_connection(). We want *one* logging message telling what's happening. Let get_existing_connection() log "assume:" messages and remove duplicate messages from recheck_assume_connection().
2017-06-07 16:41:06 +02:00
_LOG2D (LOGD_DEVICE, device, "assume: don't assume because "
"cannot generate connection for slave before its master (%s/%d)",
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
nm_platform_link_get_name (priv->platform, master_ifindex), master_ifindex);
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
return NULL;
}
if (!nm_device_get_act_request (master)) {
manager: cleanup logging message during recheck_assume_connection()/get_existing_connection() recheck_assume_connection() calls get_existing_connection(). We want *one* logging message telling what's happening. Let get_existing_connection() log "assume:" messages and remove duplicate messages from recheck_assume_connection().
2017-06-07 16:41:06 +02:00
_LOG2D (LOGD_DEVICE, device, "assume: don't assume because "
"cannot generate connection for slave before master %s activates",
nm_device_get_iface (master));
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
return NULL;
}
}
}
Revert "core: merge branch 'bg/restart-assume-rh1551958'" This reverts commit cc1920d71470042c4e0837848da9183526b663d0, reversing changes made to eb8257dea5802a004af9cccacb30af98440e2172. This breaks restart, at least for Wi-Fi devices: #0 0x00007ffff5ee8771 in _g_log_abort (breakpoint=breakpoint@entry=1) at gmessages.c:554 #1 0x00007ffff5ee9a5b in g_logv (log_domain=0x7ffff671a738 "GLib-GIO", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd720) at gmessages.c:1362 #2 0x00007ffff5ee9baf in g_log (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff5f347ea "%s: assertion '%s' failed") at gmessages.c:1403 #3 0x00007ffff5eea0f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", pretty_function=pretty_function@entry=0x7ffff673fc10 <__func__.25628> "g_dbus_proxy_call_internal", expression=expression@entry=0x7ffff673fb1c "G_IS_DBUS_PROXY (proxy)") at gmessages.c:2702 #4 0x00007ffff66cdc5f in g_dbus_proxy_call_internal (proxy=0x0, method_name=method_name@entry=0x555555810510 "Scan", parameters=0x555555c7a530, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, fd_list=fd_list@entry=0x0, cancellable=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2664 #5 0x00007ffff66cf686 in g_dbus_proxy_call (proxy=<optimized out>, method_name=method_name@entry=0x555555810510 "Scan", parameters=<optimized out>, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, cancellable=cancellable@entry=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2970 #6 0x000055555574e026 in nm_supplicant_interface_request_scan (self=0x555555ac2220 [NMSupplicantInterface], ssids=ssids@entry=0x0) at src/supplicant/nm-supplicant-interface.c:1821 #7 0x00007fffe1038276 in request_wireless_scan (self=self@entry=0x555555c6ee60 [NMDeviceWifi], periodic=periodic@entry=0, force_if_scanning=force_if_scanning@entry=0, ssids=<optimized out>, ssids@entry=0x0) at src/devices/wifi/nm-device-wifi.c:1347 #8 0x00007fffe1039011 in device_state_changed (device=0x555555c6ee60 [NMDeviceWifi], new_state=NM_DEVICE_STATE_DISCONNECTED, old_state=<optimized out>, reason=<optimized out>) at src/devices/wifi/nm-device-wifi.c:2998 #9 0x00007ffff432ed1e in ffi_call_unix64 () at ../src/x86/unix64.S:76 #10 0x00007ffff432e68f in ffi_call (cif=cif@entry=0x7fffffffdc70, fn=fn@entry=0x7fffe1038e1e <device_state_changed>, rvalue=<optimized out>, avalue=avalue@entry=0x7fffffffdb60) at ../src/x86/ffi64.c:525 #15 0x00007ffff63db66f in <emit signal ??? on instance 0x555555c6ee60 [NMDeviceWifi]> (instance=instance@entry=0x555555c6ee60, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3447 #11 0x00007ffff63bff39 in g_cclosure_marshal_generic (closure=0x555555c22ea0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gclosure.c:1490 #12 0x00007ffff63bf73d in g_closure_invoke (closure=0x555555c22ea0, return_value=0x0, n_param_values=4, param_values=0x7fffffffdea0, invocation_hint=0x7fffffffde20) at gclosure.c:804 #13 0x00007ffff63d1f30 in signal_emit_unlocked_R (node=node@entry=0x555555c22750, detail=detail@entry=0, instance=instance@entry=0x555555c6ee60, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffdea0) at gsignal.c:3673 #14 0x00007ffff63dad05 in g_signal_emit_valist (instance=0x555555c6ee60, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffe0b0) at gsignal.c:3391 #16 0x00005555556f0f18 in _set_state_full (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED, quitting=quitting@entry=0) at src/devices/nm-device.c:13268 #17 0x00005555556f1774 in nm_device_state_changed (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED) at src/devices/nm-device.c:13435 #18 0x00005555555bcf95 in recheck_assume_connection (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi]) at src/nm-manager.c:2297 #19 0x00005555555bd53e in _device_realize_finish (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi], plink=plink@entry=0x555555ae43d8) at src/nm-manager.c:2473 #20 0x00005555555c01d0 in platform_link_added (self=self@entry=0x555555b09140 [NMManager], ifindex=<optimized out>, plink=plink@entry=0x555555ae43d8, guess_assume=<optimized out>, dev_state=<optimized out>) at src/nm-manager.c:2789 #21 0x00005555555c0cec in platform_query_devices (self=self@entry=0x555555b09140 [NMManager]) at src/nm-manager.c:2901 #22 0x00005555555c439e in nm_manager_start (self=0x555555b09140 [NMManager], error=<optimized out>) at src/nm-manager.c:5632 #23 0x000055555558498e in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:413
2018-04-04 14:48:52 +02:00
/* The core of the API is nm_device_generate_connection() function and
* update_connection() virtual method and the convenient connection_type
* class attribute. Subclasses supporting the new API must have
* update_connection() implemented, otherwise nm_device_generate_connection()
* returns NULL.
*/
manager: trust the state file more when assuming connections If we can't generate a connection and maybe_later is TRUE, it means that the device can generate/assume connections but it failed for the moment due to missing master/slaves/addresses. In this case, just assume the connection from state file. https://bugzilla.redhat.com/show_bug.cgi?id=1551958
2018-04-05 11:19:54 +02:00
connection = nm_device_generate_connection (device, master, &maybe_later, &gen_error);
Revert "core: merge branch 'bg/restart-assume-rh1551958'" This reverts commit cc1920d71470042c4e0837848da9183526b663d0, reversing changes made to eb8257dea5802a004af9cccacb30af98440e2172. This breaks restart, at least for Wi-Fi devices: #0 0x00007ffff5ee8771 in _g_log_abort (breakpoint=breakpoint@entry=1) at gmessages.c:554 #1 0x00007ffff5ee9a5b in g_logv (log_domain=0x7ffff671a738 "GLib-GIO", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd720) at gmessages.c:1362 #2 0x00007ffff5ee9baf in g_log (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff5f347ea "%s: assertion '%s' failed") at gmessages.c:1403 #3 0x00007ffff5eea0f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", pretty_function=pretty_function@entry=0x7ffff673fc10 <__func__.25628> "g_dbus_proxy_call_internal", expression=expression@entry=0x7ffff673fb1c "G_IS_DBUS_PROXY (proxy)") at gmessages.c:2702 #4 0x00007ffff66cdc5f in g_dbus_proxy_call_internal (proxy=0x0, method_name=method_name@entry=0x555555810510 "Scan", parameters=0x555555c7a530, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, fd_list=fd_list@entry=0x0, cancellable=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2664 #5 0x00007ffff66cf686 in g_dbus_proxy_call (proxy=<optimized out>, method_name=method_name@entry=0x555555810510 "Scan", parameters=<optimized out>, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, cancellable=cancellable@entry=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2970 #6 0x000055555574e026 in nm_supplicant_interface_request_scan (self=0x555555ac2220 [NMSupplicantInterface], ssids=ssids@entry=0x0) at src/supplicant/nm-supplicant-interface.c:1821 #7 0x00007fffe1038276 in request_wireless_scan (self=self@entry=0x555555c6ee60 [NMDeviceWifi], periodic=periodic@entry=0, force_if_scanning=force_if_scanning@entry=0, ssids=<optimized out>, ssids@entry=0x0) at src/devices/wifi/nm-device-wifi.c:1347 #8 0x00007fffe1039011 in device_state_changed (device=0x555555c6ee60 [NMDeviceWifi], new_state=NM_DEVICE_STATE_DISCONNECTED, old_state=<optimized out>, reason=<optimized out>) at src/devices/wifi/nm-device-wifi.c:2998 #9 0x00007ffff432ed1e in ffi_call_unix64 () at ../src/x86/unix64.S:76 #10 0x00007ffff432e68f in ffi_call (cif=cif@entry=0x7fffffffdc70, fn=fn@entry=0x7fffe1038e1e <device_state_changed>, rvalue=<optimized out>, avalue=avalue@entry=0x7fffffffdb60) at ../src/x86/ffi64.c:525 #15 0x00007ffff63db66f in <emit signal ??? on instance 0x555555c6ee60 [NMDeviceWifi]> (instance=instance@entry=0x555555c6ee60, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3447 #11 0x00007ffff63bff39 in g_cclosure_marshal_generic (closure=0x555555c22ea0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gclosure.c:1490 #12 0x00007ffff63bf73d in g_closure_invoke (closure=0x555555c22ea0, return_value=0x0, n_param_values=4, param_values=0x7fffffffdea0, invocation_hint=0x7fffffffde20) at gclosure.c:804 #13 0x00007ffff63d1f30 in signal_emit_unlocked_R (node=node@entry=0x555555c22750, detail=detail@entry=0, instance=instance@entry=0x555555c6ee60, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffdea0) at gsignal.c:3673 #14 0x00007ffff63dad05 in g_signal_emit_valist (instance=0x555555c6ee60, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffe0b0) at gsignal.c:3391 #16 0x00005555556f0f18 in _set_state_full (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED, quitting=quitting@entry=0) at src/devices/nm-device.c:13268 #17 0x00005555556f1774 in nm_device_state_changed (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED) at src/devices/nm-device.c:13435 #18 0x00005555555bcf95 in recheck_assume_connection (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi]) at src/nm-manager.c:2297 #19 0x00005555555bd53e in _device_realize_finish (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi], plink=plink@entry=0x555555ae43d8) at src/nm-manager.c:2473 #20 0x00005555555c01d0 in platform_link_added (self=self@entry=0x555555b09140 [NMManager], ifindex=<optimized out>, plink=plink@entry=0x555555ae43d8, guess_assume=<optimized out>, dev_state=<optimized out>) at src/nm-manager.c:2789 #21 0x00005555555c0cec in platform_query_devices (self=self@entry=0x555555b09140 [NMManager]) at src/nm-manager.c:2901 #22 0x00005555555c439e in nm_manager_start (self=0x555555b09140 [NMManager], error=<optimized out>) at src/nm-manager.c:5632 #23 0x000055555558498e in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:413
2018-04-04 14:48:52 +02:00
if (!connection) {
manager: trust the state file more when assuming connections If we can't generate a connection and maybe_later is TRUE, it means that the device can generate/assume connections but it failed for the moment due to missing master/slaves/addresses. In this case, just assume the connection from state file. https://bugzilla.redhat.com/show_bug.cgi?id=1551958
2018-04-05 11:19:54 +02:00
if (maybe_later) {
/* The device can generate a connection, but it failed for now.
* Give it a chance to match a connection from the state file. */
only_by_uuid = TRUE;
} else {
Revert "core: merge branch 'bg/restart-assume-rh1551958'" This reverts commit cc1920d71470042c4e0837848da9183526b663d0, reversing changes made to eb8257dea5802a004af9cccacb30af98440e2172. This breaks restart, at least for Wi-Fi devices: #0 0x00007ffff5ee8771 in _g_log_abort (breakpoint=breakpoint@entry=1) at gmessages.c:554 #1 0x00007ffff5ee9a5b in g_logv (log_domain=0x7ffff671a738 "GLib-GIO", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd720) at gmessages.c:1362 #2 0x00007ffff5ee9baf in g_log (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff5f347ea "%s: assertion '%s' failed") at gmessages.c:1403 #3 0x00007ffff5eea0f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", pretty_function=pretty_function@entry=0x7ffff673fc10 <__func__.25628> "g_dbus_proxy_call_internal", expression=expression@entry=0x7ffff673fb1c "G_IS_DBUS_PROXY (proxy)") at gmessages.c:2702 #4 0x00007ffff66cdc5f in g_dbus_proxy_call_internal (proxy=0x0, method_name=method_name@entry=0x555555810510 "Scan", parameters=0x555555c7a530, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, fd_list=fd_list@entry=0x0, cancellable=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2664 #5 0x00007ffff66cf686 in g_dbus_proxy_call (proxy=<optimized out>, method_name=method_name@entry=0x555555810510 "Scan", parameters=<optimized out>, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, cancellable=cancellable@entry=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2970 #6 0x000055555574e026 in nm_supplicant_interface_request_scan (self=0x555555ac2220 [NMSupplicantInterface], ssids=ssids@entry=0x0) at src/supplicant/nm-supplicant-interface.c:1821 #7 0x00007fffe1038276 in request_wireless_scan (self=self@entry=0x555555c6ee60 [NMDeviceWifi], periodic=periodic@entry=0, force_if_scanning=force_if_scanning@entry=0, ssids=<optimized out>, ssids@entry=0x0) at src/devices/wifi/nm-device-wifi.c:1347 #8 0x00007fffe1039011 in device_state_changed (device=0x555555c6ee60 [NMDeviceWifi], new_state=NM_DEVICE_STATE_DISCONNECTED, old_state=<optimized out>, reason=<optimized out>) at src/devices/wifi/nm-device-wifi.c:2998 #9 0x00007ffff432ed1e in ffi_call_unix64 () at ../src/x86/unix64.S:76 #10 0x00007ffff432e68f in ffi_call (cif=cif@entry=0x7fffffffdc70, fn=fn@entry=0x7fffe1038e1e <device_state_changed>, rvalue=<optimized out>, avalue=avalue@entry=0x7fffffffdb60) at ../src/x86/ffi64.c:525 #15 0x00007ffff63db66f in <emit signal ??? on instance 0x555555c6ee60 [NMDeviceWifi]> (instance=instance@entry=0x555555c6ee60, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3447 #11 0x00007ffff63bff39 in g_cclosure_marshal_generic (closure=0x555555c22ea0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gclosure.c:1490 #12 0x00007ffff63bf73d in g_closure_invoke (closure=0x555555c22ea0, return_value=0x0, n_param_values=4, param_values=0x7fffffffdea0, invocation_hint=0x7fffffffde20) at gclosure.c:804 #13 0x00007ffff63d1f30 in signal_emit_unlocked_R (node=node@entry=0x555555c22750, detail=detail@entry=0, instance=instance@entry=0x555555c6ee60, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffdea0) at gsignal.c:3673 #14 0x00007ffff63dad05 in g_signal_emit_valist (instance=0x555555c6ee60, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffe0b0) at gsignal.c:3391 #16 0x00005555556f0f18 in _set_state_full (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED, quitting=quitting@entry=0) at src/devices/nm-device.c:13268 #17 0x00005555556f1774 in nm_device_state_changed (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED) at src/devices/nm-device.c:13435 #18 0x00005555555bcf95 in recheck_assume_connection (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi]) at src/nm-manager.c:2297 #19 0x00005555555bd53e in _device_realize_finish (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi], plink=plink@entry=0x555555ae43d8) at src/nm-manager.c:2473 #20 0x00005555555c01d0 in platform_link_added (self=self@entry=0x555555b09140 [NMManager], ifindex=<optimized out>, plink=plink@entry=0x555555ae43d8, guess_assume=<optimized out>, dev_state=<optimized out>) at src/nm-manager.c:2789 #21 0x00005555555c0cec in platform_query_devices (self=self@entry=0x555555b09140 [NMManager]) at src/nm-manager.c:2901 #22 0x00005555555c439e in nm_manager_start (self=0x555555b09140 [NMManager], error=<optimized out>) at src/nm-manager.c:5632 #23 0x000055555558498e in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:413
2018-04-04 14:48:52 +02:00
nm_device_assume_state_reset (device);
manager: trust the state file more when assuming connections If we can't generate a connection and maybe_later is TRUE, it means that the device can generate/assume connections but it failed for the moment due to missing master/slaves/addresses. In this case, just assume the connection from state file. https://bugzilla.redhat.com/show_bug.cgi?id=1551958
2018-04-05 11:19:54 +02:00
_LOG2D (LOGD_DEVICE, device, "assume: cannot generate connection: %s",
gen_error->message);
return NULL;
}
Revert "core: merge branch 'bg/restart-assume-rh1551958'" This reverts commit cc1920d71470042c4e0837848da9183526b663d0, reversing changes made to eb8257dea5802a004af9cccacb30af98440e2172. This breaks restart, at least for Wi-Fi devices: #0 0x00007ffff5ee8771 in _g_log_abort (breakpoint=breakpoint@entry=1) at gmessages.c:554 #1 0x00007ffff5ee9a5b in g_logv (log_domain=0x7ffff671a738 "GLib-GIO", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd720) at gmessages.c:1362 #2 0x00007ffff5ee9baf in g_log (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff5f347ea "%s: assertion '%s' failed") at gmessages.c:1403 #3 0x00007ffff5eea0f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", pretty_function=pretty_function@entry=0x7ffff673fc10 <__func__.25628> "g_dbus_proxy_call_internal", expression=expression@entry=0x7ffff673fb1c "G_IS_DBUS_PROXY (proxy)") at gmessages.c:2702 #4 0x00007ffff66cdc5f in g_dbus_proxy_call_internal (proxy=0x0, method_name=method_name@entry=0x555555810510 "Scan", parameters=0x555555c7a530, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, fd_list=fd_list@entry=0x0, cancellable=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2664 #5 0x00007ffff66cf686 in g_dbus_proxy_call (proxy=<optimized out>, method_name=method_name@entry=0x555555810510 "Scan", parameters=<optimized out>, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, cancellable=cancellable@entry=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2970 #6 0x000055555574e026 in nm_supplicant_interface_request_scan (self=0x555555ac2220 [NMSupplicantInterface], ssids=ssids@entry=0x0) at src/supplicant/nm-supplicant-interface.c:1821 #7 0x00007fffe1038276 in request_wireless_scan (self=self@entry=0x555555c6ee60 [NMDeviceWifi], periodic=periodic@entry=0, force_if_scanning=force_if_scanning@entry=0, ssids=<optimized out>, ssids@entry=0x0) at src/devices/wifi/nm-device-wifi.c:1347 #8 0x00007fffe1039011 in device_state_changed (device=0x555555c6ee60 [NMDeviceWifi], new_state=NM_DEVICE_STATE_DISCONNECTED, old_state=<optimized out>, reason=<optimized out>) at src/devices/wifi/nm-device-wifi.c:2998 #9 0x00007ffff432ed1e in ffi_call_unix64 () at ../src/x86/unix64.S:76 #10 0x00007ffff432e68f in ffi_call (cif=cif@entry=0x7fffffffdc70, fn=fn@entry=0x7fffe1038e1e <device_state_changed>, rvalue=<optimized out>, avalue=avalue@entry=0x7fffffffdb60) at ../src/x86/ffi64.c:525 #15 0x00007ffff63db66f in <emit signal ??? on instance 0x555555c6ee60 [NMDeviceWifi]> (instance=instance@entry=0x555555c6ee60, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3447 #11 0x00007ffff63bff39 in g_cclosure_marshal_generic (closure=0x555555c22ea0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gclosure.c:1490 #12 0x00007ffff63bf73d in g_closure_invoke (closure=0x555555c22ea0, return_value=0x0, n_param_values=4, param_values=0x7fffffffdea0, invocation_hint=0x7fffffffde20) at gclosure.c:804 #13 0x00007ffff63d1f30 in signal_emit_unlocked_R (node=node@entry=0x555555c22750, detail=detail@entry=0, instance=instance@entry=0x555555c6ee60, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffdea0) at gsignal.c:3673 #14 0x00007ffff63dad05 in g_signal_emit_valist (instance=0x555555c6ee60, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffe0b0) at gsignal.c:3391 #16 0x00005555556f0f18 in _set_state_full (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED, quitting=quitting@entry=0) at src/devices/nm-device.c:13268 #17 0x00005555556f1774 in nm_device_state_changed (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED) at src/devices/nm-device.c:13435 #18 0x00005555555bcf95 in recheck_assume_connection (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi]) at src/nm-manager.c:2297 #19 0x00005555555bd53e in _device_realize_finish (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi], plink=plink@entry=0x555555ae43d8) at src/nm-manager.c:2473 #20 0x00005555555c01d0 in platform_link_added (self=self@entry=0x555555b09140 [NMManager], ifindex=<optimized out>, plink=plink@entry=0x555555ae43d8, guess_assume=<optimized out>, dev_state=<optimized out>) at src/nm-manager.c:2789 #21 0x00005555555c0cec in platform_query_devices (self=self@entry=0x555555b09140 [NMManager]) at src/nm-manager.c:2901 #22 0x00005555555c439e in nm_manager_start (self=0x555555b09140 [NMManager], error=<optimized out>) at src/nm-manager.c:5632 #23 0x000055555558498e in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:413
2018-04-04 14:48:52 +02:00
}
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
nm_device_assume_state_get (device,
&assume_state_guess_assume,
&assume_state_connection_uuid);
core: match connections to connections instead of devices This backwards compatible patch adds the possibility to use new nm_device_generate_connection() API via update_connection() virtual method implementations in NMDevice subclasses. Compatibility is achieved by first trying to use the older API and match_l2_config() virtual method and only then moving on to update_connection(). The nm_device_generate_connection() calls update_connection() to create type-specific NMSetting instances and verifies the connection before returning it. To avoid tinkering with NMSettingConnection in update_connection() we use a class attribute called connection_type which is used by nm_device_generate_connection() itself. Known issues: * nm_device_generate_connection() method doesn't implement DHCP lease configuration matching. We shouldn't actually need it but if a use case for that will come out, we can fix it later. * nm_device_generate_connection() doesn't fill in the slave-specific options. * update_connection() is not implemented and connection_type is not set in the subclasses. This will be fixed in individual patches. * NMSetting's compare_property() implementations in combination with NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering false negatives in some cases. Same as above. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-06-27 14:39:13 +02:00
Revert "core: merge branch 'bg/restart-assume-rh1551958'" This reverts commit cc1920d71470042c4e0837848da9183526b663d0, reversing changes made to eb8257dea5802a004af9cccacb30af98440e2172. This breaks restart, at least for Wi-Fi devices: #0 0x00007ffff5ee8771 in _g_log_abort (breakpoint=breakpoint@entry=1) at gmessages.c:554 #1 0x00007ffff5ee9a5b in g_logv (log_domain=0x7ffff671a738 "GLib-GIO", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd720) at gmessages.c:1362 #2 0x00007ffff5ee9baf in g_log (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff5f347ea "%s: assertion '%s' failed") at gmessages.c:1403 #3 0x00007ffff5eea0f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff671a738 "GLib-GIO", pretty_function=pretty_function@entry=0x7ffff673fc10 <__func__.25628> "g_dbus_proxy_call_internal", expression=expression@entry=0x7ffff673fb1c "G_IS_DBUS_PROXY (proxy)") at gmessages.c:2702 #4 0x00007ffff66cdc5f in g_dbus_proxy_call_internal (proxy=0x0, method_name=method_name@entry=0x555555810510 "Scan", parameters=0x555555c7a530, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, fd_list=fd_list@entry=0x0, cancellable=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2664 #5 0x00007ffff66cf686 in g_dbus_proxy_call (proxy=<optimized out>, method_name=method_name@entry=0x555555810510 "Scan", parameters=<optimized out>, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, cancellable=cancellable@entry=0x0, callback=0x55555574cb96 <scan_request_cb>, user_data=0x555555ac2220) at gdbusproxy.c:2970 #6 0x000055555574e026 in nm_supplicant_interface_request_scan (self=0x555555ac2220 [NMSupplicantInterface], ssids=ssids@entry=0x0) at src/supplicant/nm-supplicant-interface.c:1821 #7 0x00007fffe1038276 in request_wireless_scan (self=self@entry=0x555555c6ee60 [NMDeviceWifi], periodic=periodic@entry=0, force_if_scanning=force_if_scanning@entry=0, ssids=<optimized out>, ssids@entry=0x0) at src/devices/wifi/nm-device-wifi.c:1347 #8 0x00007fffe1039011 in device_state_changed (device=0x555555c6ee60 [NMDeviceWifi], new_state=NM_DEVICE_STATE_DISCONNECTED, old_state=<optimized out>, reason=<optimized out>) at src/devices/wifi/nm-device-wifi.c:2998 #9 0x00007ffff432ed1e in ffi_call_unix64 () at ../src/x86/unix64.S:76 #10 0x00007ffff432e68f in ffi_call (cif=cif@entry=0x7fffffffdc70, fn=fn@entry=0x7fffe1038e1e <device_state_changed>, rvalue=<optimized out>, avalue=avalue@entry=0x7fffffffdb60) at ../src/x86/ffi64.c:525 #15 0x00007ffff63db66f in <emit signal ??? on instance 0x555555c6ee60 [NMDeviceWifi]> (instance=instance@entry=0x555555c6ee60, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3447 #11 0x00007ffff63bff39 in g_cclosure_marshal_generic (closure=0x555555c22ea0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gclosure.c:1490 #12 0x00007ffff63bf73d in g_closure_invoke (closure=0x555555c22ea0, return_value=0x0, n_param_values=4, param_values=0x7fffffffdea0, invocation_hint=0x7fffffffde20) at gclosure.c:804 #13 0x00007ffff63d1f30 in signal_emit_unlocked_R (node=node@entry=0x555555c22750, detail=detail@entry=0, instance=instance@entry=0x555555c6ee60, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffdea0) at gsignal.c:3673 #14 0x00007ffff63dad05 in g_signal_emit_valist (instance=0x555555c6ee60, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffe0b0) at gsignal.c:3391 #16 0x00005555556f0f18 in _set_state_full (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED, quitting=quitting@entry=0) at src/devices/nm-device.c:13268 #17 0x00005555556f1774 in nm_device_state_changed (self=self@entry=0x555555c6ee60 [NMDeviceWifi], state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED) at src/devices/nm-device.c:13435 #18 0x00005555555bcf95 in recheck_assume_connection (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi]) at src/nm-manager.c:2297 #19 0x00005555555bd53e in _device_realize_finish (self=self@entry=0x555555b09140 [NMManager], device=device@entry=0x555555c6ee60 [NMDeviceWifi], plink=plink@entry=0x555555ae43d8) at src/nm-manager.c:2473 #20 0x00005555555c01d0 in platform_link_added (self=self@entry=0x555555b09140 [NMManager], ifindex=<optimized out>, plink=plink@entry=0x555555ae43d8, guess_assume=<optimized out>, dev_state=<optimized out>) at src/nm-manager.c:2789 #21 0x00005555555c0cec in platform_query_devices (self=self@entry=0x555555b09140 [NMManager]) at src/nm-manager.c:2901 #22 0x00005555555c439e in nm_manager_start (self=0x555555b09140 [NMManager], error=<optimized out>) at src/nm-manager.c:5632 #23 0x000055555558498e in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:413
2018-04-04 14:48:52 +02:00
/* Now we need to compare the generated connection to each configured
* connection. The comparison function is the heart of the connection
* assumption implementation and it must compare the connections very
* carefully to sort out various corner cases. Also, the comparison is
* not entirely symmetric.
*
* When no configured connection matches the generated connection, we keep
* the generated connection instead.
*/
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
if ( assume_state_connection_uuid
&& (connection_checked = nm_settings_get_connection_by_uuid (priv->settings, assume_state_connection_uuid))
manager: fix assuming multi-connect connections When assuming existing connections, allow the same connection to be activated on a different device if the connection is multi-connect capable. Otherwise, when a connection is active on multiple devices and NM is restarted, we assume only the first instance, and create in-memory connections for others.
2018-08-08 11:33:31 +02:00
&& new_activation_allowed_for_connection (self, connection_checked)
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
&& nm_device_check_connection_compatible (device,
nm_settings_connection_get_connection (connection_checked),
NULL)) {
manager: trust the state file more when assuming connections If we can't generate a connection and maybe_later is TRUE, it means that the device can generate/assume connections but it failed for the moment due to missing master/slaves/addresses. In this case, just assume the connection from state file. https://bugzilla.redhat.com/show_bug.cgi?id=1551958
2018-04-05 11:19:54 +02:00
if (connection) {
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMConnection *con = nm_settings_connection_get_connection (connection_checked);
if (nm_utils_match_connection ((NMConnection *[]) { con, NULL },
connection,
TRUE,
nm_device_has_carrier (device),
nm_device_get_route_metric (device, AF_INET),
nm_device_get_route_metric (device, AF_INET6),
NULL, NULL))
matched = connection_checked;
manager: trust the state file more when assuming connections If we can't generate a connection and maybe_later is TRUE, it means that the device can generate/assume connections but it failed for the moment due to missing master/slaves/addresses. In this case, just assume the connection from state file. https://bugzilla.redhat.com/show_bug.cgi?id=1551958
2018-04-05 11:19:54 +02:00
} else
matched = connection_checked;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
}
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
manager: trust the state file more when assuming connections If we can't generate a connection and maybe_later is TRUE, it means that the device can generate/assume connections but it failed for the moment due to missing master/slaves/addresses. In this case, just assume the connection from state file. https://bugzilla.redhat.com/show_bug.cgi?id=1551958
2018-04-05 11:19:54 +02:00
if (!matched && only_by_uuid) {
_LOG2D (LOGD_DEVICE, device, "assume: cannot generate connection: %s",
gen_error->message);
return NULL;
}
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
if (!matched && assume_state_guess_assume) {
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
gs_free NMSettingsConnection **sett_conns = NULL;
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
guint len, i, j;
/* the state file doesn't indicate a connection UUID to assume. Search the
* persistent connections for a matching candidate. */
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conns = nm_manager_get_activatable_connections (self, FALSE, FALSE, &len);
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
if (len > 0) {
for (i = 0, j = 0; i < len; i++) {
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn = sett_conns[i];
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if ( sett_conn != connection_checked
&& nm_device_check_connection_compatible (device,
nm_settings_connection_get_connection (sett_conn),
NULL))
sett_conns[j++] = sett_conn;
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
}
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conns[j] = NULL;
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
len = j;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (len > 0) {
gs_free NMConnection **conns = NULL;
NMConnection *con;
g_qsort_with_data (sett_conns, len, sizeof (sett_conns[0]),
nm_settings_connection_cmp_timestamp_p_with_data, NULL);
conns = nm_settings_connections_array_to_connections (sett_conns, len);
con = nm_utils_match_connection (conns,
connection,
FALSE,
nm_device_has_carrier (device),
nm_device_get_route_metric (device, AF_INET),
nm_device_get_route_metric (device, AF_INET6),
NULL,
NULL);
if (con) {
for (i = 0; i < len; i++) {
if (conns[i] == con) {
matched = sett_conns[i];
break;
}
}
nm_assert (matched);
}
}
core: only assume connections that were managed in a previous run of NetworkManager Before, we would have the concept of assumed connections, which is used for (1) externally configured device that NetworkManager should not touch and (2) connections that NetworkManager should gracefully take over after a restart (seamlessly, non-destructively). The behavior was unclear and mixed. It wasn't clear whether the device is in no-touch mode (1) or gracefully take-over (2). Previous commits already introduce separate activation types EXTERNAL (1) and ASSUME (2). Also, previously, we would for both (1) and (2) try to find a matching connection and use it. That doesn't make sense for either. In the external case (1), we should not pretend that an existing connection is active. Let's always create a new in-memory connection for these cases. Note that this means, external devices now will always generate a connection, instead of pretending an existing one is active. For the assume case (2), we shall not use nm_utils_match_connection() to guess which connection might be active. It can only the one that was active on a previous run of NetworkManager. So, use the information from the state file and try to activate it. If that fails, it is not an assume activation type. Note, that this means we now most of the time don't do ASSUME anymore. Most of the time we do EXTERNAL activation That is because the state information is only available after restart of NetworkManager.
2017-03-08 08:45:11 +01:00
}
core: match connections to connections instead of devices This backwards compatible patch adds the possibility to use new nm_device_generate_connection() API via update_connection() virtual method implementations in NMDevice subclasses. Compatibility is achieved by first trying to use the older API and match_l2_config() virtual method and only then moving on to update_connection(). The nm_device_generate_connection() calls update_connection() to create type-specific NMSetting instances and verifies the connection before returning it. To avoid tinkering with NMSettingConnection in update_connection() we use a class attribute called connection_type which is used by nm_device_generate_connection() itself. Known issues: * nm_device_generate_connection() method doesn't implement DHCP lease configuration matching. We shouldn't actually need it but if a use case for that will come out, we can fix it later. * nm_device_generate_connection() doesn't fill in the slave-specific options. * update_connection() is not implemented and connection_type is not set in the subclasses. This will be fixed in individual patches. * NMSetting's compare_property() implementations in combination with NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering false negatives in some cases. Same as above. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-06-27 14:39:13 +02:00
}
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
if (matched) {
manager: cleanup logging message during recheck_assume_connection()/get_existing_connection() recheck_assume_connection() calls get_existing_connection(). We want *one* logging message telling what's happening. Let get_existing_connection() log "assume:" messages and remove duplicate messages from recheck_assume_connection().
2017-06-07 16:41:06 +02:00
_LOG2I (LOGD_DEVICE, device, "assume: will attempt to assume matching connection '%s' (%s)%s",
manager: add logging macro _NMLOG2() for logging device messages It unifies the way how we print the logging prefix, but also it passes the ifname down for structured logging.
2017-06-07 12:46:10 +02:00
nm_settings_connection_get_id (matched),
nm_settings_connection_get_uuid (matched),
assume_state_connection_uuid && nm_streq (assume_state_connection_uuid, nm_settings_connection_get_uuid (matched))
? " (indicated)" : " (guessed)");
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
nm_device_assume_state_reset (device);
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
return matched;
}
manager: cleanup logging message during recheck_assume_connection()/get_existing_connection() recheck_assume_connection() calls get_existing_connection(). We want *one* logging message telling what's happening. Let get_existing_connection() log "assume:" messages and remove duplicate messages from recheck_assume_connection().
2017-06-07 16:41:06 +02:00
_LOG2D (LOGD_DEVICE, device, "assume: generated connection '%s' (%s)",
nm_connection_get_id (connection),
nm_connection_get_uuid (connection));
core: add device-generated connection to settings 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>
2013-08-23 15:45:17 +02:00
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
nm_device_assume_state_reset (device);
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
if (!nm_settings_add_connection (priv->settings,
connection,
NM_SETTINGS_CONNECTION_PERSIST_MODE_IN_MEMORY_ONLY,
core,libnm: add AddConnection2() D-Bus API to block autoconnect from the start It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
2019-07-09 15:22:01 +02:00
NM_SETTINGS_CONNECTION_ADD_REASON_NONE,
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE
| NM_SETTINGS_CONNECTION_INT_FLAGS_NM_GENERATED,
&added,
&error)) {
manager: cleanup logging message during recheck_assume_connection()/get_existing_connection() recheck_assume_connection() calls get_existing_connection(). We want *one* logging message telling what's happening. Let get_existing_connection() log "assume:" messages and remove duplicate messages from recheck_assume_connection().
2017-06-07 16:41:06 +02:00
_LOG2W (LOGD_SETTINGS, device, "assume: failure to save generated connection '%s': %s",
manager: use logging helpers
2016-03-02 11:38:26 +01:00
nm_connection_get_id (connection),
all: clean-up usage of GError Functions that take a GError** MUST fill it in on error. There is no need to check whether error is NULL if the function it was passed to had a failing return value. Likewise, a proper GError must have a non-NULL message, so there's no need to double-check that either. Based-on-patch-by: Dan Winship <danw@gnome.org>
2016-02-28 16:25:36 +01:00
error->message);
manager: cleanup logging message during recheck_assume_connection()/get_existing_connection() recheck_assume_connection() calls get_existing_connection(). We want *one* logging message telling what's happening. Let get_existing_connection() log "assume:" messages and remove duplicate messages from recheck_assume_connection().
2017-06-07 16:41:06 +02:00
g_error_free (error);
return NULL;
core: add device-generated connection to settings 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>
2013-08-23 15:45:17 +02:00
}
manager: cleanup logging message during recheck_assume_connection()/get_existing_connection() recheck_assume_connection() calls get_existing_connection(). We want *one* logging message telling what's happening. Let get_existing_connection() log "assume:" messages and remove duplicate messages from recheck_assume_connection().
2017-06-07 16:41:06 +02:00
NM_SET_OUT (out_generated, TRUE);
return added;
core: match connections to connections instead of devices This backwards compatible patch adds the possibility to use new nm_device_generate_connection() API via update_connection() virtual method implementations in NMDevice subclasses. Compatibility is achieved by first trying to use the older API and match_l2_config() virtual method and only then moving on to update_connection(). The nm_device_generate_connection() calls update_connection() to create type-specific NMSetting instances and verifies the connection before returning it. To avoid tinkering with NMSettingConnection in update_connection() we use a class attribute called connection_type which is used by nm_device_generate_connection() itself. Known issues: * nm_device_generate_connection() method doesn't implement DHCP lease configuration matching. We shouldn't actually need it but if a use case for that will come out, we can fix it later. * nm_device_generate_connection() doesn't fill in the slave-specific options. * update_connection() is not implemented and connection_type is not set in the subclasses. This will be fixed in individual patches. * NMSetting's compare_property() implementations in combination with NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering false negatives in some cases. Same as above. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-06-27 14:39:13 +02:00
}
core: clean up nm-generated-assumed connections when assumption fails or connection disconnects https://bugzilla.gnome.org/show_bug.cgi?id=731937 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-20 20:13:14 +02:00
static gboolean
core: only assume connections that were managed in a previous run of NetworkManager Before, we would have the concept of assumed connections, which is used for (1) externally configured device that NetworkManager should not touch and (2) connections that NetworkManager should gracefully take over after a restart (seamlessly, non-destructively). The behavior was unclear and mixed. It wasn't clear whether the device is in no-touch mode (1) or gracefully take-over (2). Previous commits already introduce separate activation types EXTERNAL (1) and ASSUME (2). Also, previously, we would for both (1) and (2) try to find a matching connection and use it. That doesn't make sense for either. In the external case (1), we should not pretend that an existing connection is active. Let's always create a new in-memory connection for these cases. Note that this means, external devices now will always generate a connection, instead of pretending an existing one is active. For the assume case (2), we shall not use nm_utils_match_connection() to guess which connection might be active. It can only the one that was active on a previous run of NetworkManager. So, use the information from the state file and try to activate it. If that fails, it is not an assume activation type. Note, that this means we now most of the time don't do ASSUME anymore. Most of the time we do EXTERNAL activation That is because the state information is only available after restart of NetworkManager.
2017-03-08 08:45:11 +01:00
recheck_assume_connection (NMManager *self,
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
NMDevice *device)
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
{
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn;
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
gboolean was_unmanaged = FALSE;
gboolean generated = FALSE;
core: recheck_assume_connection() do nothing if the device is not disconnected Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-01 22:46:49 +02:00
NMDeviceState state;
manager: don't treat the initramfs-configured DHCP connections as generated These are special -- initramfs configured them and killed dhclient. Bad things would happen if we let the addresses expire though. Let's act as if initramfs actually passed the configuration to us. It actually tries to do so by the means of writing an ifcfg file, but that one is too broken to be useful, so the ifcfg-rh plugin ignores it. Notably, it doesn't have the actual addresses or correct BOOTPROTO. The generated connection is better. Co-authored-by: Thomas Haller <thaller@redhat.com> (cherry picked from commit acf3e0092ad8d52ef54644d63c8e4f7f974847c7)
2019-07-31 16:12:22 +02:00
gboolean activation_type_assume;
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
core: subscribe recheck_assume_connection() early when adding device 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.
2015-12-04 17:17:47 +01:00
g_return_val_if_fail (NM_IS_MANAGER (self), FALSE);
g_return_val_if_fail (NM_IS_DEVICE (device), FALSE);
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
if (!nm_device_get_managed (device, FALSE)) {
nm_device_assume_state_reset (device);
manager: add more logging to recheck_assume_connection() and give all lines a logging prefix.
2017-06-07 13:30:08 +02:00
_LOG2D (LOGD_DEVICE, device, "assume: don't assume because %s", "not managed");
core: clean up nm-generated-assumed connections when assumption fails or connection disconnects https://bugzilla.gnome.org/show_bug.cgi?id=731937 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-20 20:13:14 +02:00
return FALSE;
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
}
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
core: fix leak of generated connection if device is active Don't generate (and add to settings) a connection if we aren't going to use it anyway.
2014-12-03 14:24:18 -06:00
state = nm_device_get_state (device);
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
if (state > NM_DEVICE_STATE_DISCONNECTED) {
nm_device_assume_state_reset (device);
manager: add more logging to recheck_assume_connection() and give all lines a logging prefix.
2017-06-07 13:30:08 +02:00
_LOG2D (LOGD_DEVICE, device, "assume: don't assume due to device state %s",
nm_device_state_to_str (state));
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
return FALSE;
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
}
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn = get_existing_connection (self, device, &generated);
manager: cleanup logging message during recheck_assume_connection()/get_existing_connection() recheck_assume_connection() calls get_existing_connection(). We want *one* logging message telling what's happening. Let get_existing_connection() log "assume:" messages and remove duplicate messages from recheck_assume_connection().
2017-06-07 16:41:06 +02:00
/* log no reason. get_existing_connection() already does it. */
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (!sett_conn)
core: clean up nm-generated-assumed connections when assumption fails or connection disconnects https://bugzilla.gnome.org/show_bug.cgi?id=731937 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-20 20:13:14 +02:00
return FALSE;
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
manager: don't treat the initramfs-configured DHCP connections as generated These are special -- initramfs configured them and killed dhclient. Bad things would happen if we let the addresses expire though. Let's act as if initramfs actually passed the configuration to us. It actually tries to do so by the means of writing an ifcfg file, but that one is too broken to be useful, so the ifcfg-rh plugin ignores it. Notably, it doesn't have the actual addresses or correct BOOTPROTO. The generated connection is better. Co-authored-by: Thomas Haller <thaller@redhat.com> (cherry picked from commit acf3e0092ad8d52ef54644d63c8e4f7f974847c7)
2019-07-31 16:12:22 +02:00
activation_type_assume = !generated;
if (state == NM_DEVICE_STATE_UNMANAGED) {
gs_free char *initramfs_lease = g_strdup_printf (RUNSTATEDIR "/initramfs/net.%s.lease",
nm_device_get_iface (device));
gs_free char *connection_lease = g_strdup_printf (NMRUNDIR "/dhclient-%s-%s.lease",
nm_settings_connection_get_uuid (sett_conn),
nm_device_get_iface (device));
if (rename (initramfs_lease, connection_lease) == 0) {
/*
* We've managed to steal the lease used by initramfs before it
* killed off the dhclient. We need to take ownership of the configured
* connection and act like the device was configured by us.
* Otherwise the address would just expire.
*/
_LOG2I (LOGD_DEVICE, device, "assume: taking over an initramfs-configured connection");
activation_type_assume = TRUE;
if (generated) {
manager: assume DHCP if we see a lease on taking over an initramfs connection In general, we aren't really able to tell, but when we see a lease file we're pretty sure that DHCP is what was going on. https://bugzilla.redhat.com/show_bug.cgi?id=1771792 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/335 Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated')
2019-11-15 22:09:14 +01:00
/* Reset the IPv4 setting to empty method=auto, regardless of what assumption guessed. */
nm_connection_add_setting (nm_settings_connection_get_connection (sett_conn),
g_object_new (NM_TYPE_SETTING_IP4_CONFIG,
NM_SETTING_IP_CONFIG_METHOD, NM_SETTING_IP4_CONFIG_METHOD_AUTO,
NULL));
manager: don't treat the initramfs-configured DHCP connections as generated These are special -- initramfs configured them and killed dhclient. Bad things would happen if we let the addresses expire though. Let's act as if initramfs actually passed the configuration to us. It actually tries to do so by the means of writing an ifcfg file, but that one is too broken to be useful, so the ifcfg-rh plugin ignores it. Notably, it doesn't have the actual addresses or correct BOOTPROTO. The generated connection is better. Co-authored-by: Thomas Haller <thaller@redhat.com> (cherry picked from commit acf3e0092ad8d52ef54644d63c8e4f7f974847c7)
2019-07-31 16:12:22 +02:00
nm_settings_connection_update (sett_conn,
NULL,
NM_SETTINGS_CONNECTION_PERSIST_MODE_KEEP,
0,
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE,
NM_SETTINGS_CONNECTION_UPDATE_REASON_NONE,
"assume-initrd",
NULL);
}
}
}
device: mark device as sys-iface-state=external when assuming connection Since commit 74dac5f (nm-manager: try assuming connections on managed devices), and commit f4226e7 (manager: avoid generating in memory connections during startup for managed devices), recheck_assume_connection() also assumes connections on devices that are currently not in sys-iface-state "external". That is correct, as also for fully managed devices (which are currently in disconnected state), we want to assume external connections. However, when doing that, we must reset the sys-iface-state to external. https://bugzilla.redhat.com/show_bug.cgi?id=1457242
2017-06-01 22:04:26 +02:00
nm_device_sys_iface_state_set (device,
manager: don't treat the initramfs-configured DHCP connections as generated These are special -- initramfs configured them and killed dhclient. Bad things would happen if we let the addresses expire though. Let's act as if initramfs actually passed the configuration to us. It actually tries to do so by the means of writing an ifcfg file, but that one is too broken to be useful, so the ifcfg-rh plugin ignores it. Notably, it doesn't have the actual addresses or correct BOOTPROTO. The generated connection is better. Co-authored-by: Thomas Haller <thaller@redhat.com> (cherry picked from commit acf3e0092ad8d52ef54644d63c8e4f7f974847c7)
2019-07-31 16:12:22 +02:00
activation_type_assume
? NM_DEVICE_SYS_IFACE_STATE_ASSUME
: NM_DEVICE_SYS_IFACE_STATE_EXTERNAL);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
/* Move device to DISCONNECTED to activate the connection */
core: recheck_assume_connection() do nothing if the device is not disconnected Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-01 22:46:49 +02:00
if (state == NM_DEVICE_STATE_UNMANAGED) {
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
was_unmanaged = TRUE;
nm_device_state_changed (device,
NM_DEVICE_STATE_UNAVAILABLE,
NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED);
}
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
if (nm_device_get_state (device) == NM_DEVICE_STATE_UNAVAILABLE) {
nm_device_state_changed (device,
NM_DEVICE_STATE_DISCONNECTED,
NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED);
}
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
g_return_val_if_fail (nm_device_get_state (device) >= NM_DEVICE_STATE_DISCONNECTED, FALSE);
{
gs_unref_object NMActiveConnection *active = NULL;
gs_unref_object NMAuthSubject *subject = NULL;
NMActiveConnection *master_ac;
GError *error = NULL;
subject = nm_auth_subject_new_internal ();
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
all: fix misspellings https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/64
2019-01-11 17:07:03 -02:00
/* Note: the lifetime of the activation connection is always bound to the profiles visibility
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
* via NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY.
*
* This only makes a difference, if the profile actually has "connection.permissions"
* set to limit visibility (which is not the case for externally managed, generated profiles).
*
* If we assume a previously active connection whose lifetime was unbound, we now bind it
* after restart. That is not correct, and can mean that the profile becomes subject to
* deactivation after restart (if the user logs out).
*
* This should be improved, but it's unclear how. */
manager: add is-vpn argument to _new_active_connection() and avoid searching existing activations - pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection() would re-determine whether a connection is a VPN type, although that was already established previously. The confusing part is: will they come to the same result? Why? What if not? Instead pass it as argument and assert that we got it right. - the check for existing connections should look whether there is an existing active connection of type NMVpnConnection. Instead, what matters is, - do we have a connection of type VPN (otherwise, don't even bother to search for existing-ac) - is the connection already active? Checking whether the connection is already active, and ask backwards whether it's of type NMVpnConnection is odd, maybe even wrong in some cases.
2018-04-12 11:32:18 +02:00
active = _new_active_connection (self,
FALSE,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn,
NULL,
manager: add is-vpn argument to _new_active_connection() and avoid searching existing activations - pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection() would re-determine whether a connection is a VPN type, although that was already established previously. The confusing part is: will they come to the same result? Why? What if not? Instead pass it as argument and assert that we got it right. - the check for existing connections should look whether there is an existing active connection of type NMVpnConnection. Instead, what matters is, - do we have a connection of type VPN (otherwise, don't even bother to search for existing-ac) - is the connection already active? Checking whether the connection is already active, and ask backwards whether it's of type NMVpnConnection is odd, maybe even wrong in some cases.
2018-04-12 11:32:18 +02:00
NULL,
NULL,
device,
subject,
manager: don't treat the initramfs-configured DHCP connections as generated These are special -- initramfs configured them and killed dhclient. Bad things would happen if we let the addresses expire though. Let's act as if initramfs actually passed the configuration to us. It actually tries to do so by the means of writing an ifcfg file, but that one is too broken to be useful, so the ifcfg-rh plugin ignores it. Notably, it doesn't have the actual addresses or correct BOOTPROTO. The generated connection is better. Co-authored-by: Thomas Haller <thaller@redhat.com> (cherry picked from commit acf3e0092ad8d52ef54644d63c8e4f7f974847c7)
2019-07-31 16:12:22 +02:00
activation_type_assume ? NM_ACTIVATION_TYPE_ASSUME : NM_ACTIVATION_TYPE_EXTERNAL,
activation_type_assume ? NM_ACTIVATION_REASON_ASSUME : NM_ACTIVATION_REASON_EXTERNAL,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY,
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
&error);
if (!active) {
manager: add more logging to recheck_assume_connection() and give all lines a logging prefix.
2017-06-07 13:30:08 +02:00
_LOGW (LOGD_DEVICE, "assume: assumed connection %s failed to activate: %s",
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_dbus_object_get_path (NM_DBUS_OBJECT (sett_conn)),
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
error->message);
g_error_free (error);
if (was_unmanaged) {
nm_device_state_changed (device,
NM_DEVICE_STATE_UNAVAILABLE,
NM_DEVICE_STATE_REASON_CONFIG_FAILED);
}
core: clean up nm-generated-assumed connections when assumption fails or connection disconnects https://bugzilla.gnome.org/show_bug.cgi?id=731937 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-20 20:13:14 +02:00
manager: don't treat the initramfs-configured DHCP connections as generated These are special -- initramfs configured them and killed dhclient. Bad things would happen if we let the addresses expire though. Let's act as if initramfs actually passed the configuration to us. It actually tries to do so by the means of writing an ifcfg file, but that one is too broken to be useful, so the ifcfg-rh plugin ignores it. Notably, it doesn't have the actual addresses or correct BOOTPROTO. The generated connection is better. Co-authored-by: Thomas Haller <thaller@redhat.com> (cherry picked from commit acf3e0092ad8d52ef54644d63c8e4f7f974847c7)
2019-07-31 16:12:22 +02:00
if ( generated
&& !activation_type_assume) {
manager: add more logging to recheck_assume_connection() and give all lines a logging prefix.
2017-06-07 13:30:08 +02:00
_LOG2D (LOGD_DEVICE, device, "assume: deleting generated connection after assuming failed");
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
nm_settings_connection_delete (sett_conn, FALSE);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
} else {
if (nm_device_sys_iface_state_get (device) == NM_DEVICE_SYS_IFACE_STATE_ASSUME)
nm_device_sys_iface_state_set (device, NM_DEVICE_SYS_IFACE_STATE_EXTERNAL);
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
}
return FALSE;
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
}
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
/* If the device is a slave or VLAN, find the master ActiveConnection */
master_ac = NULL;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if ( find_master (self,
nm_settings_connection_get_connection (sett_conn),
device,
NULL,
NULL,
&master_ac,
NULL)
&& master_ac)
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
nm_active_connection_set_master (active, master_ac);
active_connection_add (self, active);
nm_device_queue_activation (device, NM_ACT_REQUEST (active));
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
}
core: clean up nm-generated-assumed connections when assumption fails or connection disconnects https://bugzilla.gnome.org/show_bug.cgi?id=731937 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-20 20:13:14 +02:00
manager: merge/inline assume_connection() in recheck_assume_connection() There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
2017-03-09 16:58:37 +01:00
return TRUE;
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
}
core: subscribe recheck_assume_connection() early when adding device 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.
2015-12-04 17:17:47 +01:00
static void
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
recheck_assume_connection_cb (NMManager *self, NMDevice *device)
core: subscribe recheck_assume_connection() early when adding device 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.
2015-12-04 17:17:47 +01:00
{
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
recheck_assume_connection (self, device);
core: subscribe recheck_assume_connection() early when adding device 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.
2015-12-04 17:17:47 +01:00
}
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
static void
device_ifindex_changed (NMDevice *device,
GParamSpec *pspec,
NMManager *self)
{
_parent_notify_changed (self, device, FALSE);
}
core: remove child devices when a parent's ip_iface becomes known Child devices shouldn't be exposed as real NMDevices (yet) since the configuration and life cycle is controlled by the parent. We already do this if the ip_iface is known when the child device is added, but PPP and other transient interfaces often show up just before we know the parent's ip_iface.
2014-06-12 13:27:14 -05:00
static void
device_ip_iface_changed (NMDevice *device,
GParamSpec *pspec,
NMManager *self)
{
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: remove child devices when a parent's ip_iface becomes known Child devices shouldn't be exposed as real NMDevices (yet) since the configuration and life cycle is controlled by the parent. We already do this if the ip_iface is known when the child device is added, but PPP and other transient interfaces often show up just before we know the parent's ip_iface.
2014-06-12 13:27:14 -05:00
const char *ip_iface = nm_device_get_ip_iface (device);
manager: match device type when removing an ip interface Otherwise we might end up removing a wrong device of a same name.
2017-10-12 14:53:43 +02:00
NMDeviceType device_type = nm_device_get_device_type (device);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *candidate;
core: remove child devices when a parent's ip_iface becomes known Child devices shouldn't be exposed as real NMDevices (yet) since the configuration and life cycle is controlled by the parent. We already do this if the ip_iface is known when the child device is added, but PPP and other transient interfaces often show up just before we know the parent's ip_iface.
2014-06-12 13:27:14 -05:00
/* Remove NMDevice objects that are actually child devices of others,
* when the other device finally knows its IP interface name. For example,
* remove the PPP interface that's a child of a WWAN device, since it's
* not really a standalone NMDevice.
*/
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (candidate, &priv->devices_lst_head, devices_lst) {
core: remove child devices when a parent's ip_iface becomes known Child devices shouldn't be exposed as real NMDevices (yet) since the configuration and life cycle is controlled by the parent. We already do this if the ip_iface is known when the child device is added, but PPP and other transient interfaces often show up just before we know the parent's ip_iface.
2014-06-12 13:27:14 -05:00
if ( candidate != device
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
&& g_strcmp0 (nm_device_get_iface (candidate), ip_iface) == 0
manager: match device type when removing an ip interface Otherwise we might end up removing a wrong device of a same name.
2017-10-12 14:53:43 +02:00
&& nm_device_get_device_type (candidate) == device_type
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
&& nm_device_is_real (candidate)) {
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
remove_device (self, candidate, FALSE);
core: remove child devices when a parent's ip_iface becomes known Child devices shouldn't be exposed as real NMDevices (yet) since the configuration and life cycle is controlled by the parent. We already do this if the ip_iface is known when the child device is added, but PPP and other transient interfaces often show up just before we know the parent's ip_iface.
2014-06-12 13:27:14 -05:00
break;
}
}
}
manager: retry virtual connections when a device is added or changes 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 d8e1590c5058 ("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
2016-01-07 17:54:38 +01:00
static void
device_iface_changed (NMDevice *device,
GParamSpec *pspec,
NMManager *self)
{
/* Virtual connections may refer to the new device name as
* parent device, retry to activate them.
*/
retry_connections_for_parent_device (self, device);
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
static void
_emit_device_added_removed (NMManager *self,
NMDevice *device,
gboolean is_added)
{
nm_dbus_object_emit_signal (NM_DBUS_OBJECT (self),
&interface_info_manager,
is_added
? &signal_info_device_added
: &signal_info_device_removed,
"(o)",
nm_dbus_object_get_path (NM_DBUS_OBJECT (device)));
g_signal_emit (self,
signals[is_added ? DEVICE_ADDED : DEVICE_REMOVED],
0,
device);
_notify (self, PROP_DEVICES);
}
manager: retry virtual connections when a device is added or changes 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 d8e1590c5058 ("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
2016-01-07 17:54:38 +01:00
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
static void
device_realized (NMDevice *device,
GParamSpec *pspec,
NMManager *self)
{
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
_emit_device_added_removed (self, device, nm_device_is_real (device));
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
}
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
connectivity: consider default route for global connectivity state When we agregate the connectivity state, only devices that have the best default route should be considered. Since we do connectivity checking per-device, the per-device check does not care whether traffic to the internet is really routed via this device. But when talking about the global connectivity state, we care mostly about the (best) default route. So, we should not allow a device with worse or now default route, to contribute its connectivity state. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39
2018-12-03 11:09:39 +01:00
static NMConnectivityState
_get_best_connectivity (NMManager *self, int addr_family)
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
connectivity: consider default route for global connectivity state When we agregate the connectivity state, only devices that have the best default route should be considered. Since we do connectivity checking per-device, the per-device check does not care whether traffic to the internet is really routed via this device. But when talking about the global connectivity state, we care mostly about the (best) default route. So, we should not allow a device with worse or now default route, to contribute its connectivity state. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39
2018-12-03 11:09:39 +01:00
NMConnectivityState best_state;
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *dev;
connectivity: consider default route for global connectivity state When we agregate the connectivity state, only devices that have the best default route should be considered. Since we do connectivity checking per-device, the per-device check does not care whether traffic to the internet is really routed via this device. But when talking about the global connectivity state, we care mostly about the (best) default route. So, we should not allow a device with worse or now default route, to contribute its connectivity state. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39
2018-12-03 11:09:39 +01:00
gint64 best_metric;
if (addr_family == AF_UNSPEC) {
best_state = _get_best_connectivity (self, AF_INET);
if (nm_connectivity_state_cmp (best_state, NM_CONNECTIVITY_FULL) >= 0) {
/* already FULL IPv4 connectivity. No need to check IPv6, it doesn't get
* better. */
return best_state;
}
return NM_MAX_WITH_CMP (nm_connectivity_state_cmp,
best_state,
_get_best_connectivity (self, AF_INET6));
}
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
connectivity: consider default route for global connectivity state When we agregate the connectivity state, only devices that have the best default route should be considered. Since we do connectivity checking per-device, the per-device check does not care whether traffic to the internet is really routed via this device. But when talking about the global connectivity state, we care mostly about the (best) default route. So, we should not allow a device with worse or now default route, to contribute its connectivity state. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39
2018-12-03 11:09:39 +01:00
nm_assert_addr_family (addr_family);
best_state = NM_CONNECTIVITY_UNKNOWN;
best_metric = G_MAXINT64;
c_list_for_each_entry (dev, &priv->devices_lst_head, devices_lst) {
const NMPObject *r;
NMConnectivityState state;
gint64 metric;
r = nm_device_get_best_default_route (dev, addr_family);
if (r) {
metric = nm_utils_ip_route_metric_normalize (addr_family,
NMP_OBJECT_CAST_IP_ROUTE (r)->metric);
} else {
/* if all devices have no default-route, we still include the best
* of all connectivity state of all the devices. */
metric = G_MAXINT64;
}
if (metric > best_metric) {
/* we already have a default route with better metric. The connectivity state
* of this device is irreleavnt. */
continue;
}
state = nm_device_get_connectivity_state (dev, addr_family);
if (metric < best_metric) {
/* this device has a better default route. It wins. */
best_metric = metric;
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
best_state = state;
connectivity: consider default route for global connectivity state When we agregate the connectivity state, only devices that have the best default route should be considered. Since we do connectivity checking per-device, the per-device check does not care whether traffic to the internet is really routed via this device. But when talking about the global connectivity state, we care mostly about the (best) default route. So, we should not allow a device with worse or now default route, to contribute its connectivity state. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39
2018-12-03 11:09:39 +01:00
} else {
best_state = NM_MAX_WITH_CMP (nm_connectivity_state_cmp,
best_state,
state);
}
if (nm_connectivity_state_cmp (best_state, NM_CONNECTIVITY_FULL) >= 0) {
/* it doesn't get better than FULL. We are done. */
break;
connectivity: optmize finding best connectivty state in NMManager::device_connectivity_changed() It doesn't get better than FULL, so we can abort the loop in that case early.
2018-04-11 11:35:14 +02:00
}
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
}
connectivity: consider default route for global connectivity state When we agregate the connectivity state, only devices that have the best default route should be considered. Since we do connectivity checking per-device, the per-device check does not care whether traffic to the internet is really routed via this device. But when talking about the global connectivity state, we care mostly about the (best) default route. So, we should not allow a device with worse or now default route, to contribute its connectivity state. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39
2018-12-03 11:09:39 +01:00
return best_state;
}
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
connectivity: consider default route for global connectivity state When we agregate the connectivity state, only devices that have the best default route should be considered. Since we do connectivity checking per-device, the per-device check does not care whether traffic to the internet is really routed via this device. But when talking about the global connectivity state, we care mostly about the (best) default route. So, we should not allow a device with worse or now default route, to contribute its connectivity state. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39
2018-12-03 11:09:39 +01:00
static void
device_connectivity_changed (NMDevice *device,
GParamSpec *pspec,
NMManager *self)
Update connectivity value on device removal When a device is removed (like when the user unplugs a usb network device) the device object is removed, so it doesn't emit a notify signal for a change in its connectivity and so, device_connectivity_changed is not called. This means that nobody updates the global connectivity value which is potentially wrong if the device was the one providing network connectivity. Since device_connectivity_changed's first two parameters aren't actually used and are there just for the signal to be able to be connected, I moved the code from device_connectivity_changed to a new update_connectivity_value function that just takes a NMManager parameter and also call it from remove_device. [thaller@redhat.com: fix coding style regarding whitespace] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/141 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/101
2019-03-21 11:32:32 +01:00
{
update_connectivity_value (self);
}
static void
update_connectivity_value (NMManager *self)
connectivity: consider default route for global connectivity state When we agregate the connectivity state, only devices that have the best default route should be considered. Since we do connectivity checking per-device, the per-device check does not care whether traffic to the internet is really routed via this device. But when talking about the global connectivity state, we care mostly about the (best) default route. So, we should not allow a device with worse or now default route, to contribute its connectivity state. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39
2018-12-03 11:09:39 +01:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMConnectivityState best_state;
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
connectivity: consider default route for global connectivity state When we agregate the connectivity state, only devices that have the best default route should be considered. Since we do connectivity checking per-device, the per-device check does not care whether traffic to the internet is really routed via this device. But when talking about the global connectivity state, we care mostly about the (best) default route. So, we should not allow a device with worse or now default route, to contribute its connectivity state. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39
2018-12-03 11:09:39 +01:00
best_state = _get_best_connectivity (self, AF_UNSPEC);
if (best_state == priv->connectivity_state)
return;
priv->connectivity_state = best_state;
_LOGD (LOGD_CORE, "connectivity checking indicates %s",
nm_connectivity_state_to_string (priv->connectivity_state));
nm_manager_update_state (self);
_notify (self, PROP_CONNECTIVITY);
nm_dispatcher_call_connectivity (priv->connectivity_state, NULL, NULL, NULL);
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
}
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
static void
core: only assume connections that were managed in a previous run of NetworkManager Before, we would have the concept of assumed connections, which is used for (1) externally configured device that NetworkManager should not touch and (2) connections that NetworkManager should gracefully take over after a restart (seamlessly, non-destructively). The behavior was unclear and mixed. It wasn't clear whether the device is in no-touch mode (1) or gracefully take-over (2). Previous commits already introduce separate activation types EXTERNAL (1) and ASSUME (2). Also, previously, we would for both (1) and (2) try to find a matching connection and use it. That doesn't make sense for either. In the external case (1), we should not pretend that an existing connection is active. Let's always create a new in-memory connection for these cases. Note that this means, external devices now will always generate a connection, instead of pretending an existing one is active. For the assume case (2), we shall not use nm_utils_match_connection() to guess which connection might be active. It can only the one that was active on a previous run of NetworkManager. So, use the information from the state file and try to activate it. If that fails, it is not an assume activation type. Note, that this means we now most of the time don't do ASSUME anymore. Most of the time we do EXTERNAL activation That is because the state information is only available after restart of NetworkManager.
2017-03-08 08:45:11 +01:00
_device_realize_finish (NMManager *self,
NMDevice *device,
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
const NMPlatformLink *plink)
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
{
g_return_if_fail (NM_IS_MANAGER (self));
g_return_if_fail (NM_IS_DEVICE (device));
nm_device_realize_finish (device, plink);
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
if (!nm_device_get_managed (device, FALSE)) {
nm_device_assume_state_reset (device);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
return;
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
}
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
if (recheck_assume_connection (self, device))
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
return;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
/* if we failed to assume a connection for the managed device, but the device
* is still unavailable. Set UNAVAILABLE state again, this time with NOW_MANAGED. */
nm_device_state_changed (device,
NM_DEVICE_STATE_UNAVAILABLE,
NM_DEVICE_STATE_REASON_NOW_MANAGED);
nm_device_emit_recheck_auto_activate (device);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
}
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
/**
* add_device:
* @self: the #NMManager
* @device: the #NMDevice to add
manager: improve the add_device() error handling a bit Let it indicate that it didn't succeed adding a device to the global list and bail out.
2015-12-08 14:51:56 +01:00
* @error: (out): the #GError
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
*
* If successful, this function will increase the references count of @device.
* Callers should decrease the reference count.
*/
manager: improve the add_device() error handling a bit Let it indicate that it didn't succeed adding a device to the global list and bail out.
2015-12-08 14:51:56 +01:00
static gboolean
add_device (NMManager *self, NMDevice *device, GError **error)
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
{
2008-04-29 Dan Williams <dcbw@redhat.com> Handle HAL dropouts better; allow NM to start up even if HAL isn't up yet. * marshallers/nm-marshal.list - Add marshaller * src/NetworkManager.c - (main): let the NMManager handle the NMHalManager * src/nm-hal-manager.c src/nm-hal-manager.h - convert to a GObject, and emit singals when stuff changes. Let the NMManager handle the signals, instead of the NMHalManager calling into the NMManager. * src/nm-manager.c src/nm-manager.h - (remove_one_device): consolidate device removals here - (dispose): use remove_one_device() - (nm_manager_get_device_by_udi): make static - (deferred_hal_manager_query_devices): idle handler to query the HAL manager for devices at startup or wakeup time - (nm_manager_new): create and monitor the HAL manager - (hal_manager_udi_added_cb): new function; do what nm_manager_add_device() used to do when signalled by the hal manager - (hal_manager_udi_removed_cb): new function; do what nm_manager_remove_device() used to do when signalled by the hal manager - (hal_manager_rfkill_changed_cb): handle rfkill changes from the hal manager - (hal_manager_hal_reappeared_cb): when HAL comes back, remove devices in our device list that aren't known to HAL - (impl_manager_sleep): on wakeup, re-add devices from an idle handler; see comments on nm-hal-manager.c::nm_manager_state_changed() a few commits ago - (nm_manager_get_device_by_path, nm_manager_is_udi_managed, nm_manager_activation_pending, nm_manager_wireless_enabled, nm_manager_wireless_hardware_enabled, nm_manager_set_wireless_hardware_enabled): remove, unused git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3619 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 23:03:00 +00:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
const char *iface, *type_desc;
core: clean up per-device rfkill handling Add an accessor for device rfkill type and use that instead of GObject properties, and also use that accessor when claiming a new device instead of checking NM_IS_DEVICE_xxxx(). Allows us to move one step closer to making WiMAX a plugin.
2011-11-18 12:02:58 -06:00
RfKillType rtype;
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
GSList *iter, *remove = NULL;
core: check duplicate devices by interface name not UDI We can't have devices with duplicate interface names so we might as well use that for dupe checking instead of the (mostly useless) UDI.
2014-09-24 14:57:14 -05:00
int ifindex;
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
const char *dbus_path;
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *candidate;
core: ensure that modem-manager claimed data devices are ignored add function nm_modem_manager_has_modem_for_iface to modem-manager api and ignore device additions in nm-manager if the iface is claimed by modem-manager; also forget about already managed devices once they get claimed by modem-manager.
2009-09-04 16:55:48 +02:00
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
/* No duplicates */
core: check duplicate devices by interface name not UDI We can't have devices with duplicate interface names so we might as well use that for dupe checking instead of the (mostly useless) UDI.
2014-09-24 14:57:14 -05:00
ifindex = nm_device_get_ifindex (device);
manager: improve the add_device() error handling a bit Let it indicate that it didn't succeed adding a device to the global list and bail out.
2015-12-08 14:51:56 +01:00
if (ifindex > 0 && nm_manager_get_device_by_ifindex (self, ifindex)) {
g_set_error (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_FAILED,
manager: fix typo in error message Fixes: 1762d58a8cf7fbd21b6940fb2a15c136952a9603
2016-02-16 16:21:52 +01:00
"A device with ifindex %d already exists", ifindex);
manager: improve the add_device() error handling a bit Let it indicate that it didn't succeed adding a device to the global list and bail out.
2015-12-08 14:51:56 +01:00
return FALSE;
}
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
/* Remove existing devices owned by the new device; eg remove ethernet
* ports that are owned by a WWAN modem, since udev may announce them
* before the modem is fully discovered.
*
* FIXME: use parent/child device relationships instead of removing
* the child NMDevice entirely
*/
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (candidate, &priv->devices_lst_head, devices_lst) {
if ( nm_device_is_real (candidate)
&& (iface = nm_device_get_ip_iface (candidate))
&& nm_device_owns_iface (device, iface))
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
remove = g_slist_prepend (remove, candidate);
core: ensure that modem-manager claimed data devices are ignored add function nm_modem_manager_has_modem_for_iface to modem-manager api and ignore device additions in nm-manager if the iface is claimed by modem-manager; also forget about already managed devices once they get claimed by modem-manager.
2009-09-04 16:55:48 +02:00
}
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
for (iter = remove; iter; iter = iter->next)
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
remove_device (self, NM_DEVICE (iter->data), FALSE);
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
g_slist_free (remove);
core: ensure that modem-manager claimed data devices are ignored add function nm_modem_manager_has_modem_for_iface to modem-manager api and ignore device additions in nm-manager if the iface is claimed by modem-manager; also forget about already managed devices once they get claimed by modem-manager.
2009-09-04 16:55:48 +02:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
g_object_ref (device);
nm_assert (c_list_is_empty (&device->devices_lst));
c_list_link_tail (&priv->devices_lst_head, &device->devices_lst);
manager: fix use-after-free crash for cdc-ether modems An ethernet device that's actually a component of a modem could get added to the device list, but then destroyed without getting removed from the device list.
2009-10-04 23:36:06 -07:00
core: use define for NMDevice's "state-changed" signal name
2015-12-07 19:42:59 +01:00
g_signal_connect (device, NM_DEVICE_STATE_CHANGED,
trivial: fix whitespace and spelling error Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-10 11:13:55 +01:00
G_CALLBACK (manager_device_state_changed),
self);
2007-03-02 Tambet Ingo <tambet@ximian.com> * libnm-glib/nm-device-802-11-wireless.c: Cache networks (bssids) list. We get signalled when it changes. * libnm-glib/nm-client.c: Cache NMState and device list, we get signalled when it changes. * libnm-glib/nm-device.c: Cache the device state property. * libnm-glib/nm-access-point.c: Cache the strength property. * src/nm-device-802-11-wireless.c: Fix wireless device scanning scheduler. The new algorithm is to start from SCAN_INTERVAL_MIN (currently defined as 0) and add a SCAN_INTERVAL_STEP (currently 20 seconds) with each successful scan until SCAN_INTERVAL_MAX (currently 120 seconds) is reached. Do not scan while the device is down, activating, or activated (in case of A/B/G cards). Remove some old dead ifdef'ed out code that used to configure wireless devices, it's all done through supplicant now. * src/supplicant-manager/nm-supplicant-interface.c: Fix the reference counting issues with pending calls which caused leaks and crashes when interface was removed (now that the interface actually gets removed). * src/nm-call-store.c: Make a copy of data before running a foreach with user callback on it - The most common usage pattern is to cancel (and thus remove) all pending calls with foreach which would modify the hash table we're iterating over. * src/nm-manager.c: When a device is added, make sure it is "up". When it's removed or disabled due to disabling wireless or networking, bring it down. * include/NetworkManager.h: Add new device state NM_DEVICE_STATE_DOWN. * src/nm-device-802-11-wireless.c: * src/nm-device-802-3-ethernet.c: * src/nm-device.c: - Remove "init" virtual function, all gobjects have a place for that already (constructor). - Replace "start" virtual function with "bring_up", devices can be brought up and down more than just on startup now. - Add "is_up" virtual function. - Implement one way to bring a device down instead of previous 4 different ways, each of witch did something different. * src/NetworkManagerUtils.c (nm_dev_sock_open): This doesn't need an NMDevice, all it needs is the device interface. Get rid of NMData.dev_list (3 members to go). Get rif of NMData in a lot of places. * gnome/libnm_glib/libnm_glib.c: Make it compile again. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2395 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-03-02 09:30:48 +00:00
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
g_signal_connect (device, NM_DEVICE_AUTH_REQUEST,
G_CALLBACK (device_auth_request_cb),
self);
core: allow devices to indicate when they should be removed Devices created by plugins will use this to indicate when their backing resources have disappeared, at which point the manager should remove them.
2014-02-10 08:49:47 -06:00
g_signal_connect (device, NM_DEVICE_REMOVED,
G_CALLBACK (device_removed_cb),
self);
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
g_signal_connect_data (device, NM_DEVICE_RECHECK_ASSUME,
G_CALLBACK (recheck_assume_connection_cb),
self, NULL, G_CONNECT_SWAPPED);
core: subscribe recheck_assume_connection() early when adding device 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.
2015-12-04 17:17:47 +01:00
core: remove child devices when a parent's ip_iface becomes known Child devices shouldn't be exposed as real NMDevices (yet) since the configuration and life cycle is controlled by the parent. We already do this if the ip_iface is known when the child device is added, but PPP and other transient interfaces often show up just before we know the parent's ip_iface.
2014-06-12 13:27:14 -05:00
g_signal_connect (device, "notify::" NM_DEVICE_IP_IFACE,
G_CALLBACK (device_ip_iface_changed),
self);
manager: retry virtual connections when a device is added or changes 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 d8e1590c5058 ("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
2016-01-07 17:54:38 +01:00
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
g_signal_connect (device, "notify::" NM_DEVICE_IFINDEX,
G_CALLBACK (device_ifindex_changed),
self);
manager: retry virtual connections when a device is added or changes 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 d8e1590c5058 ("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
2016-01-07 17:54:38 +01:00
g_signal_connect (device, "notify::" NM_DEVICE_IFACE,
G_CALLBACK (device_iface_changed),
self);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
g_signal_connect (device, "notify::" NM_DEVICE_REAL,
G_CALLBACK (device_realized),
self);
core: remove child devices when a parent's ip_iface becomes known Child devices shouldn't be exposed as real NMDevices (yet) since the configuration and life cycle is controlled by the parent. We already do this if the ip_iface is known when the child device is added, but PPP and other transient interfaces often show up just before we know the parent's ip_iface.
2014-06-12 13:27:14 -05:00
device: expose connectivity check result on a device Separate properties for IPv4 and IPv6.
2018-07-03 19:09:34 +02:00
g_signal_connect (device, "notify::" NM_DEVICE_IP4_CONNECTIVITY,
G_CALLBACK (device_connectivity_changed),
self);
g_signal_connect (device, "notify::" NM_DEVICE_IP6_CONNECTIVITY,
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
G_CALLBACK (device_connectivity_changed),
self);
core: add NMManager:startup property Add a property on NMManager indicating that it is currently starting up and activating startup-time/boot-time network connections. "startup" is initially TRUE, and becomes FALSE once all NMDevices report that they have no pending activity (eg, trying to activate, waiting for a wifi scan to complete, etc). This is tracked via a new NMDevice:has-pending-activity property, which is maintained partially by the device itself, and partially by other parts of the code.
2013-08-13 17:45:34 -04:00
if (priv->startup) {
g_signal_connect (device, "notify::" NM_DEVICE_HAS_PENDING_ACTION,
G_CALLBACK (device_has_pending_action_changed),
self);
}
core: clean up per-device rfkill handling Add an accessor for device rfkill type and use that instead of GObject properties, and also use that accessor when claiming a new device instead of checking NM_IS_DEVICE_xxxx(). Allows us to move one step closer to making WiMAX a plugin.
2011-11-18 12:02:58 -06:00
/* Update global rfkill state for this device type with the device's
* rfkill state, and then set this device's rfkill state based on the
* global state.
*/
rtype = nm_device_get_rfkill_type (device);
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
if (rtype != RFKILL_TYPE_UNKNOWN) {
nm_manager_rfkill_update (self, rtype);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
nm_device_set_enabled (device, radio_enabled_for_type (self, rtype, TRUE));
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
}
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
iface = nm_device_get_iface (device);
g_assert (iface);
core: add a 'type-desc' property to NMDeviceInterface and use it instead of littering the code with NM_IS_*.
2009-07-07 14:24:12 -04:00
type_desc = nm_device_get_type_desc (device);
g_assert (type_desc);
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
nm_device_set_unmanaged_by_user_settings (device);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_flags (device,
NM_UNMANAGED_SLEEPING,
manager_sleeping (self));
core: convert unmanaged bits to flags Instead of tracking unmanaged-ness in a couple variables (and because I'd like to add one for user-unmanaged later) let's do it in a single flags variable, and consolidate setting of the unmanaged states in one place.
2014-03-31 21:45:54 -05:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
dbus_path = nm_dbus_object_export (NM_DBUS_OBJECT (device));
manager: add logging macro _NMLOG2() for logging device messages It unifies the way how we print the logging prefix, but also it passes the ifname down for structured logging.
2017-06-07 12:46:10 +02:00
_LOG2I (LOGD_DEVICE, device, "new %s device (%s)", type_desc, dbus_path);
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
settings: rename NMSysconfigSettings to NMSettings
2010-10-27 20:05:23 -05:00
nm_settings_device_added (priv->settings, device);
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
g_signal_emit (self, signals[INTERNAL_DEVICE_ADDED], 0, device);
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
_notify (self, PROP_ALL_DEVICES);
core: implement connection assumption Mark activation requests that contain connections to be assumed, and use that to short-circuit various parts of the activation process by not touching various device attributes, since they are already set up. Also ensure the device is not deactivated when it initially becomes managed, because that would kill the connection we are about to assume.
2009-08-05 18:03:09 -04:00
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
_parent_notify_changed (self, device, FALSE);
manager: improve the add_device() error handling a bit Let it indicate that it didn't succeed adding a device to the global list and bail out.
2015-12-08 14:51:56 +01:00
return TRUE;
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
static void
factory_device_added_cb (NMDeviceFactory *factory,
NMDevice *device,
gpointer user_data)
{
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
NMManager *self = user_data;
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
GError *error = NULL;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
g_return_if_fail (NM_IS_MANAGER (self));
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
if (nm_device_realize_start (device,
NULL,
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
FALSE, /* assume_state_guess_assume */
NULL, /* assume_state_connection_uuid */
FALSE, /* set_nm_owned */
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
NM_UNMAN_FLAG_OP_FORGET,
NULL,
&error)) {
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
add_device (self, device, NULL);
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
_device_realize_finish (self, device, NULL);
manager: try other connections only after the device is realized After a device is created in system_create_virtual_device(), the manager tries to activate connections that depend on the device even if the device isn't realized, as in the following log: # team0 gets created <info> manager: (team0): new Team device (/org/freedesktop/NetworkManager/Devices/7) # team0.23 gets created <debug> device[0x28079b0] (team0.23): constructed (NMDeviceVlan) <debug> manager: (team0-vlan23) create virtual device team0.23 <debug> device[0x28079b0] (team0.23): unmanaged: flags set to [platform-init,!sleeping=0x10/0x11/unmanaged/unrealized], set-managed [sleeping <info> manager: (team0.23): new VLAN device (/org/freedesktop/NetworkManager/Devices/8) # the manager tries to realize team0.23 <debug> device[0x28079b0] (team0.23): create (is nm-owned) <warn> manager: (team0-vlan23) couldn't create the device: cannot retrieve ifindex of interface team0 (Team): skip VLAN creation for now <debug> manager: (team0.23): removing device (allow_unmanage 1, managed 0) <debug> device[0x28079b0] (team0.23): ip4-config: update (commit=0, new-config=(nil)) <debug> device[0x28079b0] (team0.23): ip6-config: update (commit=0, new-config=(nil)) <debug> device[0x28079b0] (team0.23): disposing <debug> device[0x28079b0] (team0.23): ip4-config: update (commit=1, new-config=(nil)) <debug> device[0x28079b0] (team0.23): ip6-config: update (commit=1, new-config=(nil)) <debug> device[0x28079b0] (team0.23): finalize(): NMDeviceVlan # the manager realizes team0 <debug> device[0x2800870] (team0): create (is nm-owned) <debug> platform: link: add link 'team0' of type 'team' (196610) Change the order of operations and try the child connection only after the parent has been realized.
2017-09-13 18:38:59 +02:00
retry_connections_for_parent_device (self, device);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
} else {
manager: add logging macro _NMLOG2() for logging device messages It unifies the way how we print the logging prefix, but also it passes the ifname down for structured logging.
2017-06-07 12:46:10 +02:00
_LOG2W (LOGD_DEVICE, device, "failed to realize device: %s", error->message);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
g_error_free (error);
}
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
}
core: move device creation into the manager Consolidate device creation in the manager object; bluetooth and modem devices were already handled by it, so it makes sense to do it all from one place. Furthermore we'll be creating virtual devices in the manager too. It also reduces indirection (no need to send device_creator() in the DEVICE_ADDED signal) and makes the code flow clearer.
2012-02-05 23:18:32 -06:00
core: let device plugins advertise supported link and setting types Instead of looping over all plugins and asking each plugin whether it can handle a link or a connection, have them advertise the link and connection types they support, and use that when creating new devices.
2014-09-17 14:17:30 -05:00
static void
_register_device_factory (NMDeviceFactory *factory, gpointer user_data)
core: split out device factory registration function We'll soon use it for both shared-library-based plugins, and internal device factories.
2014-09-05 15:05:40 -05:00
{
core: let device plugins advertise supported link and setting types Instead of looping over all plugins and asking each plugin whether it can handle a link or a connection, have them advertise the link and connection types they support, and use that when creating new devices.
2014-09-17 14:17:30 -05:00
NMManager *self = NM_MANAGER (user_data);
core: split out device factory registration function We'll soon use it for both shared-library-based plugins, and internal device factories.
2014-09-05 15:05:40 -05:00
g_signal_connect (factory,
NM_DEVICE_FACTORY_DEVICE_ADDED,
G_CALLBACK (factory_device_added_cb),
self);
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data This is a complete refactoring of the bluetooth code. Now that BlueZ 4 support was dropped, the separation of NMBluezManager and NMBluez5Manager makes no sense. They should be merged. At that point, notice that BlueZ 5's D-Bus API is fully centered around D-Bus's ObjectManager interface. Using that interface, we basically only call GetManagedObjects() once and register to InterfacesAdded, InterfacesRemoved and PropertiesChanged signals. There is no need to fetch individual properties ever. Note how NMBluezDevice used to query the D-Bus properties itself by creating a GDBusProxy. This is redundant, because when using the ObjectManager interfaces, we have all information already. Instead, let NMBluezManager basically become the client-side cache of all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned about caching the D-Bus interface's state, tracking suitable profiles (pan_connection), and moderate between bluez and NMDeviceBt. These tasks don't get simpler by moving them to a seprate file. Let them also be handled by NMBluezManager. I mean, just look how it was previously: NMBluez5Manager registers to ObjectManager interface and sees a device appearing. It creates a NMBluezDevice object and registers to its "initialized" and "notify:usable" signal. In the meantime, NMBluezDevice fetches the relevant information from D-Bus (although it was already present in the data provided by the ObjectManager) and eventually emits these usable and initialized signals. Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and NMBluezDevice are strongly cooperating to the point that it is simpler to merge them. This is not mere refactoring. This patch aims to make everything asynchronously and always cancellable. Also, it aims to fix races and inconsistencies of the state. - Registering to a NAP server now waits for the response and delays activation of the NMDeviceBridge accordingly. - For NAP connections we now watch the bnep0 interface in platform, and tear down the device when it goes away. Bluez doesn't send us a notification on D-Bus in that case. - Rework establishing a DUN connection. It no longer uses blocking connect() and does not block until rfcomm device appears. It's all async now. It also watches the rfcomm file descriptor for POLLERR/POLLHUP to notice disconnect. - drop nm_device_factory_emit_component_added() and instead let NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
}
/*****************************************************************************/
void
nm_manager_notify_device_availibility_maybe_changed (NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMDevice *device;
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst)
nm_device_notify_availability_maybe_changed (device);
core: move device creation into the manager Consolidate device creation in the manager object; bluetooth and modem devices were already handled by it, so it makes sense to do it all from one place. Furthermore we'll be creating virtual devices in the manager too. It also reduces indirection (no need to send device_creator() in the DEVICE_ADDED signal) and makes the code flow clearer.
2012-02-05 23:18:32 -06:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: add support for internal device factories
2014-09-05 15:57:40 -05:00
Use ModemManager.
2009-01-19 11:01:00 +02:00
static void
platform: refactor signals by combining added/changed/removed Before platform raised 3 signals for each object type. Combine them into one and add a new parameter @change_type to distinguish between the change type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-07 19:04:38 +01:00
platform_link_added (NMManager *self,
int ifindex,
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
const NMPlatformLink *plink,
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
gboolean guess_assume,
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
const NMConfigDeviceStateData *dev_state)
Use ModemManager.
2009-01-19 11:01:00 +02:00
{
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: let device plugins advertise supported link and setting types Instead of looping over all plugins and asking each plugin whether it can handle a link or a connection, have them advertise the link and connection types they support, and use that when creating new devices.
2014-09-17 14:17:30 -05:00
NMDeviceFactory *factory;
core: trivial device creation cleanup We really need an NMDevice here, so just call it that instead of GObject.
2012-02-10 12:21:10 -06:00
NMDevice *device = NULL;
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *candidate;
Use ModemManager.
2009-01-19 11:01:00 +02:00
core: split NMAtmManager out of NMUdevManager Split the "atm"-subsystem-monitoring parts of NMUdevManager into a separate class. Now NMUdevManager only handles "net"-subsystem device enumeration.
2013-05-24 17:30:31 -03:00
g_return_if_fail (ifindex > 0);
core: remove some redundant code and add some argument checks ifindex is already passed to the function, no need to look it up again.
2012-03-06 11:38:03 -06:00
trivial: spacing and code cleanups in nm-manager.h Remove some dead code and a redundant function.
2014-09-05 13:15:44 -05:00
if (nm_manager_get_device_by_ifindex (self, ifindex))
core: split NMAtmManager out of NMUdevManager Split the "atm"-subsystem-monitoring parts of NMUdevManager into a separate class. Now NMUdevManager only handles "net"-subsystem device enumeration.
2013-05-24 17:30:31 -03:00
return;
Use ModemManager.
2009-01-19 11:01:00 +02:00
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
/* Let unrealized devices try to realize themselves with the link */
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (candidate, &priv->devices_lst_head, devices_lst) {
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
gboolean compatible = TRUE;
manager: refactor error variable in platform_link_added() Free the error via gs_free_error and create separate instances.
2016-04-04 19:42:04 +02:00
gs_free_error GError *error = NULL;
core: ensure platform links are compatible with the NMDevice 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.
2014-10-09 12:42:29 -05:00
manager: don't assign a new link to a device of a different link type
2017-10-10 11:14:05 +02:00
if (nm_device_get_link_type (candidate) != plink->type)
continue;
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
if (strcmp (nm_device_get_iface (candidate), plink->name))
continue;
core: ensure platform links are compatible with the NMDevice 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.
2014-10-09 12:42:29 -05:00
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
if (nm_device_is_real (candidate)) {
manager: don't update ifindex of existing devices When NM has to rebuild the platform cache, it first generates ADD and then REMOVE events for the links. So, if an interface is removed and readded, platform will emit the ADDED event with a new ifindex while the device with old ifindex still exists. In such case the manager currently updates the device's ifindex but this causes problems as the DNS manager tracks configurations by their ifindex and so the configurations for the old device will become stale. Fix this by removing the device and adding it again when we detect a change of ifindex on a device that already had valid one. https://bugzilla.redhat.com/show_bug.cgi?id=1542366
2018-08-02 17:45:09 +02:00
/* There's already a realized device with the link's name
* and a different ifindex.
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
*/
manager: don't update ifindex of existing devices When NM has to rebuild the platform cache, it first generates ADD and then REMOVE events for the links. So, if an interface is removed and readded, platform will emit the ADDED event with a new ifindex while the device with old ifindex still exists. In such case the manager currently updates the device's ifindex but this causes problems as the DNS manager tracks configurations by their ifindex and so the configurations for the old device will become stale. Fix this by removing the device and adding it again when we detect a change of ifindex on a device that already had valid one. https://bugzilla.redhat.com/show_bug.cgi?id=1542366
2018-08-02 17:45:09 +02:00
if (nm_device_get_ifindex (candidate) <= 0)
nm_device_update_from_platform_link (candidate, plink);
else {
/* The ifindex of a device can't be changed after
* initialization because it is used as a key by
* the dns-manager.
*/
_LOGD (LOGD_DEVICE, "(%s): removing old device %p after ifindex change from %d to %d",
plink->name, candidate, nm_device_get_ifindex (candidate), ifindex);
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
remove_device (self, candidate, FALSE);
manager: don't update ifindex of existing devices When NM has to rebuild the platform cache, it first generates ADD and then REMOVE events for the links. So, if an interface is removed and readded, platform will emit the ADDED event with a new ifindex while the device with old ifindex still exists. In such case the manager currently updates the device's ifindex but this causes problems as the DNS manager tracks configurations by their ifindex and so the configurations for the old device will become stale. Fix this by removing the device and adding it again when we detect a change of ifindex on a device that already had valid one. https://bugzilla.redhat.com/show_bug.cgi?id=1542366
2018-08-02 17:45:09 +02:00
goto add;
}
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
return;
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
} else if (nm_device_realize_start (candidate,
plink,
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
FALSE, /* assume_state_guess_assume */
NULL, /* assume_state_connection_uuid */
FALSE, /* set_nm_owned */
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
NM_UNMAN_FLAG_OP_FORGET,
&compatible,
&error)) {
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
_device_realize_finish (self, candidate, plink);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
return;
}
core: ensure platform links are compatible with the NMDevice 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.
2014-10-09 12:42:29 -05:00
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGD (LOGD_DEVICE, "(%s): failed to realize from plink: '%s'",
plink->name, error->message);
core: ensure platform links are compatible with the NMDevice 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.
2014-10-09 12:42:29 -05:00
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
/* Try next unrealized device */
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
}
manager: don't update ifindex of existing devices When NM has to rebuild the platform cache, it first generates ADD and then REMOVE events for the links. So, if an interface is removed and readded, platform will emit the ADDED event with a new ifindex while the device with old ifindex still exists. In such case the manager currently updates the device's ifindex but this causes problems as the DNS manager tracks configurations by their ifindex and so the configurations for the old device will become stale. Fix this by removing the device and adding it again when we detect a change of ifindex on a device that already had valid one. https://bugzilla.redhat.com/show_bug.cgi?id=1542366
2018-08-02 17:45:09 +02:00
add:
core: let device plugins advertise supported link and setting types Instead of looping over all plugins and asking each plugin whether it can handle a link or a connection, have them advertise the link and connection types they support, and use that when creating new devices.
2014-09-17 14:17:30 -05:00
/* Try registered device factories */
factory = nm_device_factory_manager_find_factory_for_link_type (plink->type);
if (factory) {
core: let plugins indicate links which should be ignored Instead of hacky stuff in the Manager, let plugins themselves indicate which links should be ignored (because they are really child links that are controlled by a different device that the plugin handles).
2015-05-06 09:53:44 -05:00
gboolean ignore = FALSE;
manager: refactor error variable in platform_link_added() Free the error via gs_free_error and create separate instances.
2016-04-04 19:42:04 +02:00
gs_free_error GError *error = NULL;
core: let plugins indicate links which should be ignored Instead of hacky stuff in the Manager, let plugins themselves indicate which links should be ignored (because they are really child links that are controlled by a different device that the plugin handles).
2015-05-06 09:53:44 -05:00
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device = nm_device_factory_create_device (factory, plink->name, plink, NULL, &ignore, &error);
core: let device plugins advertise supported link and setting types Instead of looping over all plugins and asking each plugin whether it can handle a link or a connection, have them advertise the link and connection types they support, and use that when creating new devices.
2014-09-17 14:17:30 -05:00
if (!device) {
core: let plugins indicate links which should be ignored Instead of hacky stuff in the Manager, let plugins themselves indicate which links should be ignored (because they are really child links that are controlled by a different device that the plugin handles).
2015-05-06 09:53:44 -05:00
if (!ignore) {
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGW (LOGD_PLATFORM, "%s: factory failed to create device: %s",
manager: use logging helpers
2016-03-02 11:38:26 +01:00
plink->name, error->message);
device: minor logging change in platform_link_added() Show ignored devices in debug level.
2016-04-12 10:19:21 +02:00
} else {
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGD (LOGD_PLATFORM, "%s: factory failed to create device: %s",
device: minor logging change in platform_link_added() Show ignored devices in debug level.
2016-04-12 10:19:21 +02:00
plink->name, error->message);
core: let plugins indicate links which should be ignored Instead of hacky stuff in the Manager, let plugins themselves indicate which links should be ignored (because they are really child links that are controlled by a different device that the plugin handles).
2015-05-06 09:53:44 -05:00
}
core: move device creation into the manager Consolidate device creation in the manager object; bluetooth and modem devices were already handled by it, so it makes sense to do it all from one place. Furthermore we'll be creating virtual devices in the manager too. It also reduces indirection (no need to send device_creator() in the DEVICE_ADDED signal) and makes the code flow clearer.
2012-02-05 23:18:32 -06:00
return;
}
}
if (device == NULL) {
device: initialize nm_plugin_missing via constructor property No need for the setter/getter of this property. Immutable properties are so much nicer. Remove the setter and ensure that the nm_plugin_missing property is only set during object construction.
2016-09-26 13:26:15 +02:00
gboolean nm_plugin_missing = FALSE;
core: fix compiler warnings -Werror=shadow by trivial renaming of variables https://bugzilla.gnome.org/show_bug.cgi?id=710497 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-10-22 17:11:24 +02:00
switch (plink->type) {
platform/trivial: rename NM_LINK_TYPE_WWAN_ETHERNET to NM_LINK_TYPE_WWAN_NET Some newer WWAN netdev types are "rawip" which don't bother with ethernet framing.
2016-06-14 11:19:15 -05:00
case NM_LINK_TYPE_WWAN_NET:
core: let plugins indicate links which should be ignored Instead of hacky stuff in the Manager, let plugins themselves indicate which links should be ignored (because they are really child links that are controlled by a different device that the plugin handles).
2015-05-06 09:53:44 -05:00
case NM_LINK_TYPE_BNEP:
core: log when creating Generic device when a plugin is missing Log when a plugin is missing for link types that should have plugins.
2014-05-09 10:30:04 -05:00
case NM_LINK_TYPE_OLPC_MESH:
core: log when creating team device as generic due to missing plugin Previous commit 38a83e15a2f741a4a038ce5c55f1ad41b59f69a1 moves the team device to a plugin. If the plugin is not available, we should log an information that we create a generic device instead. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-27 17:02:23 +02:00
case NM_LINK_TYPE_TEAM:
core: log when creating Generic device when a plugin is missing Log when a plugin is missing for link types that should have plugins.
2014-05-09 10:30:04 -05:00
case NM_LINK_TYPE_WIFI:
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGI (LOGD_PLATFORM, "(%s): '%s' plugin not available; creating generic device",
manager: use logging helpers
2016-03-02 11:38:26 +01:00
plink->name, nm_link_type_to_string (plink->type));
core: set nm-plugin-missing device property
2015-04-14 14:43:31 +02:00
nm_plugin_missing = TRUE;
core: log when creating Generic device when a plugin is missing Log when a plugin is missing for link types that should have plugins.
2014-05-09 10:30:04 -05:00
/* fall through */
core: use NMPlatform to figure out device types, where possible 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
2013-04-25 15:46:39 -04:00
default:
device: initialize nm_plugin_missing via constructor property No need for the setter/getter of this property. Immutable properties are so much nicer. Remove the setter and ensure that the nm_plugin_missing property is only set during object construction.
2016-09-26 13:26:15 +02:00
device = nm_device_generic_new (plink, nm_plugin_missing);
core: use NMPlatform to figure out device types, where possible 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
2013-04-25 15:46:39 -04:00
break;
core, libnm-glib: add NMDeviceGeneric 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.
2013-04-17 10:41:15 -04:00
}
core: move device creation into the manager Consolidate device creation in the manager object; bluetooth and modem devices were already handled by it, so it makes sense to do it all from one place. Furthermore we'll be creating virtual devices in the manager too. It also reduces indirection (no need to send device_creator() in the DEVICE_ADDED signal) and makes the code flow clearer.
2012-02-05 23:18:32 -06:00
}
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
if (device) {
manager: refactor error variable in platform_link_added() Free the error via gs_free_error and create separate instances.
2016-04-04 19:42:04 +02:00
gs_free_error GError *error = NULL;
device: set user-explicit unmanaged flag based on loaded device-state On restart, the device state may be stored in /var/run. Reuse it to set the managed flag.
2016-09-26 14:51:23 +02:00
NMUnmanFlagOp unmanaged_user_explicit = NM_UNMAN_FLAG_OP_FORGET;
if (dev_state) {
switch (dev_state->managed) {
case NM_CONFIG_DEVICE_STATE_MANAGED_TYPE_MANAGED:
unmanaged_user_explicit = NM_UNMAN_FLAG_OP_SET_MANAGED;
break;
case NM_CONFIG_DEVICE_STATE_MANAGED_TYPE_UNMANAGED:
unmanaged_user_explicit = NM_UNMAN_FLAG_OP_SET_UNMANAGED;
break;
case NM_CONFIG_DEVICE_STATE_MANAGED_TYPE_UNKNOWN:
break;
}
}
manager: refactor error variable in platform_link_added() Free the error via gs_free_error and create separate instances.
2016-04-04 19:42:04 +02:00
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
if (nm_device_realize_start (device,
plink,
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
guess_assume,
dev_state ? dev_state->connection_uuid : NULL,
device: only set nm-owned from statefile during initial setup The state file should only be read initially when NM starts, that is: during NMManager's platform_query_devices(). At all later points, for example when a software device gets destroyed and re-realized, the state file is clearly no longer relevant. Hence, pass the set-nm-owned flag from NMManager to realize_start_setup(). This is very much the same as with the NM_UNMANAGED_FLAG_USER_EXPLICT flag, which we also read from the state-file.
2017-06-07 22:11:50 +02:00
dev_state ? (dev_state->nm_owned == 1) : FALSE,
device: set user-explicit unmanaged flag based on loaded device-state On restart, the device state may be stored in /var/run. Reuse it to set the managed flag.
2016-09-26 14:51:23 +02:00
unmanaged_user_explicit,
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
NULL,
&error)) {
manager: improve the add_device() error handling a bit Let it indicate that it didn't succeed adding a device to the global list and bail out.
2015-12-08 14:51:56 +01:00
add_device (self, device, NULL);
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
_device_realize_finish (self, device, plink);
manager: try other connections only after the device is realized After a device is created in system_create_virtual_device(), the manager tries to activate connections that depend on the device even if the device isn't realized, as in the following log: # team0 gets created <info> manager: (team0): new Team device (/org/freedesktop/NetworkManager/Devices/7) # team0.23 gets created <debug> device[0x28079b0] (team0.23): constructed (NMDeviceVlan) <debug> manager: (team0-vlan23) create virtual device team0.23 <debug> device[0x28079b0] (team0.23): unmanaged: flags set to [platform-init,!sleeping=0x10/0x11/unmanaged/unrealized], set-managed [sleeping <info> manager: (team0.23): new VLAN device (/org/freedesktop/NetworkManager/Devices/8) # the manager tries to realize team0.23 <debug> device[0x28079b0] (team0.23): create (is nm-owned) <warn> manager: (team0-vlan23) couldn't create the device: cannot retrieve ifindex of interface team0 (Team): skip VLAN creation for now <debug> manager: (team0.23): removing device (allow_unmanage 1, managed 0) <debug> device[0x28079b0] (team0.23): ip4-config: update (commit=0, new-config=(nil)) <debug> device[0x28079b0] (team0.23): ip6-config: update (commit=0, new-config=(nil)) <debug> device[0x28079b0] (team0.23): disposing <debug> device[0x28079b0] (team0.23): ip4-config: update (commit=1, new-config=(nil)) <debug> device[0x28079b0] (team0.23): ip6-config: update (commit=1, new-config=(nil)) <debug> device[0x28079b0] (team0.23): finalize(): NMDeviceVlan # the manager realizes team0 <debug> device[0x2800870] (team0): create (is nm-owned) <debug> platform: link: add link 'team0' of type 'team' (196610) Change the order of operations and try the child connection only after the parent has been realized.
2017-09-13 18:38:59 +02:00
retry_connections_for_parent_device (self, device);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
} else {
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGW (LOGD_DEVICE, "%s: failed to realize device: %s",
plink->name, error->message);
manager: call nm_device_realize() also for generic devices 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: e8139f56c26ae3bcc5e14abdb29970ae07e93299
2015-08-25 16:10:40 +02:00
}
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
g_object_unref (device);
}
Use ModemManager.
2009-01-19 11:01:00 +02:00
}
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
typedef struct {
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
CList lst;
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
NMManager *self;
int ifindex;
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
guint idle_id;
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
} PlatformLinkCbData;
static gboolean
_platform_link_cb_idle (PlatformLinkCbData *data)
{
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
int ifindex = data->ifindex;
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
NMManager *self = data->self;
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: keep platform link object alive and don't copy it Sometimes, when we have a platform object, we need to keep it alive, because any subsequent platform operation might invalidate the object. Previously, we achieved that by copying the NMPlatformLink data. For a while now, all platform object are immuable and recounted. We should not copy the instance to a NMPlatformLink object, because then the instance is no longer a full NMPObject. Instead, just take an additional reference. Since the object must be immutable, that is just as safe. But now callees down the stack get a proper NMPObject instance, and might reference it too.
2017-09-29 16:58:24 +02:00
const NMPlatformLink *plink;
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
c-list: re-import latest version of c-list.h from upstream Most notably, it renames c_list_unlink_init() -> c_list_unlink() c_list_unlink() -> c_list_unlink_stale() $ sed -e 's/\<c_list_unlink\>/c_list_unlink_old/g' \ -e 's/\<c_list_unlink_init\>/c_list_unlink/g' \ -e 's/\<c_list_unlink_old\>/c_list_unlink_stale/g' \ $(git grep -l c_list_unlink -- ':(exclude)shared/nm-utils/c-list.h') \ -i
2017-11-28 11:22:01 +01:00
c_list_unlink_stale (&data->lst);
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
g_slice_free (PlatformLinkCbData, data);
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
core: keep platform link object alive and don't copy it Sometimes, when we have a platform object, we need to keep it alive, because any subsequent platform operation might invalidate the object. Previously, we achieved that by copying the NMPlatformLink data. For a while now, all platform object are immuable and recounted. We should not copy the instance to a NMPlatformLink object, because then the instance is no longer a full NMPObject. Instead, just take an additional reference. Since the object must be immutable, that is just as safe. But now callees down the stack get a proper NMPObject instance, and might reference it too.
2017-09-29 16:58:24 +02:00
plink = nm_platform_link_get (priv->platform, ifindex);
if (plink) {
core: avoid compiler warnings related to cleanup attribute gcc doesn't consider variables with cleanup attribute as unused. clang does, and warns about them. In one case, clang is right, in the other one the warning is bogus. Fix both.
2017-10-05 14:42:02 +02:00
const NMPObject *plink_keep_alive = nmp_object_ref (NMP_OBJECT_UP_CAST (plink));
manager: fix clearing weak-ref in platform_link_added() We must always clear the weak-ref. Fixes: 4dbaac4ba24ebc8b257fffe5197cc8e362804a58
2015-12-04 14:11:00 +01:00
core: keep platform link object alive and don't copy it Sometimes, when we have a platform object, we need to keep it alive, because any subsequent platform operation might invalidate the object. Previously, we achieved that by copying the NMPlatformLink data. For a while now, all platform object are immuable and recounted. We should not copy the instance to a NMPlatformLink object, because then the instance is no longer a full NMPObject. Instead, just take an additional reference. Since the object must be immutable, that is just as safe. But now callees down the stack get a proper NMPObject instance, and might reference it too.
2017-09-29 16:58:24 +02:00
platform_link_added (self, ifindex, plink, FALSE, NULL);
core: avoid compiler warnings related to cleanup attribute gcc doesn't consider variables with cleanup attribute as unused. clang does, and warns about them. In one case, clang is right, in the other one the warning is bogus. Fix both.
2017-10-05 14:42:02 +02:00
nmp_object_unref (plink_keep_alive);
manager: fix clearing weak-ref in platform_link_added() We must always clear the weak-ref. Fixes: 4dbaac4ba24ebc8b257fffe5197cc8e362804a58
2015-12-04 14:11:00 +01:00
} else {
NMDevice *device;
GError *error = NULL;
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
device = nm_manager_get_device_by_ifindex (self, ifindex);
manager: fix clearing weak-ref in platform_link_added() We must always clear the weak-ref. Fixes: 4dbaac4ba24ebc8b257fffe5197cc8e362804a58
2015-12-04 14:11:00 +01:00
if (device) {
core: always unrealize software devices when platform link disappears 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: 7e5f27a21ca22d986755e4cc480e85d8a51ff17d
2016-01-14 17:24:25 +01:00
if (nm_device_is_software (device)) {
manager: set interface as removed when the link disappears Set the device state as removed when the link disappears, so that in the call to unrealize() when the device is unmanaged we also perform a cleanup of it and especially, we terminate any DHCP client instances running on the device. If we keep DHCP clients running, we can hit assertions later when we start another instance on the same interface, because we kill the old dhclient from the pidfile, and the g_child_watch_add() done by the first client instance is not able to waitpid() it, complaining with: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). Most likely the process is ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive first argument; either behavior can break applications that use g_child_watch_add()/g_spawn_sync() either directly or indirectly. https://bugzilla.redhat.com/show_bug.cgi?id=1436602 (cherry picked from commit df537d2eac44cffe4512214c87f3f303c5a350d3)
2017-04-13 18:28:08 +02:00
nm_device_sys_iface_state_set (device, NM_DEVICE_SYS_IFACE_STATE_REMOVED);
manager: let external devices go on removal If we didn't create them, we shouldn't keep them around unrealized.
2015-12-09 15:41:39 +01:00
/* Our software devices stick around until their connection is removed */
manager: fix clearing weak-ref in platform_link_added() We must always clear the weak-ref. Fixes: 4dbaac4ba24ebc8b257fffe5197cc8e362804a58
2015-12-04 14:11:00 +01:00
if (!nm_device_unrealize (device, FALSE, &error)) {
manager: add logging macro _NMLOG2() for logging device messages It unifies the way how we print the logging prefix, but also it passes the ifname down for structured logging.
2017-06-07 12:46:10 +02:00
_LOG2W (LOGD_DEVICE, device, "failed to unrealize: %s", error->message);
manager: fix clearing weak-ref in platform_link_added() We must always clear the weak-ref. Fixes: 4dbaac4ba24ebc8b257fffe5197cc8e362804a58
2015-12-04 14:11:00 +01:00
g_clear_error (&error);
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
remove_device (self, device, FALSE);
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
} else {
nm_device_update_from_platform_link (device, NULL);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
}
manager: fix clearing weak-ref in platform_link_added() We must always clear the weak-ref. Fixes: 4dbaac4ba24ebc8b257fffe5197cc8e362804a58
2015-12-04 14:11:00 +01:00
} else {
manager: let external devices go on removal If we didn't create them, we shouldn't keep them around unrealized.
2015-12-09 15:41:39 +01:00
/* Hardware and external devices always get removed when their kernel link is gone */
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
remove_device (self, device, FALSE);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
}
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
}
}
manager: fix clearing weak-ref in platform_link_added() We must always clear the weak-ref. Fixes: 4dbaac4ba24ebc8b257fffe5197cc8e362804a58
2015-12-04 14:11:00 +01:00
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
return G_SOURCE_REMOVE;
}
2008-04-29 Dan Williams <dcbw@redhat.com> Handle HAL dropouts better; allow NM to start up even if HAL isn't up yet. * marshallers/nm-marshal.list - Add marshaller * src/NetworkManager.c - (main): let the NMManager handle the NMHalManager * src/nm-hal-manager.c src/nm-hal-manager.h - convert to a GObject, and emit singals when stuff changes. Let the NMManager handle the signals, instead of the NMHalManager calling into the NMManager. * src/nm-manager.c src/nm-manager.h - (remove_one_device): consolidate device removals here - (dispose): use remove_one_device() - (nm_manager_get_device_by_udi): make static - (deferred_hal_manager_query_devices): idle handler to query the HAL manager for devices at startup or wakeup time - (nm_manager_new): create and monitor the HAL manager - (hal_manager_udi_added_cb): new function; do what nm_manager_add_device() used to do when signalled by the hal manager - (hal_manager_udi_removed_cb): new function; do what nm_manager_remove_device() used to do when signalled by the hal manager - (hal_manager_rfkill_changed_cb): handle rfkill changes from the hal manager - (hal_manager_hal_reappeared_cb): when HAL comes back, remove devices in our device list that aren't known to HAL - (impl_manager_sleep): on wakeup, re-add devices from an idle handler; see comments on nm-hal-manager.c::nm_manager_state_changed() a few commits ago - (nm_manager_get_device_by_path, nm_manager_is_udi_managed, nm_manager_activation_pending, nm_manager_wireless_enabled, nm_manager_wireless_hardware_enabled, nm_manager_set_wireless_hardware_enabled): remove, unused git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3619 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 23:03:00 +00:00
static void
platform: refactor signals by combining added/changed/removed Before platform raised 3 signals for each object type. Combine them into one and add a new parameter @change_type to distinguish between the change type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-07 19:04:38 +01:00
platform_link_cb (NMPlatform *platform,
core: don't use generated glib enum for platform types
2016-10-22 13:08:36 +02:00
int obj_type_i,
platform: refactor signals by combining added/changed/removed Before platform raised 3 signals for each object type. Combine them into one and add a new parameter @change_type to distinguish between the change type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-07 19:04:38 +01:00
int ifindex,
NMPlatformLink *plink,
core: don't use generated glib enum for platform types
2016-10-22 13:08:36 +02:00
int change_type_i,
platform: refactor signals by combining added/changed/removed Before platform raised 3 signals for each object type. Combine them into one and add a new parameter @change_type to distinguish between the change type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-07 19:04:38 +01:00
gpointer user_data)
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
{
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
NMManager *self;
NMManagerPrivate *priv;
core: don't use generated glib enum for platform types
2016-10-22 13:08:36 +02:00
const NMPlatformSignalChangeType change_type = change_type_i;
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
PlatformLinkCbData *data;
platform: refactor signals by combining added/changed/removed Before platform raised 3 signals for each object type. Combine them into one and add a new parameter @change_type to distinguish between the change type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-07 19:04:38 +01:00
switch (change_type) {
case NM_PLATFORM_SIGNAL_ADDED:
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
case NM_PLATFORM_SIGNAL_REMOVED:
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
self = NM_MANAGER (user_data);
priv = NM_MANAGER_GET_PRIVATE (self);
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
data = g_slice_new (PlatformLinkCbData);
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
data->self = self;
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
data->ifindex = ifindex;
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
c_list_link_tail (&priv->link_cb_lst, &data->lst);
data->idle_id = g_idle_add ((GSourceFunc) _platform_link_cb_idle, data);
platform: refactor signals by combining added/changed/removed Before platform raised 3 signals for each object type. Combine them into one and add a new parameter @change_type to distinguish between the change type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-07 19:04:38 +01:00
break;
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
default:
platform: refactor signals by combining added/changed/removed Before platform raised 3 signals for each object type. Combine them into one and add a new parameter @change_type to distinguish between the change type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-07 19:04:38 +01:00
break;
core: delay handling of link-changed platform event in manager Backtrace: NetworkManager[10972]: <debug> [1435142179.593334] [platform/nm-platform.c:2962] log_ip4_route(): signal: route 4 removed: 0.0.0.0/0 via 192.168.100.1 dev 85 metric 300 mss 0 src user scope global NetworkManager[10972]: <debug> [1435142179.593421] [platform/nm-platform.c:2944] log_link(): signal: link removed: 85: bond0 <DOWN;broadcast,multicast,master> mtu 1500 arp 1 bond* init addr 7A:AB:BE:0D:19:3D driver bond NetworkManager[10972]: <debug> [1435142179.593446] [nm-manager.c:779] remove_device(): (bond0): removing device (allow_unmanage 1, managed 1) NetworkManager[10972]: <debug> [1435142179.596995] [devices/nm-device.c:7232] nm_device_set_unmanaged(): [0x5555559d2a40] (bond0): now unmanaged NetworkManager[10972]: (devices/nm-device.c:8040):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE) #0 0x00007ffff4a538c3 in g_logv () at /lib64/libglib-2.0.so.0 #1 0x00007ffff4a53a3f in g_log () at /lib64/libglib-2.0.so.0 #2 0x00007ffff4a53d56 in g_warn_message () at /lib64/libglib-2.0.so.0 #3 0x00005555555b9dca in _set_state_full (self=0x5555559d2a40, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:8040 #4 0x0000555555626d7b in remove_device (manager=0x5555559631e0, device=0x5555559d2a40, quitting=0, allow_unmanage=<optimized out>) at nm-manager.c:801 #5 0x00007ffff28b7dac in ffi_call_unix64 () at /lib64/libffi.so.6 #6 0x00007ffff28b76d5 in ffi_call () at /lib64/libffi.so.6 #7 0x00007ffff4d4a628 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0 #8 0x00007ffff4d49de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff4d5b70d in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #10 0x00007ffff4d63471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #11 0x00007ffff4d63c78 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #12 0x00005555555ce4ea in do_emit_signal (platform=platform@entry=0x55555594c8b0, obj=0x555555a74c50, cache_op=NMP_CACHE_OPS_REMOVED, was_visible=<optimized out>, reason=reason@entry= NM_PLATFORM_REASON_INTERNAL) at platform/nm-linux-platform.c:1425 #13 0x00005555555ce826 in cache_prune_candidates_prune (platform=platform@entry=0x55555594c8b0) at platform/nm-linux-platform.c:1704 #14 0x00005555555d32d3 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=85, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=0) at platform/nm-linux-platform.c:1951 #15 0x00005555555d356b in delayed_action_handle_all (ifindex=85, platform=0x55555594c8b0) at platform/nm-linux-platform.c:1491 #16 0x00005555555d356b in delayed_action_handle_all (platform=0x55555594c8b0) at platform/nm-linux-platform.c:1573 #17 0x00005555555d356b in delayed_action_handle_all (platform=platform@entry=0x55555594c8b0, read_netlink=read_netlink@entry=0) at platform/nm-linux-platform.c:1588 #18 0x00005555555d32e2 in do_request_link (platform=platform@entry=0x55555594c8b0, ifindex=ifindex@entry=7, name=name@entry=0x0, handle_delayed_action=handle_delayed_action@entry=1) at platform/nm-linux-platform.c:1954 #19 0x00005555555d5177 in do_change_link (platform=platform@entry=0x55555594c8b0, nlo=nlo@entry=0x55555597f0f0, complete_from_cache=complete_from_cache@entry=1) at platform/nm-linux-platform.c:2753 #20 0x00005555555d56b4 in link_enslave (platform=0x55555594c8b0, master=0, slave=7) at platform/nm-linux-platform.c:3141 #21 0x00005555555976de in release_slave (device=0x5555559d2a40, slave=0x5555559c6be0, configure=<optimized out>) at devices/nm-device-bond.c:437 #22 0x00005555555b7bc3 in nm_device_release_one_slave (self=self@entry=0x5555559d2a40, slave=0x5555559c6be0, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:1049 #23 0x00005555555b7f0e in nm_device_master_release_slaves (self=self@entry=0x5555559d2a40) at devices/nm-device.c:1781 #24 0x00005555555b9592 in nm_device_cleanup (self=0x5555559d2a40, reason=<optimized out>, deconfigure=1) at devices/nm-device.c:7752 #25 0x00005555555ba161 in _set_state_full (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:8128 #26 0x00005555555bb297 in nm_device_state_changed (self=self@entry=0x5555559d2a40, state=state@entry=NM_DEVICE_STATE_DISCONNECTED, reason=reason@entry=NM_DEVICE_STATE_REASON_CONNECTION_REMOVED) at devices/nm-device.c:8319 #27 0x00005555555bd9a5 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8343 #28 0x00007ffff4a4c79a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #29 0x00007ffff4a4cae8 in g_main_context_iterate.isra.24 () at /lib64/libglib-2.0.so.0 #30 0x00007ffff4a4cdba in g_main_loop_run () at /lib64/libglib-2.0.so.0 #31 0x000055555559556f in main (argc=1, argv=0x7fffffffdb88) at main.c:518
2015-06-24 13:42:16 +02:00
}
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
}
platform: move nm_platform_query_devices() to nm-manager nm_platform_query_devices() would raise an 'added' signal for all its links. That is bad style because it could confuse other listeners for platform signals which don't expect such artificial change signals. The public API of NMPlatform already gives NMManager the ability to 'pull' all the links and iterate them itself. Before, nm_platform_query_devices() would also initialize udev devices, so there was a more compelling reason for this function.
2015-05-04 16:54:51 +02:00
static void
platform_query_devices (NMManager *self)
{
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
platform: refactor nm_platform_link_get_all() to return GPtrArray Instead of doing a full clone, return a pointer array (with references owned). The NMPlatformLink instances are now immutable.
2017-07-04 22:29:27 +02:00
gs_unref_ptrarray GPtrArray *links = NULL;
platform: move nm_platform_query_devices() to nm-manager nm_platform_query_devices() would raise an 'added' signal for all its links. That is bad style because it could confuse other listeners for platform signals which don't expect such artificial change signals. The public API of NMPlatform already gives NMManager the ability to 'pull' all the links and iterate them itself. Before, nm_platform_query_devices() would also initialize udev devices, so there was a more compelling reason for this function.
2015-05-04 16:54:51 +02:00
int i;
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
gboolean guess_assume;
config: remove nm_config_data_get_value_cached() It has almost no callers, and it is a bit of a strange API. Let's not cache the last accessed value inside NMConfigData. Instead, free it right after use. It was not reused anyway, it only hangs around as convenience for the caller.
2017-10-24 08:35:42 +02:00
gs_free char *order = NULL;
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
guess_assume = nm_config_get_first_start (nm_config_get ());
config: remove nm_config_data_get_value_cached() It has almost no callers, and it is a bit of a strange API. Let's not cache the last accessed value inside NMConfigData. Instead, free it right after use. It was not reused anyway, it only hangs around as convenience for the caller.
2017-10-24 08:35:42 +02:00
order = nm_config_data_get_value (NM_CONFIG_GET_DATA,
NM_CONFIG_KEYFILE_GROUP_MAIN,
NM_CONFIG_KEYFILE_KEY_MAIN_SLAVES_ORDER,
NM_CONFIG_GET_VALUE_STRIP);
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
links = nm_platform_link_get_all (priv->platform, !nm_streq0 (order, "index"));
platform: refactor nm_platform_link_get_all() to return GPtrArray Instead of doing a full clone, return a pointer array (with references owned). The NMPlatformLink instances are now immutable.
2017-07-04 22:29:27 +02:00
if (!links)
return;
for (i = 0; i < links->len; i++) {
platform: refactor NMPObject cast macros using _Generic() This way, we also accept void pointers, while preserving constness.
2017-07-05 11:12:59 +02:00
const NMPlatformLink *link = NMP_OBJECT_CAST_LINK (links->pdata[i]);
core: cache device state in NMConfig and load all at once NMManager will need to know the state of all device at once. Hence, load it once and cache it in NMConfig. Note that this wastes a bit of memory in the order of O(number-of-interfaces). But each device state entry is rather small, and we always consume memory in the order of O(number-of-interfaces).
2017-12-06 13:09:31 +01:00
const NMConfigDeviceStateData *dev_state;
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
core: cache device state in NMConfig and load all at once NMManager will need to know the state of all device at once. Hence, load it once and cache it in NMConfig. Note that this wastes a bit of memory in the order of O(number-of-interfaces). But each device state entry is rather small, and we always consume memory in the order of O(number-of-interfaces).
2017-12-06 13:09:31 +01:00
dev_state = nm_config_device_state_get (priv->config, link->ifindex);
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
platform_link_added (self,
platform: refactor nm_platform_link_get_all() to return GPtrArray Instead of doing a full clone, return a pointer array (with references owned). The NMPlatformLink instances are now immutable.
2017-07-04 22:29:27 +02:00
link->ifindex,
link,
device: assume matching connections during first start Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
2017-04-19 16:16:12 +02:00
guess_assume && (!dev_state || !dev_state->connection_uuid),
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
dev_state);
}
platform: move nm_platform_query_devices() to nm-manager nm_platform_query_devices() would raise an 'added' signal for all its links. That is bad style because it could confuse other listeners for platform signals which don't expect such artificial change signals. The public API of NMPlatform already gives NMManager the ability to 'pull' all the links and iterate them itself. Before, nm_platform_query_devices() would also initialize udev devices, so there was a more compelling reason for this function.
2015-05-04 16:54:51 +02:00
}
2008-04-29 Dan Williams <dcbw@redhat.com> Handle HAL dropouts better; allow NM to start up even if HAL isn't up yet. * marshallers/nm-marshal.list - Add marshaller * src/NetworkManager.c - (main): let the NMManager handle the NMHalManager * src/nm-hal-manager.c src/nm-hal-manager.h - convert to a GObject, and emit singals when stuff changes. Let the NMManager handle the signals, instead of the NMHalManager calling into the NMManager. * src/nm-manager.c src/nm-manager.h - (remove_one_device): consolidate device removals here - (dispose): use remove_one_device() - (nm_manager_get_device_by_udi): make static - (deferred_hal_manager_query_devices): idle handler to query the HAL manager for devices at startup or wakeup time - (nm_manager_new): create and monitor the HAL manager - (hal_manager_udi_added_cb): new function; do what nm_manager_add_device() used to do when signalled by the hal manager - (hal_manager_udi_removed_cb): new function; do what nm_manager_remove_device() used to do when signalled by the hal manager - (hal_manager_rfkill_changed_cb): handle rfkill changes from the hal manager - (hal_manager_hal_reappeared_cb): when HAL comes back, remove devices in our device list that aren't known to HAL - (impl_manager_sleep): on wakeup, re-add devices from an idle handler; see comments on nm-hal-manager.c::nm_manager_state_changed() a few commits ago - (nm_manager_get_device_by_path, nm_manager_is_udi_managed, nm_manager_activation_pending, nm_manager_wireless_enabled, nm_manager_wireless_hardware_enabled, nm_manager_set_wireless_hardware_enabled): remove, unused git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3619 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 23:03:00 +00:00
static void
core: split NMRfkillManager out of NMUdevManager Split the rfkill-monitoring parts of NMUdevManager into a separate class. Now NMUdevManager only handles device enumeration.
2013-05-09 10:24:08 -04:00
rfkill_manager_rfkill_changed_cb (NMRfkillManager *rfkill_mgr,
RfKillType rtype,
RfKillState udev_state,
gpointer user_data)
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
{
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
nm_manager_rfkill_update (NM_MANAGER (user_data), rtype);
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
}
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
const CList *
2008-04-29 Dan Williams <dcbw@redhat.com> Handle HAL dropouts better; allow NM to start up even if HAL isn't up yet. * marshallers/nm-marshal.list - Add marshaller * src/NetworkManager.c - (main): let the NMManager handle the NMHalManager * src/nm-hal-manager.c src/nm-hal-manager.h - convert to a GObject, and emit singals when stuff changes. Let the NMManager handle the signals, instead of the NMHalManager calling into the NMManager. * src/nm-manager.c src/nm-manager.h - (remove_one_device): consolidate device removals here - (dispose): use remove_one_device() - (nm_manager_get_device_by_udi): make static - (deferred_hal_manager_query_devices): idle handler to query the HAL manager for devices at startup or wakeup time - (nm_manager_new): create and monitor the HAL manager - (hal_manager_udi_added_cb): new function; do what nm_manager_add_device() used to do when signalled by the hal manager - (hal_manager_udi_removed_cb): new function; do what nm_manager_remove_device() used to do when signalled by the hal manager - (hal_manager_rfkill_changed_cb): handle rfkill changes from the hal manager - (hal_manager_hal_reappeared_cb): when HAL comes back, remove devices in our device list that aren't known to HAL - (impl_manager_sleep): on wakeup, re-add devices from an idle handler; see comments on nm-hal-manager.c::nm_manager_state_changed() a few commits ago - (nm_manager_get_device_by_path, nm_manager_is_udi_managed, nm_manager_activation_pending, nm_manager_wireless_enabled, nm_manager_wireless_hardware_enabled, nm_manager_set_wireless_hardware_enabled): remove, unused git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3619 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 23:03:00 +00:00
nm_manager_get_devices (NMManager *manager)
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
{
g_return_val_if_fail (NM_IS_MANAGER (manager), NULL);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
return &NM_MANAGER_GET_PRIVATE (manager)->devices_lst_head;
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
}
core: improve selection of device when activating profile on any device With $ nmcli connection up "$PROFILE" ifname "$DEVICE" it's clear that the user means the particular device. That also is taken as a indication to make $DEVICE as managed, in case it was unmanaged before. So, this command implies a previous $ nmcli device set $DEVICE managed yes On the other hand, if the user just issues $ nmcli connection up "$PROFILE" without a particular device, then we should prefer devices which are marked as managed instead of unmanaged once. Likewise, we should consider the device's state when selecting a device. This means, when activating a profile which is activatable on multiple devices, it will now prefer devices which are not already active. The exception to this is that if the profile itself is already active (and multi-connect "single"), then it will prefer to re-activate the profile on the same device. This was done previously already. What's new is that if the the profile is not multi-connect "single", the said exception no longer applies, and we prefer to activate the profile on a hitherto unactivated device. https://bugzilla.redhat.com/show_bug.cgi?id=1639254 https://github.com/NetworkManager/NetworkManager/pull/232
2018-10-15 15:23:22 +02:00
typedef enum {
DEVICE_ACTIVATION_PRIO_NONE,
DEVICE_ACTIVATION_PRIO_UNMANAGED,
DEVICE_ACTIVATION_PRIO_UNAVAILABLE,
DEVICE_ACTIVATION_PRIO_DEACTIVATING,
DEVICE_ACTIVATION_PRIO_ACTIVATING,
DEVICE_ACTIVATION_PRIO_ACTIVATED,
DEVICE_ACTIVATION_PRIO_DISCONNECTED,
_DEVICE_ACTIVATION_PRIO_BEST = DEVICE_ACTIVATION_PRIO_DISCONNECTED,
} DeviceActivationPrio;
static DeviceActivationPrio
_device_get_activation_prio (NMDevice *device)
{
if (!nm_device_get_managed (device, TRUE))
return DEVICE_ACTIVATION_PRIO_NONE;
switch (nm_device_get_state (device)) {
case NM_DEVICE_STATE_DISCONNECTED:
return DEVICE_ACTIVATION_PRIO_DISCONNECTED;
case NM_DEVICE_STATE_ACTIVATED:
return DEVICE_ACTIVATION_PRIO_ACTIVATED;
case NM_DEVICE_STATE_PREPARE:
case NM_DEVICE_STATE_CONFIG:
case NM_DEVICE_STATE_NEED_AUTH:
case NM_DEVICE_STATE_IP_CONFIG:
case NM_DEVICE_STATE_IP_CHECK:
case NM_DEVICE_STATE_SECONDARIES:
return DEVICE_ACTIVATION_PRIO_ACTIVATING;
case NM_DEVICE_STATE_DEACTIVATING:
case NM_DEVICE_STATE_FAILED:
return DEVICE_ACTIVATION_PRIO_DEACTIVATING;
case NM_DEVICE_STATE_UNAVAILABLE:
return DEVICE_ACTIVATION_PRIO_UNAVAILABLE;
case NM_DEVICE_STATE_UNKNOWN:
case NM_DEVICE_STATE_UNMANAGED:
return DEVICE_ACTIVATION_PRIO_UNMANAGED;
}
g_return_val_if_reached (DEVICE_ACTIVATION_PRIO_UNAVAILABLE);
}
manager: pick an available device if none was specified upon connection activation This offloads some complexity from the client. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
static NMDevice *
nm_manager_get_best_device_for_connection (NMManager *self,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
manager: fix activation without specified device 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: 0bfe635119facb8514e8f5824f599f4c4c3514e2
2015-10-19 14:14:17 +02:00
NMConnection *connection,
manager: change nm_manager_get_best_device_for_connection() signature Add a @unavailable_devices argument that specifies an hash table of devices to be excluded from the search.
2017-02-24 09:08:02 +01:00
gboolean for_user_request,
core: return error reason from nm_manager_get_best_device_for_connection() Still unused, but will be used to give a better failure reason when no device is found. The difficulty here is to select the failure message from the most appropriate device. This might still need some tweaking by setting the error codes accordingly and re-ordering checks so that failure cares that are more accurate are handled first.
2018-07-10 11:50:21 +02:00
GHashTable *unavailable_devices,
GError **error)
manager: pick an available device if none was specified upon connection activation This offloads some complexity from the client. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
{
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
manager: search all existing active connections during nm_manager_get_best_device_for_connection() In nm_manager_get_best_device_for_connection(), not only check whether the first found active-connection has a device. There might be multiple candidates, in which case iterate over them and figure out which one is the most suitable. Also, despite the found @ac has the same settings-connection, it does not mean that the connection is available on the device. Extend the check and only return compatible and ready devices. This can easily happen that the settings-connection was modified in the meantime and no longer is compatible with the device (despite currently being active on the device, but with the previous settings).
2018-04-22 15:21:52 +02:00
NMActiveConnectionState ac_state;
manager: cleanup find_ac_for_connection() in "nm-manager.c" - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
2017-03-13 14:01:47 +01:00
NMActiveConnection *ac;
manager: search all existing active connections during nm_manager_get_best_device_for_connection() In nm_manager_get_best_device_for_connection(), not only check whether the first found active-connection has a device. There might be multiple candidates, in which case iterate over them and figure out which one is the most suitable. Also, despite the found @ac has the same settings-connection, it does not mean that the connection is available on the device. Extend the check and only return compatible and ready devices. This can easily happen that the settings-connection was modified in the meantime and no longer is compatible with the device (despite currently being active on the device, but with the previous settings).
2018-04-22 15:21:52 +02:00
NMDevice *ac_device;
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *device;
core: improve selection of device when activating profile on any device With $ nmcli connection up "$PROFILE" ifname "$DEVICE" it's clear that the user means the particular device. That also is taken as a indication to make $DEVICE as managed, in case it was unmanaged before. So, this command implies a previous $ nmcli device set $DEVICE managed yes On the other hand, if the user just issues $ nmcli connection up "$PROFILE" without a particular device, then we should prefer devices which are marked as managed instead of unmanaged once. Likewise, we should consider the device's state when selecting a device. This means, when activating a profile which is activatable on multiple devices, it will now prefer devices which are not already active. The exception to this is that if the profile itself is already active (and multi-connect "single"), then it will prefer to re-activate the profile on the same device. This was done previously already. What's new is that if the the profile is not multi-connect "single", the said exception no longer applies, and we prefer to activate the profile on a hitherto unactivated device. https://bugzilla.redhat.com/show_bug.cgi?id=1639254 https://github.com/NetworkManager/NetworkManager/pull/232
2018-10-15 15:23:22 +02:00
struct {
NMDevice *device;
DeviceActivationPrio prio;
} best = {
.device = NULL,
.prio = DEVICE_ACTIVATION_PRIO_NONE,
};
manager: fix activation without specified device 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: 0bfe635119facb8514e8f5824f599f4c4c3514e2
2015-10-19 14:14:17 +02:00
NMDeviceCheckConAvailableFlags flags;
manager: search all existing active connections during nm_manager_get_best_device_for_connection() In nm_manager_get_best_device_for_connection(), not only check whether the first found active-connection has a device. There might be multiple candidates, in which case iterate over them and figure out which one is the most suitable. Also, despite the found @ac has the same settings-connection, it does not mean that the connection is available on the device. Extend the check and only return compatible and ready devices. This can easily happen that the settings-connection was modified in the meantime and no longer is compatible with the device (despite currently being active on the device, but with the previous settings).
2018-04-22 15:21:52 +02:00
gs_unref_ptrarray GPtrArray *all_ac_arr = NULL;
core: return error reason from nm_manager_get_best_device_for_connection() Still unused, but will be used to give a better failure reason when no device is found. The difficulty here is to select the failure message from the most appropriate device. This might still need some tweaking by setting the error codes accordingly and re-ordering checks so that failure cares that are more accurate are handled first.
2018-07-10 11:50:21 +02:00
gs_free_error GError *local_best = NULL;
core: fix checking multi-connect flag in nm_manager_get_best_device_for_connection() We should not check @sett_conn, but @connection. Fixes: 09719bc479b63c8e5fef3950e980b263aca7eff5
2018-10-17 12:21:33 +02:00
NMConnectionMultiConnect multi_connect;
manager: pick an available device if none was specified upon connection activation This offloads some complexity from the client. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_assert (!sett_conn || NM_IS_SETTINGS_CONNECTION (sett_conn));
nm_assert (!connection || NM_IS_CONNECTION (connection));
nm_assert (sett_conn || connection);
nm_assert (!connection || !sett_conn || connection == nm_settings_connection_get_connection (sett_conn));
if (!connection)
connection = nm_settings_connection_get_connection (sett_conn);
core: fix checking multi-connect flag in nm_manager_get_best_device_for_connection() We should not check @sett_conn, but @connection. Fixes: 09719bc479b63c8e5fef3950e980b263aca7eff5
2018-10-17 12:21:33 +02:00
multi_connect = _nm_connection_get_multi_connect (connection);
core: ignore unmanaged devices for explicit activation request depending on multi-connect When a device is unmanaged, an explicit activation request can still activate it. In particular, that is the case for $ nmcli connection up "$PROFILE" ifname "$DEVICE" It is also the case, for plain $ nmcli connection up "$PROFILE" where NetworkManager searches for a suitable device -- depending on multi-connect setting of the profile. The idea is, that a profile with "multi-connect=single" is expected to sufficently and uniquely match a device, based on matching properties like "connection.interface-name". In that case, an explicit activation request from the user shows the intent to manage the device. Note that it's hard to understand whether the profile really uniquely selects a particular device. For example, if the profile doesn't specify "connection.interface-name", it might still uniquely identify an ethernet device, if you only have one such device. On the other hand, with "connection.multi-connect" other than "single", it is very much expected that the profile does not strictly match one device. Change the behavior here for multi-connect profiles. This allows the user to block individual devices from activation via $ nmcli device set "$DEVICE" managed not A subsequent $ nmcli connection up "$MULTI_PROFILE" will not consider "$DEVICE" as suitable candidate for activation. Likewise, in the future we may want to add a $ nmcli connection up --all "$MULTI_PROFILE" command, to activate the profile on all suitable device. In that case again, unmanaged devices probably also should be skipped for multi-connect profiles. https://bugzilla.redhat.com/show_bug.cgi?id=1639254
2018-10-17 11:33:02 +02:00
if (!for_user_request)
flags = NM_DEVICE_CHECK_CON_AVAILABLE_NONE;
else {
/* if the profile is multi-connect=single, we also consider devices which
all: fix misspellings https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/64
2019-01-11 17:07:03 -02:00
* are marked as unmanaged. And explicit user-request shows sufficient user
core: ignore unmanaged devices for explicit activation request depending on multi-connect When a device is unmanaged, an explicit activation request can still activate it. In particular, that is the case for $ nmcli connection up "$PROFILE" ifname "$DEVICE" It is also the case, for plain $ nmcli connection up "$PROFILE" where NetworkManager searches for a suitable device -- depending on multi-connect setting of the profile. The idea is, that a profile with "multi-connect=single" is expected to sufficently and uniquely match a device, based on matching properties like "connection.interface-name". In that case, an explicit activation request from the user shows the intent to manage the device. Note that it's hard to understand whether the profile really uniquely selects a particular device. For example, if the profile doesn't specify "connection.interface-name", it might still uniquely identify an ethernet device, if you only have one such device. On the other hand, with "connection.multi-connect" other than "single", it is very much expected that the profile does not strictly match one device. Change the behavior here for multi-connect profiles. This allows the user to block individual devices from activation via $ nmcli device set "$DEVICE" managed not A subsequent $ nmcli connection up "$MULTI_PROFILE" will not consider "$DEVICE" as suitable candidate for activation. Likewise, in the future we may want to add a $ nmcli connection up --all "$MULTI_PROFILE" command, to activate the profile on all suitable device. In that case again, unmanaged devices probably also should be skipped for multi-connect profiles. https://bugzilla.redhat.com/show_bug.cgi?id=1639254
2018-10-17 11:33:02 +02:00
* intent to make the device managed.
* That is also, because we expect that such profile is suitably tied
* to the intended device. So when an unmanaged device matches, the user's
* intent is clear.
*
* For multi-connect != single devices that is different. The profile
* is not restricted to a particular device.
* For that reason, plain `nmcli connection up "$MULIT_PROFILE"` seems
* less suitable for multi-connect profiles, because the target device is
* left unspecified. Anyway, if a user issues
*
* $ nmcli device set "$DEVICE" managed no
* $ nmcli connection up "$MULIT_PROFILE"
*
* then it is reasonable for multi-connect profiles to not consider
* the device a suitable candidate.
*
* This may be seen inconsistent, but I think that it makes a lot of
* sense. Also note that "connection.multi-connect" work quite differently
* in aspects like activation. E.g. `nmcli connection up` of multi-connect
* "single" profile, will deactivate the profile if it is active already.
* That is different from multi-connect profiles, where it will aim to
* activate the profile one more time on an hitherto disconnected device.
*/
if (multi_connect == NM_CONNECTION_MULTI_CONNECT_SINGLE)
flags = NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST;
else
flags = NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST & ~_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_OVERRULE_UNMANAGED;
}
core: fix checking multi-connect flag in nm_manager_get_best_device_for_connection() We should not check @sett_conn, but @connection. Fixes: 09719bc479b63c8e5fef3950e980b263aca7eff5
2018-10-17 12:21:33 +02:00
if ( multi_connect == NM_CONNECTION_MULTI_CONNECT_SINGLE
core: improve selection of device when activating profile on any device With $ nmcli connection up "$PROFILE" ifname "$DEVICE" it's clear that the user means the particular device. That also is taken as a indication to make $DEVICE as managed, in case it was unmanaged before. So, this command implies a previous $ nmcli device set $DEVICE managed yes On the other hand, if the user just issues $ nmcli connection up "$PROFILE" without a particular device, then we should prefer devices which are marked as managed instead of unmanaged once. Likewise, we should consider the device's state when selecting a device. This means, when activating a profile which is activatable on multiple devices, it will now prefer devices which are not already active. The exception to this is that if the profile itself is already active (and multi-connect "single"), then it will prefer to re-activate the profile on the same device. This was done previously already. What's new is that if the the profile is not multi-connect "single", the said exception no longer applies, and we prefer to activate the profile on a hitherto unactivated device. https://bugzilla.redhat.com/show_bug.cgi?id=1639254 https://github.com/NetworkManager/NetworkManager/pull/232
2018-10-15 15:23:22 +02:00
&& (ac = active_connection_find_by_connection (self, sett_conn, connection, NM_ACTIVE_CONNECTION_STATE_DEACTIVATING, &all_ac_arr))) {
/* if we have a profile which may activate on only one device (multi-connect single), then
* we prefer the device on which the profile is already active. It means to reactivate
* the profile on the same device.
*
* If the profile can be activated on multiple devices, we don't do this. In fact, the
* check below for the DeviceActivationPrio will prefer devices which are not already
* activated (with this or another) profile. */
manager: pick an available device if none was specified upon connection activation This offloads some complexity from the client. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
manager: search all existing active connections during nm_manager_get_best_device_for_connection() In nm_manager_get_best_device_for_connection(), not only check whether the first found active-connection has a device. There might be multiple candidates, in which case iterate over them and figure out which one is the most suitable. Also, despite the found @ac has the same settings-connection, it does not mean that the connection is available on the device. Extend the check and only return compatible and ready devices. This can easily happen that the settings-connection was modified in the meantime and no longer is compatible with the device (despite currently being active on the device, but with the previous settings).
2018-04-22 15:21:52 +02:00
ac_device = nm_active_connection_get_device (ac);
if ( ac_device
&& ( (unavailable_devices && g_hash_table_contains (unavailable_devices, ac_device))
core: give better error reason why device is unavailable The error reason is still unused.
2018-06-27 16:21:43 +02:00
|| !nm_device_check_connection_available (ac_device, connection, flags, NULL, NULL)))
manager: search all existing active connections during nm_manager_get_best_device_for_connection() In nm_manager_get_best_device_for_connection(), not only check whether the first found active-connection has a device. There might be multiple candidates, in which case iterate over them and figure out which one is the most suitable. Also, despite the found @ac has the same settings-connection, it does not mean that the connection is available on the device. Extend the check and only return compatible and ready devices. This can easily happen that the settings-connection was modified in the meantime and no longer is compatible with the device (despite currently being active on the device, but with the previous settings).
2018-04-22 15:21:52 +02:00
ac_device = NULL;
if (all_ac_arr) {
guint i;
ac_state = nm_active_connection_get_state (ac);
/* we found several active connections. See which one is the most suitable... */
nm_assert (ac == all_ac_arr->pdata[0]);
for (i = 1; i < all_ac_arr->len; i++) {
NMActiveConnection *ac2 = all_ac_arr->pdata[i];
NMDevice *ac_device2 = nm_active_connection_get_device (ac2);
NMActiveConnectionState ac_state2;
if ( !ac_device2
|| (unavailable_devices && g_hash_table_contains (unavailable_devices, ac_device2))
core: give better error reason why device is unavailable The error reason is still unused.
2018-06-27 16:21:43 +02:00
|| !nm_device_check_connection_available (ac_device2, connection, flags, NULL, NULL))
manager: search all existing active connections during nm_manager_get_best_device_for_connection() In nm_manager_get_best_device_for_connection(), not only check whether the first found active-connection has a device. There might be multiple candidates, in which case iterate over them and figure out which one is the most suitable. Also, despite the found @ac has the same settings-connection, it does not mean that the connection is available on the device. Extend the check and only return compatible and ready devices. This can easily happen that the settings-connection was modified in the meantime and no longer is compatible with the device (despite currently being active on the device, but with the previous settings).
2018-04-22 15:21:52 +02:00
continue;
ac_state2 = nm_active_connection_get_state (ac2);
if (!ac_device)
goto found_better;
if (ac_state == ac_state2) {
/* active-connections are in their list in the order in which they are connected.
* If we have two with same state, the later (newer) one is preferred. */
goto found_better;
}
switch (ac_state) {
case NM_ACTIVE_CONNECTION_STATE_UNKNOWN:
if (NM_IN_SET (ac_state2, NM_ACTIVE_CONNECTION_STATE_ACTIVATING, NM_ACTIVE_CONNECTION_STATE_ACTIVATED, NM_ACTIVE_CONNECTION_STATE_DEACTIVATING))
goto found_better;
break;
case NM_ACTIVE_CONNECTION_STATE_ACTIVATING:
if (NM_IN_SET (ac_state2, NM_ACTIVE_CONNECTION_STATE_ACTIVATED))
goto found_better;
break;
case NM_ACTIVE_CONNECTION_STATE_ACTIVATED:
break;
case NM_ACTIVE_CONNECTION_STATE_DEACTIVATING:
if (NM_IN_SET (ac_state2, NM_ACTIVE_CONNECTION_STATE_ACTIVATING, NM_ACTIVE_CONNECTION_STATE_ACTIVATED))
goto found_better;
break;
default:
nm_assert_not_reached ();
goto found_better;
}
continue;
found_better:
ac = ac2;
ac_state = ac_state2;
ac_device = ac_device2;
}
}
if (ac_device)
return ac_device;
}
manager: fix activation without specified device 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: 0bfe635119facb8514e8f5824f599f4c4c3514e2
2015-10-19 14:14:17 +02:00
manager: pick an available device if none was specified upon connection activation This offloads some complexity from the client. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
/* Pick the first device that's compatible with the connection. */
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
core: return error reason from nm_manager_get_best_device_for_connection() Still unused, but will be used to give a better failure reason when no device is found. The difficulty here is to select the failure message from the most appropriate device. This might still need some tweaking by setting the error codes accordingly and re-ordering checks so that failure cares that are more accurate are handled first.
2018-07-10 11:50:21 +02:00
GError *local = NULL;
core: improve selection of device when activating profile on any device With $ nmcli connection up "$PROFILE" ifname "$DEVICE" it's clear that the user means the particular device. That also is taken as a indication to make $DEVICE as managed, in case it was unmanaged before. So, this command implies a previous $ nmcli device set $DEVICE managed yes On the other hand, if the user just issues $ nmcli connection up "$PROFILE" without a particular device, then we should prefer devices which are marked as managed instead of unmanaged once. Likewise, we should consider the device's state when selecting a device. This means, when activating a profile which is activatable on multiple devices, it will now prefer devices which are not already active. The exception to this is that if the profile itself is already active (and multi-connect "single"), then it will prefer to re-activate the profile on the same device. This was done previously already. What's new is that if the the profile is not multi-connect "single", the said exception no longer applies, and we prefer to activate the profile on a hitherto unactivated device. https://bugzilla.redhat.com/show_bug.cgi?id=1639254 https://github.com/NetworkManager/NetworkManager/pull/232
2018-10-15 15:23:22 +02:00
DeviceActivationPrio prio;
manager: pick an available device if none was specified upon connection activation This offloads some complexity from the client. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
core: return error reason from nm_manager_get_best_device_for_connection() Still unused, but will be used to give a better failure reason when no device is found. The difficulty here is to select the failure message from the most appropriate device. This might still need some tweaking by setting the error codes accordingly and re-ordering checks so that failure cares that are more accurate are handled first.
2018-07-10 11:50:21 +02:00
if ( unavailable_devices
&& g_hash_table_contains (unavailable_devices, device))
manager: change nm_manager_get_best_device_for_connection() signature Add a @unavailable_devices argument that specifies an hash table of devices to be excluded from the search.
2017-02-24 09:08:02 +01:00
continue;
core: improve selection of device when activating profile on any device With $ nmcli connection up "$PROFILE" ifname "$DEVICE" it's clear that the user means the particular device. That also is taken as a indication to make $DEVICE as managed, in case it was unmanaged before. So, this command implies a previous $ nmcli device set $DEVICE managed yes On the other hand, if the user just issues $ nmcli connection up "$PROFILE" without a particular device, then we should prefer devices which are marked as managed instead of unmanaged once. Likewise, we should consider the device's state when selecting a device. This means, when activating a profile which is activatable on multiple devices, it will now prefer devices which are not already active. The exception to this is that if the profile itself is already active (and multi-connect "single"), then it will prefer to re-activate the profile on the same device. This was done previously already. What's new is that if the the profile is not multi-connect "single", the said exception no longer applies, and we prefer to activate the profile on a hitherto unactivated device. https://bugzilla.redhat.com/show_bug.cgi?id=1639254 https://github.com/NetworkManager/NetworkManager/pull/232
2018-10-15 15:23:22 +02:00
/* determine the priority of this device. Currently this priority is independent
* of the profile (connection) and the device's details (aside the state).
core/trivial: add code comment for nm_manager_get_best_device_for_connection()
2018-10-17 12:21:49 +02:00
*
core: improve selection of device when activating profile on any device With $ nmcli connection up "$PROFILE" ifname "$DEVICE" it's clear that the user means the particular device. That also is taken as a indication to make $DEVICE as managed, in case it was unmanaged before. So, this command implies a previous $ nmcli device set $DEVICE managed yes On the other hand, if the user just issues $ nmcli connection up "$PROFILE" without a particular device, then we should prefer devices which are marked as managed instead of unmanaged once. Likewise, we should consider the device's state when selecting a device. This means, when activating a profile which is activatable on multiple devices, it will now prefer devices which are not already active. The exception to this is that if the profile itself is already active (and multi-connect "single"), then it will prefer to re-activate the profile on the same device. This was done previously already. What's new is that if the the profile is not multi-connect "single", the said exception no longer applies, and we prefer to activate the profile on a hitherto unactivated device. https://bugzilla.redhat.com/show_bug.cgi?id=1639254 https://github.com/NetworkManager/NetworkManager/pull/232
2018-10-15 15:23:22 +02:00
* Maybe nm_device_check_connection_available() should instead return a priority,
core/trivial: add code comment for nm_manager_get_best_device_for_connection()
2018-10-17 12:21:49 +02:00
* as it has more information available.
*
* For example, if you have multiple Wi-Fi devices, currently a user-request would
* also select the device if the AP is not visible. Optimally, if one of the two
* devices sees the AP and the other one doesn't, the former would be preferred.
* For that, the priority would need to be determined by nm_device_check_connection_available(). */
core: improve selection of device when activating profile on any device With $ nmcli connection up "$PROFILE" ifname "$DEVICE" it's clear that the user means the particular device. That also is taken as a indication to make $DEVICE as managed, in case it was unmanaged before. So, this command implies a previous $ nmcli device set $DEVICE managed yes On the other hand, if the user just issues $ nmcli connection up "$PROFILE" without a particular device, then we should prefer devices which are marked as managed instead of unmanaged once. Likewise, we should consider the device's state when selecting a device. This means, when activating a profile which is activatable on multiple devices, it will now prefer devices which are not already active. The exception to this is that if the profile itself is already active (and multi-connect "single"), then it will prefer to re-activate the profile on the same device. This was done previously already. What's new is that if the the profile is not multi-connect "single", the said exception no longer applies, and we prefer to activate the profile on a hitherto unactivated device. https://bugzilla.redhat.com/show_bug.cgi?id=1639254 https://github.com/NetworkManager/NetworkManager/pull/232
2018-10-15 15:23:22 +02:00
prio = _device_get_activation_prio (device);
if ( prio <= best.prio
&& best.device) {
/* we already have a matching device with a better priority. This candidate
core/trivial: add code comment for nm_manager_get_best_device_for_connection()
2018-10-17 12:21:49 +02:00
* cannot be better. Skip the check.
*
* Also note, that below we collect the best error message @local_best.
* Since we already have best.device, the error message does not matter
* either, and we can skip nm_device_check_connection_available() altogether. */
core: improve selection of device when activating profile on any device With $ nmcli connection up "$PROFILE" ifname "$DEVICE" it's clear that the user means the particular device. That also is taken as a indication to make $DEVICE as managed, in case it was unmanaged before. So, this command implies a previous $ nmcli device set $DEVICE managed yes On the other hand, if the user just issues $ nmcli connection up "$PROFILE" without a particular device, then we should prefer devices which are marked as managed instead of unmanaged once. Likewise, we should consider the device's state when selecting a device. This means, when activating a profile which is activatable on multiple devices, it will now prefer devices which are not already active. The exception to this is that if the profile itself is already active (and multi-connect "single"), then it will prefer to re-activate the profile on the same device. This was done previously already. What's new is that if the the profile is not multi-connect "single", the said exception no longer applies, and we prefer to activate the profile on a hitherto unactivated device. https://bugzilla.redhat.com/show_bug.cgi?id=1639254 https://github.com/NetworkManager/NetworkManager/pull/232
2018-10-15 15:23:22 +02:00
continue;
}
core: return error reason from nm_manager_get_best_device_for_connection() Still unused, but will be used to give a better failure reason when no device is found. The difficulty here is to select the failure message from the most appropriate device. This might still need some tweaking by setting the error codes accordingly and re-ordering checks so that failure cares that are more accurate are handled first.
2018-07-10 11:50:21 +02:00
if (nm_device_check_connection_available (device,
connection,
flags,
NULL,
core: improve selection of device when activating profile on any device With $ nmcli connection up "$PROFILE" ifname "$DEVICE" it's clear that the user means the particular device. That also is taken as a indication to make $DEVICE as managed, in case it was unmanaged before. So, this command implies a previous $ nmcli device set $DEVICE managed yes On the other hand, if the user just issues $ nmcli connection up "$PROFILE" without a particular device, then we should prefer devices which are marked as managed instead of unmanaged once. Likewise, we should consider the device's state when selecting a device. This means, when activating a profile which is activatable on multiple devices, it will now prefer devices which are not already active. The exception to this is that if the profile itself is already active (and multi-connect "single"), then it will prefer to re-activate the profile on the same device. This was done previously already. What's new is that if the the profile is not multi-connect "single", the said exception no longer applies, and we prefer to activate the profile on a hitherto unactivated device. https://bugzilla.redhat.com/show_bug.cgi?id=1639254 https://github.com/NetworkManager/NetworkManager/pull/232
2018-10-15 15:23:22 +02:00
error ? &local : NULL)) {
if (prio == _DEVICE_ACTIVATION_PRIO_BEST) {
/* this device already has the best priority. It cannot get better
* and finish the search. */
return device;
}
best.prio = prio;
best.device = device;
continue;
}
core: return error reason from nm_manager_get_best_device_for_connection() Still unused, but will be used to give a better failure reason when no device is found. The difficulty here is to select the failure message from the most appropriate device. This might still need some tweaking by setting the error codes accordingly and re-ordering checks so that failure cares that are more accurate are handled first.
2018-07-10 11:50:21 +02:00
if (error) {
gboolean reset_error;
if (!local_best)
reset_error = TRUE;
else if (local_best->domain != NM_UTILS_ERROR)
reset_error = (local->domain == NM_UTILS_ERROR);
else {
reset_error = ( local->domain == NM_UTILS_ERROR
&& local_best->code < local->code);
}
if (reset_error) {
g_clear_error (&local_best);
g_set_error (&local_best,
local->domain,
local->code,
"device %s not available because %s",
nm_device_get_iface (device),
local->message);
}
g_error_free (local);
}
manager: pick an available device if none was specified upon connection activation This offloads some complexity from the client. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
}
core: improve selection of device when activating profile on any device With $ nmcli connection up "$PROFILE" ifname "$DEVICE" it's clear that the user means the particular device. That also is taken as a indication to make $DEVICE as managed, in case it was unmanaged before. So, this command implies a previous $ nmcli device set $DEVICE managed yes On the other hand, if the user just issues $ nmcli connection up "$PROFILE" without a particular device, then we should prefer devices which are marked as managed instead of unmanaged once. Likewise, we should consider the device's state when selecting a device. This means, when activating a profile which is activatable on multiple devices, it will now prefer devices which are not already active. The exception to this is that if the profile itself is already active (and multi-connect "single"), then it will prefer to re-activate the profile on the same device. This was done previously already. What's new is that if the the profile is not multi-connect "single", the said exception no longer applies, and we prefer to activate the profile on a hitherto unactivated device. https://bugzilla.redhat.com/show_bug.cgi?id=1639254 https://github.com/NetworkManager/NetworkManager/pull/232
2018-10-15 15:23:22 +02:00
if (best.device)
return best.device;
core: return error reason from nm_manager_get_best_device_for_connection() Still unused, but will be used to give a better failure reason when no device is found. The difficulty here is to select the failure message from the most appropriate device. This might still need some tweaking by setting the error codes accordingly and re-ordering checks so that failure cares that are more accurate are handled first.
2018-07-10 11:50:21 +02:00
if (error) {
if (local_best)
g_propagate_error (error, g_steal_pointer (&local_best));
else {
nm_utils_error_set_literal (error,
NM_UTILS_ERROR_UNKNOWN,
"no suitable device found");
}
}
manager: pick an available device if none was specified upon connection activation This offloads some complexity from the client. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
return NULL;
}
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
static const char **
_get_devices_paths (NMManager *self,
gboolean all_devices)
2007-08-26 Dan Williams <dcbw@redhat.com> Convert to using interface indexes as the primary method of identifying devices inside NetworkManager. Indexes are (?) stable, but devices can be renamed at any time. Device object paths now refer to the device index rather than the name, and you can map those two manually if you like by looking in the /sys/class/net/<name>/ifindex file. Also moves most netlink-related code to nm-netlink.c, and cleans up nm-netlink-monitor.c to use interface indexes rather than names. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2731 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-08-26 15:55:27 +00:00
{
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
const char **paths = NULL;
core: fix impl_manager_get_devices() to skip non-exported objects Must skip over NULL paths. Also, the previous version leaked the object-paths as g_variant_new() doesn't take ownership. Fixes: 34ba4e14b8674dc74327975159e101710ebd5403
2015-08-18 13:42:20 +02:00
guint i;
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *device;
2007-08-26 Dan Williams <dcbw@redhat.com> Convert to using interface indexes as the primary method of identifying devices inside NetworkManager. Indexes are (?) stable, but devices can be renamed at any time. Device object paths now refer to the device index rather than the name, and you can map those two manually if you like by looking in the /sys/class/net/<name>/ifindex file. Also moves most netlink-related code to nm-netlink.c, and cleans up nm-netlink-monitor.c to use interface indexes rather than names. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2731 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-08-26 15:55:27 +00:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
paths = g_new (const char *, c_list_length (&priv->devices_lst_head) + 1);
core: fix impl_manager_get_devices() to skip non-exported objects Must skip over NULL paths. Also, the previous version leaked the object-paths as g_variant_new() doesn't take ownership. Fixes: 34ba4e14b8674dc74327975159e101710ebd5403
2015-08-18 13:42:20 +02:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
i = 0;
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
core: fix impl_manager_get_devices() to skip non-exported objects Must skip over NULL paths. Also, the previous version leaked the object-paths as g_variant_new() doesn't take ownership. Fixes: 34ba4e14b8674dc74327975159e101710ebd5403
2015-08-18 13:42:20 +02:00
const char *path;
2007-08-26 Dan Williams <dcbw@redhat.com> Convert to using interface indexes as the primary method of identifying devices inside NetworkManager. Indexes are (?) stable, but devices can be renamed at any time. Device object paths now refer to the device index rather than the name, and you can map those two manually if you like by looking in the /sys/class/net/<name>/ifindex file. Also moves most netlink-related code to nm-netlink.c, and cleans up nm-netlink-monitor.c to use interface indexes rather than names. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2731 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-08-26 15:55:27 +00:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
path = nm_dbus_object_get_path (NM_DBUS_OBJECT (device));
if (!path)
continue;
if ( !all_devices
&& !nm_device_is_real (device))
continue;
paths[i++] = path;
core: fix impl_manager_get_devices() to skip non-exported objects Must skip over NULL paths. Also, the previous version leaked the object-paths as g_variant_new() doesn't take ownership. Fixes: 34ba4e14b8674dc74327975159e101710ebd5403
2015-08-18 13:42:20 +02:00
}
paths[i++] = NULL;
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
return paths;
2007-08-26 Dan Williams <dcbw@redhat.com> Convert to using interface indexes as the primary method of identifying devices inside NetworkManager. Indexes are (?) stable, but devices can be renamed at any time. Device object paths now refer to the device index rather than the name, and you can map those two manually if you like by looking in the /sys/class/net/<name>/ifindex file. Also moves most netlink-related code to nm-netlink.c, and cleans up nm-netlink-monitor.c to use interface indexes rather than names. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2731 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-08-26 15:55:27 +00:00
}
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_get_devices (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
{
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMManager *self = NM_MANAGER (obj);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
gs_free const char **paths = NULL;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
paths = _get_devices_paths (self, FALSE);
g_dbus_method_invocation_return_value (invocation,
g_variant_new ("(^ao)", (char **) paths));
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
}
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_get_all_devices (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
{
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMManager *self = NM_MANAGER (obj);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
gs_free const char **paths = NULL;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
paths = _get_devices_paths (self, TRUE);
g_dbus_method_invocation_return_value (invocation,
g_variant_new ("(^ao)", (char **) paths));
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
}
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_get_device_by_ip_iface (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
core: add GetDeviceByIpIface method Allow clients to get a device by its IP interface name instead of having to get the device list and iterate through each one, and read the interface name to get what they want.
2011-04-22 12:27:55 -05:00
NMDevice *device;
const char *path = NULL;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
const char *iface;
g_variant_get (parameters, "(&s)", &iface);
core: add GetDeviceByIpIface method Allow clients to get a device by its IP interface name instead of having to get the device list and iterate through each one, and read the interface name to get what they want.
2011-04-22 12:27:55 -05:00
device = find_device_by_ip_iface (self, iface);
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
if (device)
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
path = nm_dbus_object_get_path (NM_DBUS_OBJECT (device));
core: add GetDeviceByIpIface method Allow clients to get a device by its IP interface name instead of having to get the device list and iterate through each one, and read the interface name to get what they want.
2011-04-22 12:27:55 -05:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
if (!path) {
g_dbus_method_invocation_return_error (invocation,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_UNKNOWN_DEVICE,
"No device found for the requested iface.");
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
return;
core: add GetDeviceByIpIface method Allow clients to get a device by its IP interface name instead of having to get the device list and iterate through each one, and read the interface name to get what they want.
2011-04-22 12:27:55 -05:00
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_return_value (invocation,
g_variant_new ("(o)", path));
core: add GetDeviceByIpIface method Allow clients to get a device by its IP interface name instead of having to get the device list and iterate through each one, and read the interface name to get what they want.
2011-04-22 12:27:55 -05:00
}
core: Tighten up find_master() and ensure_master_active_connection() semantics Return activation errors in a few edge cases rather than doing the wrong thing.
2014-01-29 13:22:53 -05:00
static gboolean
is_compatible_with_slave (NMConnection *master, NMConnection *slave)
{
NMSettingConnection *s_con;
g_return_val_if_fail (master, FALSE);
g_return_val_if_fail (slave, FALSE);
s_con = nm_connection_get_setting_connection (slave);
g_assert (s_con);
return nm_connection_is_type (master, nm_setting_connection_get_slave_type (s_con));
}
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
/**
* find_master:
* @self: #NMManager object
* @connection: the #NMConnection to find the master connection and device for
* @device: the #NMDevice, if any, which will activate @connection
* @out_master_connection: on success, the master connection of @connection if
* that master connection was found
* @out_master_device: on success, the master device of @connection if that
* master device was found
core: fix a crash with autoconnect masters with autoconnect slaves 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.
2014-01-28 17:24:26 -05:00
* @out_master_ac: on success, the master ActiveConnection of @connection if
* there already is one
core: make find_master() return a GError on failure
2014-01-29 11:48:03 -05:00
* @error: the error, if an error occurred
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
*
core: Fix the find_master() and ensure_master_active_connection() docs These two functions have confusing semantics, so document them in better detail (which also highlights some bugs).
2014-01-29 13:22:53 -05:00
* Given an #NMConnection, attempts to find its master. If @connection has
* no master, this will return %TRUE and @out_master_connection and
* @out_master_device will be untouched.
*
* If @connection does have a master, then the outputs depend on what is in its
* #NMSettingConnection:master property:
*
core: fix a crash with autoconnect masters with autoconnect slaves 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.
2014-01-28 17:24:26 -05:00
* If "master" is the ifname of an existing #NMDevice, and that device has a
* compatible master connection activated or activating on it, then
* @out_master_device, @out_master_connection, and @out_master_ac will all be
* set. If the device exists and is idle, only @out_master_device will be set.
* If the device exists and has an incompatible connection on it, an error
* will be returned.
core: Fix the find_master() and ensure_master_active_connection() docs These two functions have confusing semantics, so document them in better detail (which also highlights some bugs).
2014-01-29 13:22:53 -05:00
*
* If "master" is the ifname of a non-existent device, then @out_master_device
* will be %NULL, and @out_master_connection will be a connection whose
core: fix a crash with autoconnect masters with autoconnect slaves 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.
2014-01-28 17:24:26 -05:00
* activation would cause the creation of that device. @out_master_ac MAY be
* set in this case as well (if the connection has started activating, but has
* not yet created its device).
core: Fix the find_master() and ensure_master_active_connection() docs These two functions have confusing semantics, so document them in better detail (which also highlights some bugs).
2014-01-29 13:22:53 -05:00
*
core: Tighten up find_master() and ensure_master_active_connection() semantics Return activation errors in a few edge cases rather than doing the wrong thing.
2014-01-29 13:22:53 -05:00
* If "master" is the UUID of a compatible master connection, then
* @out_master_connection will be the identified connection, and @out_master_device
core: fix a crash with autoconnect masters with autoconnect slaves 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.
2014-01-28 17:24:26 -05:00
* and/or @out_master_ac will be set if the connection is currently activating.
* (@out_master_device will not be set if the device exists but does not have
* @out_master_connection active/activating on it.)
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
*
* Returns: %TRUE if the master device and/or connection could be found or if
* the connection did not require a master, %FALSE otherwise
**/
static gboolean
find_master (NMManager *self,
NMConnection *connection,
NMDevice *device,
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
NMSettingsConnection **out_master_connection,
core: make find_master() return a GError on failure
2014-01-29 11:48:03 -05:00
NMDevice **out_master_device,
core: fix a crash with autoconnect masters with autoconnect slaves 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.
2014-01-28 17:24:26 -05:00
NMActiveConnection **out_master_ac,
core: make find_master() return a GError on failure
2014-01-29 11:48:03 -05:00
GError **error)
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMSettingConnection *s_con;
const char *master;
NMDevice *master_device = NULL;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *master_connection;
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
s_con = nm_connection_get_setting_connection (connection);
g_assert (s_con);
master = nm_setting_connection_get_master (s_con);
if (master == NULL)
return TRUE; /* success, but no master */
/* Try as an interface name first */
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
master_device = find_device_by_iface (self, master, NULL, connection);
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
if (master_device) {
core: make find_master() return a GError on failure
2014-01-29 11:48:03 -05:00
if (master_device == device) {
g_set_error_literal (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_DEPENDENCY_FAILED,
"Device cannot be its own master");
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
return FALSE;
core: make find_master() return a GError on failure
2014-01-29 11:48:03 -05:00
}
core: Tighten up find_master() and ensure_master_active_connection() semantics Return activation errors in a few edge cases rather than doing the wrong thing.
2014-01-29 13:22:53 -05:00
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
master_connection = nm_device_get_settings_connection (master_device);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if ( master_connection
&& !is_compatible_with_slave (nm_settings_connection_get_connection (master_connection),
connection)) {
core: Tighten up find_master() and ensure_master_active_connection() semantics Return activation errors in a few edge cases rather than doing the wrong thing.
2014-01-29 13:22:53 -05:00
g_set_error (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_DEPENDENCY_FAILED,
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
"The active connection on %s is not compatible",
nm_device_get_iface (master_device));
core: Tighten up find_master() and ensure_master_active_connection() semantics Return activation errors in a few edge cases rather than doing the wrong thing.
2014-01-29 13:22:53 -05:00
return FALSE;
}
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
} else {
/* Try master as a connection UUID */
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
master_connection = nm_settings_get_connection_by_uuid (priv->settings, master);
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
if (master_connection) {
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *candidate;
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
/* Check if the master connection is activated on some device already */
c_list_for_each_entry (candidate, &priv->devices_lst_head, devices_lst) {
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
if (candidate == device)
continue;
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
if (nm_device_get_settings_connection (candidate) == master_connection) {
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
master_device = candidate;
break;
}
}
}
}
if (out_master_connection)
*out_master_connection = master_connection;
if (out_master_device)
*out_master_device = master_device;
manager: cleanup find_ac_for_connection() in "nm-manager.c" - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
2017-03-13 14:01:47 +01:00
if (out_master_ac && master_connection) {
manager: extend helper function to find all matching active-connections ... instead of just the first. It's not used yet, and there is no change in behavior.
2018-04-19 15:27:54 +02:00
*out_master_ac = active_connection_find (self, master_connection, NULL,
NM_ACTIVE_CONNECTION_STATE_DEACTIVATING,
NULL);
manager: cleanup find_ac_for_connection() in "nm-manager.c" - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
2017-03-13 14:01:47 +01:00
}
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
core: make find_master() return a GError on failure
2014-01-29 11:48:03 -05:00
if (master_device || master_connection)
return TRUE;
else {
g_set_error_literal (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_UNKNOWN_DEVICE,
"Master connection not found or invalid");
return FALSE;
}
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
}
/**
* ensure_master_active_connection:
* @self: the #NMManager
core: pass NMAuthSubject around activation paths instead of uid + dbus sender
2013-07-29 13:11:47 -05:00
* @subject: the #NMAuthSubject representing the requestor of this activation
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
* @connection: the connection that should depend on @master_connection
* @device: the #NMDevice, if any, which will activate @connection
core: Fix the find_master() and ensure_master_active_connection() docs These two functions have confusing semantics, so document them in better detail (which also highlights some bugs).
2014-01-29 13:22:53 -05:00
* @master_connection: the master connection, or %NULL
* @master_device: the master device, or %NULL
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
* @activation_reason: the reason for activation
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
* @error: the error, if an error occurred
*
* Determines whether a given #NMConnection depends on another connection to
* be activated, and if so, finds that master connection or creates it.
*
core: Fix the find_master() and ensure_master_active_connection() docs These two functions have confusing semantics, so document them in better detail (which also highlights some bugs).
2014-01-29 13:22:53 -05:00
* If @master_device and @master_connection are both set then @master_connection
core: Tighten up find_master() and ensure_master_active_connection() semantics Return activation errors in a few edge cases rather than doing the wrong thing.
2014-01-29 13:22:53 -05:00
* MUST already be activated or activating on @master_device, and the function will
* return the existing #NMActiveConnection.
core: Fix the find_master() and ensure_master_active_connection() docs These two functions have confusing semantics, so document them in better detail (which also highlights some bugs).
2014-01-29 13:22:53 -05:00
*
core: Tighten up find_master() and ensure_master_active_connection() semantics Return activation errors in a few edge cases rather than doing the wrong thing.
2014-01-29 13:22:53 -05:00
* If only @master_device is set, and it has an #NMActiveConnection, then the
* function will return it if it is a compatible master, or an error if not. If it
* doesn't have an AC, then the function will create one if a compatible master
* connection exists, or return an error if not.
core: Fix the find_master() and ensure_master_active_connection() docs These two functions have confusing semantics, so document them in better detail (which also highlights some bugs).
2014-01-29 13:22:53 -05:00
*
* If only @master_connection is set, then this will try to find or create a compatible
* #NMDevice, and either activate @master_connection on that device or return an error.
*
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
* Returns: the master #NMActiveConnection that the caller should depend on, or
* %NULL if an error occurred
*/
static NMActiveConnection *
ensure_master_active_connection (NMManager *self,
core: pass NMAuthSubject around activation paths instead of uid + dbus sender
2013-07-29 13:11:47 -05:00
NMAuthSubject *subject,
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
NMConnection *connection,
NMDevice *device,
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
NMSettingsConnection *master_connection,
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
NMDevice *master_device,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
NMActivationReason activation_reason,
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
GError **error)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
NMActiveConnection *ac;
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
NMActiveConnection *master_ac = NULL;
NMDeviceState master_state;
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
gboolean bind_lifetime_to_profile_visibility;
g_return_val_if_fail (connection, NULL);
g_return_val_if_fail (master_connection || master_device, FALSE);
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
bind_lifetime_to_profile_visibility = NM_FLAGS_HAS (nm_device_get_activation_state_flags (device),
NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY);
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
/* If the master device isn't activated then we need to activate it using
* compatible connection. If it's already activating we can just proceed.
*/
if (master_device) {
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
NMSettingsConnection *device_connection = nm_device_get_settings_connection (master_device);
core: Tighten up find_master() and ensure_master_active_connection() semantics Return activation errors in a few edge cases rather than doing the wrong thing.
2014-01-29 13:22:53 -05:00
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
/* If we're passed a connection and a device, we require that connection
* be already activated on the device, eg returned from find_master().
*/
core: fix activation of slave when master is not active, but device exists NM fails to activate a slave if the master device already exists but has not active connection. One way to reproduce, create a bond master/slave configuration and ensure that the master device exists (e.g. by activating the bond, and killing NM without taking down the device, or externally via `ip link add`). If you try to activate the slave it will fail with the following message (in nmcli): "Error: Connection activation failed: The active connection on MASTER is not a valid master for 'SLAVE'" although MASTER is not active. This also triggers the following assertion: #0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0 #1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0 #2 0x000000000047646a in is_compatible_with_slave (master=0x0, slave=slave@entry=0xc4aa60) at nm-manager.c:2193 #3 0x000000000047e289 in ensure_master_active_connection (self=self@entry=0xc8d150, subject=0x7f23b80059e0, connection=connection@entry=0xc4aa60, device=device@entry=0xcac380, master_connection=master_connection@entry=0x0, master_device=master_device@entry=0xc9e800, error=error@entry=0x7fffa5cc4958) at nm-manager.c:2395 #4 0x000000000047eb4a in _internal_activate_device (self=self@entry=0xc8d150, active=active@entry=0xcc33b0, error=error@entry=0x7fffa5cc4958) at nm-manager.c:2665 #5 0x000000000047ecf2 in _internal_activate_generic (self=self@entry=0xc8d150, active=active@entry=0xcc33b0, error=error@entry=0x7fffa5cc4958) at nm-manager.c:2712 #6 0x000000000047ef2b in _internal_activation_auth_done (active=0xcc33b0, success=<optimized out>, error_desc=0x0, user_data1=0xc8d150, user_data2=<optimized out>) at nm-manager.c:2848 #7 0x0000000000466fa1 in auth_done (chain=0xcef020, error=0x0, unused=<optimized out>, user_data=<optimized out>) at nm-active-connection.c:603 #8 0x00000000004753da in auth_chain_finish (user_data=0xcef020) at nm-manager-auth.c:88 #9 0x0000003370c492a6 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #10 0x0000003370c49628 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0 #11 0x0000003370c49a3a in g_main_loop_run () from /lib64/libglib-2.0.so.0 #12 0x0000000000429e65 in main (argc=1, argv=0x7fffa5cc4e48) at main.c:678 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-11 20:35:08 +02:00
g_assert (!master_connection || master_connection == device_connection);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if ( device_connection
&& !is_compatible_with_slave (nm_settings_connection_get_connection (device_connection),
connection)) {
core: Tighten up find_master() and ensure_master_active_connection() semantics Return activation errors in a few edge cases rather than doing the wrong thing.
2014-01-29 13:22:53 -05:00
g_set_error (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_DEPENDENCY_FAILED,
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
"The active connection %s is not compatible",
core: Tighten up find_master() and ensure_master_active_connection() semantics Return activation errors in a few edge cases rather than doing the wrong thing.
2014-01-29 13:22:53 -05:00
nm_connection_get_id (connection));
return NULL;
}
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
master_state = nm_device_get_state (master_device);
if ( (master_state == NM_DEVICE_STATE_ACTIVATED)
|| nm_device_is_activating (master_device)) {
/* Device already using master_connection */
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
ac = NM_ACTIVE_CONNECTION (nm_device_get_act_request (master_device));
g_return_val_if_fail (device_connection, ac);
if (!bind_lifetime_to_profile_visibility) {
/* unbind the lifetime. */
nm_active_connection_set_state_flags_clear (ac,
NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY);
}
return ac;
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
}
core: Fix the find_master() and ensure_master_active_connection() docs These two functions have confusing semantics, so document them in better detail (which also highlights some bugs).
2014-01-29 13:22:53 -05:00
/* If the device is disconnected, find a compatible connection and
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
* activate it on the device.
*/
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
if (master_state == NM_DEVICE_STATE_DISCONNECTED || !nm_device_is_real (master_device)) {
core: refactor nm_manager_get_activatable_connections() to return an array ... instead of a GSList.
2017-02-03 15:13:03 +01:00
gs_free NMSettingsConnection **connections = NULL;
guint i;
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
g_assert (master_connection == NULL);
/* Find a compatible connection and activate this device using it */
core: extend nm_manager_get_activatable_connections() for autoconnect and multi-connect In general, a activatable connection is one that is currently not active, or supports to be activatable multiple times according to multi-connect setting. In addition, during autoconnect, a profile which is marked as multi-connect=manual-multiple will not be avalable. Hence, add an argument "for_auto_activation". The code is mostly unused but will be used next (except for connections, which set connection.multi-connect=multiple).
2018-06-27 14:20:57 +02:00
connections = nm_manager_get_activatable_connections (self, FALSE, TRUE, NULL);
core: refactor nm_manager_get_activatable_connections() to return an array ... instead of a GSList.
2017-02-03 15:13:03 +01:00
for (i = 0; connections[i]; i++) {
NMSettingsConnection *candidate = connections[i];
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMConnection *cand_conn = nm_settings_connection_get_connection (candidate);
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
core: add support for team device Signed-off-by: Jiri Pirko <jiri@resnulli.us>
2013-07-25 15:36:45 +02:00
/* Ensure eg bond/team slave and the candidate master is a
* bond/team master
*/
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (!is_compatible_with_slave (cand_conn, connection))
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
continue;
core: give better error reason why device is unavailable The error reason is still unused.
2018-06-27 16:21:43 +02:00
if (nm_device_check_connection_available (master_device,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
cand_conn,
core: give better error reason why device is unavailable The error reason is still unused.
2018-06-27 16:21:43 +02:00
NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST,
NULL,
NULL)) {
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
master_ac = nm_manager_activate_connection (self,
candidate,
NULL,
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
NULL,
core: make nm_manager_activate_connection() take a Device, not a path Simpler; everywhere that called it has an NMDevice already anyway.
2012-09-13 15:57:36 -05:00
master_device,
core: pass NMAuthSubject around activation paths instead of uid + dbus sender
2013-07-29 13:11:47 -05:00
subject,
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
NM_ACTIVATION_TYPE_MANAGED,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
activation_reason,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
bind_lifetime_to_profile_visibility
? NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY
: NM_ACTIVATION_STATE_FLAG_NONE,
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
error);
return master_ac;
}
}
g_set_error (error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_UNKNOWN_CONNECTION,
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
"No compatible connection found.");
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
return NULL;
}
/* Otherwise, the device is unmanaged, unavailable, or disconnecting */
g_set_error (error,
NM_MANAGER_ERROR,
libnm-core, core: move NMManagerError to nm-errors Move the definition of NMManagerError to nm-errors, register it with D-Bus, and verify in the tests that it maps correctly. NM_MANAGER_ERROR_INTERNAL gets renamed to NM_MANAGER_ERROR_FAILED for consistency. NM_MANAGER_ERROR_UNMANAGED_DEVICE is dropped since that name doesn't really describe the one place it was previously used in. NM_MANAGER_ERROR_SYSTEM_CONNECTION is dropped because it was't being used. NM_MANAGER_ERROR_UNSUPPORTED_CONNECTION_TYPE is dropped because it can be replaced with an NM_CONNECTION_ERROR. NM_MANAGER_ERROR_AUTOCONNECT_NOT_ALLOWED is turned into the more generic NM_MANAGER_ERROR_CONNECTION_NOT_AVAILABLE. Also, remove the <tp:possible-errors> sections from nm-manager.xml, since they were completely out of date.
2014-10-15 15:27:25 -04:00
NM_MANAGER_ERROR_DEPENDENCY_FAILED,
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
"Device unmanaged or not available for activation");
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
} else if (master_connection) {
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *candidate;
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
/* Find a compatible device and activate it using this connection */
c_list_for_each_entry (candidate, &priv->devices_lst_head, devices_lst) {
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
if (candidate == device) {
/* A device obviously can't be its own master */
continue;
}
core: give better error reason why device is unavailable The error reason is still unused.
2018-06-27 16:21:43 +02:00
if (!nm_device_check_connection_available (candidate,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_settings_connection_get_connection (master_connection),
core: give better error reason why device is unavailable The error reason is still unused.
2018-06-27 16:21:43 +02:00
NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST,
NULL,
NULL))
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
continue;
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
if (!nm_device_is_software (candidate)) {
master_state = nm_device_get_state (candidate);
if (nm_device_is_real (candidate) && master_state != NM_DEVICE_STATE_DISCONNECTED)
continue;
}
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
core: don't allow auto-activation of a master that has been disconnected The master-activation code was ignoring whether or not the master device was inhibiting automatic connections.
2013-01-30 12:52:42 -06:00
master_ac = nm_manager_activate_connection (self,
master_connection,
NULL,
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
NULL,
core: make nm_manager_activate_connection() take a Device, not a path Simpler; everywhere that called it has an NMDevice already anyway.
2012-09-13 15:57:36 -05:00
candidate,
core: pass NMAuthSubject around activation paths instead of uid + dbus sender
2013-07-29 13:11:47 -05:00
subject,
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
NM_ACTIVATION_TYPE_MANAGED,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
activation_reason,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
bind_lifetime_to_profile_visibility
? NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY
: NM_ACTIVATION_STATE_FLAG_NONE,
core: don't allow auto-activation of a master that has been disconnected The master-activation code was ignoring whether or not the master device was inhibiting automatic connections.
2013-01-30 12:52:42 -06:00
error);
return master_ac;
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
}
g_set_error (error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_UNKNOWN_DEVICE,
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
"No device available");
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
} else
g_assert_not_reached ();
return NULL;
}
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
typedef struct {
NMSettingsConnection *connection;
NMDevice *device;
} SlaveConnectionInfo;
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
/**
* find_slaves:
* @manager: #NMManager object
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
* @sett_conn: the master #NMSettingsConnection to find slave connections for
* @device: the master #NMDevice for the @sett_conn
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
* @out_n_slaves: on return, the number of slaves found
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
*
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
* Given an #NMSettingsConnection, attempts to find its slaves. If @sett_conn is not
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
* master, or has not any slaves, this will return %NULL.
*
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
* Returns: an array of #SlaveConnectionInfo for given master @sett_conn, or %NULL
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
**/
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
static SlaveConnectionInfo *
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
find_slaves (NMManager *manager,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
NMDevice *device,
manager: propagate the for-user-request flag for slaves autoconnection If the master is activated by user, propagate the for-user-request to slaves activations when autoconnecting slaves, so that they can manage slaves device as needed. Reproducer: ip l add eth1 type veth peer name eth2 ip l set eth1 up ip l set eth2 up sleep 2 echo " * Initial state" echo " - eth1: $(nmcli -g general.state device show eth1)" nmcli con add type ethernet ifname eth1 con-name slave-test+ master br-test slave-type bridge nmcli con add type bridge ifname br-test con-name br-test+ connection.autoconnect-slaves yes ip4 172.25.1.1/24 nmcli con up br-test+ echo " * After user activation" echo " - br-test: $(nmcli -g general.state device show br-test)" echo " - eth1: $(nmcli -g general.state device show eth1)" should give: * Initial state - eth1: 10 (unmanaged) * After user activation - br-test: 100 (connected) - eth1: 100 (connected)
2019-07-02 11:51:29 +02:00
guint *out_n_slaves,
gboolean for_user_request)
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (manager);
core: refactor nm_settings_get_connections_sorted() to return array instead of GSList We call these functions a lot. A GSList is just the wrong tool for the job. Refactor the code to use instead a sorted array everywhere. This means, we malloc() one array for all connections instead slice-allocate a GSList item for each. Also, sorting an array is faster then sorting a GSList. Technically, the GSList implementation had the same big-O runtime complexity, but using an array is still faster. That is, sorting an array and a GSList is both O(n*log(n)). Actually, nm_settings_get_connections_sorted() used g_slist_insert_sorted() instead of g_slist_sort(). That results in O(n^2). That could have been fixed to have O(n*log(n)), but instead refactor the code to use an array.
2017-02-03 14:15:16 +01:00
gs_free NMSettingsConnection **all_connections = NULL;
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
guint n_all_connections;
core: refactor nm_settings_get_connections_sorted() to return array instead of GSList We call these functions a lot. A GSList is just the wrong tool for the job. Refactor the code to use instead a sorted array everywhere. This means, we malloc() one array for all connections instead slice-allocate a GSList item for each. Also, sorting an array is faster then sorting a GSList. Technically, the GSList implementation had the same big-O runtime complexity, but using an array is still faster. That is, sorting an array and a GSList is both O(n*log(n)). Actually, nm_settings_get_connections_sorted() used g_slist_insert_sorted() instead of g_slist_sort(). That results in O(n^2). That could have been fixed to have O(n*log(n)), but instead refactor the code to use an array.
2017-02-03 14:15:16 +01:00
guint i;
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
SlaveConnectionInfo *slaves = NULL;
guint n_slaves = 0;
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
NMSettingConnection *s_con;
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
gs_unref_hashtable GHashTable *devices = NULL;
nm_assert (out_n_slaves);
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
s_con = nm_connection_get_setting_connection (nm_settings_connection_get_connection (sett_conn));
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
g_return_val_if_fail (s_con, NULL);
all: use nm_direct_hash() instead of g_direct_hash() We also do this for libnm, where it causes visible changes in behavior. But if somebody would rely on the hashing implementation for hash tables, it would be seriously flawed.
2017-11-15 16:06:43 +01:00
devices = g_hash_table_new (nm_direct_hash, NULL);
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
/* Search through all connections, not only inactive ones, because
* even if a slave was already active, it might be deactivated during
* master reactivation.
*/
core: merge nm_settings_get_connections_sorted() with nm_settings_get_connections_clone()
2017-11-22 12:46:58 +01:00
all_connections = nm_settings_get_connections_clone (priv->settings, &n_all_connections,
NULL, NULL,
nm_settings_connection_cmp_autoconnect_priority_p_with_data, NULL);
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
for (i = 0; i < n_all_connections; i++) {
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
NMSettingsConnection *master_connection = NULL;
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
NMDevice *master_device = NULL, *slave_device;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *candidate = all_connections[i];
find_master (manager,
nm_settings_connection_get_connection (candidate),
NULL,
&master_connection,
&master_device,
NULL,
NULL);
if ( (master_connection && master_connection == sett_conn)
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
|| (master_device && master_device == device)) {
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
slave_device = nm_manager_get_best_device_for_connection (manager,
candidate,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NULL,
manager: propagate the for-user-request flag for slaves autoconnection If the master is activated by user, propagate the for-user-request to slaves activations when autoconnecting slaves, so that they can manage slaves device as needed. Reproducer: ip l add eth1 type veth peer name eth2 ip l set eth1 up ip l set eth2 up sleep 2 echo " * Initial state" echo " - eth1: $(nmcli -g general.state device show eth1)" nmcli con add type ethernet ifname eth1 con-name slave-test+ master br-test slave-type bridge nmcli con add type bridge ifname br-test con-name br-test+ connection.autoconnect-slaves yes ip4 172.25.1.1/24 nmcli con up br-test+ echo " * After user activation" echo " - br-test: $(nmcli -g general.state device show br-test)" echo " - eth1: $(nmcli -g general.state device show eth1)" should give: * Initial state - eth1: 10 (unmanaged) * After user activation - br-test: 100 (connected) - eth1: 100 (connected)
2019-07-02 11:51:29 +02:00
for_user_request,
core: return error reason from nm_manager_get_best_device_for_connection() Still unused, but will be used to give a better failure reason when no device is found. The difficulty here is to select the failure message from the most appropriate device. This might still need some tweaking by setting the error codes accordingly and re-ordering checks so that failure cares that are more accurate are handled first.
2018-07-10 11:50:21 +02:00
devices,
NULL);
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
if (!slaves) {
/* what we allocate is quite likely much too large. Don't bother, it is only
* a temporary buffer. */
slaves = g_new (SlaveConnectionInfo, n_all_connections);
}
nm_assert (n_slaves < n_all_connections);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
slaves[n_slaves].connection = candidate,
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
slaves[n_slaves].device = slave_device,
n_slaves++;
if (slave_device)
g_hash_table_add (devices, slave_device);
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
}
}
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
*out_n_slaves = n_slaves;
/* Warning: returns NULL if n_slaves is zero. */
return slaves;
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
}
static gboolean
should_connect_slaves (NMConnection *connection, NMDevice *device)
{
NMSettingConnection *s_con;
core: add nm_config_data_get_connection_default_int64()
2018-09-05 09:24:33 +02:00
NMSettingConnectionAutoconnectSlaves val;
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
s_con = nm_connection_get_setting_connection (connection);
g_assert (s_con);
core: add nm_config_data_get_connection_default_int64()
2018-09-05 09:24:33 +02:00
val = nm_setting_connection_get_autoconnect_slaves (s_con);
if (val != NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_DEFAULT)
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
goto out;
core: add nm_config_data_get_connection_default_int64()
2018-09-05 09:24:33 +02:00
val = nm_config_data_get_connection_default_int64 (NM_CONFIG_GET_DATA,
core: add checks on connection default properties Add a new CON_DEFAULT() macro that places a property name into a special section used at runtime to check whether it is a supported connection default. Unfortunately, this mechanism doesn't work for plugins so we have to enumerate the connection defaults from plugins in the daemon using another CON_DEFAULT_NOP() macro.
2018-11-14 14:52:21 +01:00
NM_CON_DEFAULT ("connection.autoconnect-slaves"),
core: add nm_config_data_get_connection_default_int64()
2018-09-05 09:24:33 +02:00
device,
0, 1, -1);
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
out:
core: add nm_config_data_get_connection_default_int64()
2018-09-05 09:24:33 +02:00
if (val == NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_NO)
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
return FALSE;
core: add nm_config_data_get_connection_default_int64()
2018-09-05 09:24:33 +02:00
if (val == NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_YES)
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
return TRUE;
return FALSE;
}
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
static int
core: add configuration flag to choose slaves activation order Commits 39d0559d9a7a ("platform: sort links by name instead of ifindex") and 529a0a1a7f19 ("manager: sort slaves to be autoconnected by device name") changed the order of activation of slaves. Introduce a system-wide configuration property to preserve the old behavior. https://bugzilla.redhat.com/show_bug.cgi?id=1452585
2017-05-15 17:17:26 +02:00
compare_slaves (gconstpointer a, gconstpointer b, gpointer sort_by_name)
manager: sort slaves to be autoconnected by device name Autoconnect slaves based on device name order instead of activation timestamp.
2017-03-02 16:14:18 +01:00
{
const SlaveConnectionInfo *a_info = a;
const SlaveConnectionInfo *b_info = b;
/* Slaves without a device at the end */
if (!a_info->device)
return 1;
if (!b_info->device)
return -1;
core: add configuration flag to choose slaves activation order Commits 39d0559d9a7a ("platform: sort links by name instead of ifindex") and 529a0a1a7f19 ("manager: sort slaves to be autoconnected by device name") changed the order of activation of slaves. Introduce a system-wide configuration property to preserve the old behavior. https://bugzilla.redhat.com/show_bug.cgi?id=1452585
2017-05-15 17:17:26 +02:00
if (GPOINTER_TO_INT (sort_by_name)) {
return g_strcmp0 (nm_device_get_iface (a_info->device),
nm_device_get_iface (b_info->device));
}
return nm_device_get_ifindex (a_info->device) - nm_device_get_ifindex (b_info->device);
manager: sort slaves to be autoconnected by device name Autoconnect slaves based on device name order instead of activation timestamp.
2017-03-02 16:14:18 +01:00
}
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
static void
manager: use logging helpers
2016-03-02 11:38:26 +01:00
autoconnect_slaves (NMManager *self,
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
NMSettingsConnection *master_connection,
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
NMDevice *master_device,
manager: propagate the for-user-request flag for slaves autoconnection If the master is activated by user, propagate the for-user-request to slaves activations when autoconnecting slaves, so that they can manage slaves device as needed. Reproducer: ip l add eth1 type veth peer name eth2 ip l set eth1 up ip l set eth2 up sleep 2 echo " * Initial state" echo " - eth1: $(nmcli -g general.state device show eth1)" nmcli con add type ethernet ifname eth1 con-name slave-test+ master br-test slave-type bridge nmcli con add type bridge ifname br-test con-name br-test+ connection.autoconnect-slaves yes ip4 172.25.1.1/24 nmcli con up br-test+ echo " * After user activation" echo " - br-test: $(nmcli -g general.state device show br-test)" echo " - eth1: $(nmcli -g general.state device show eth1)" should give: * Initial state - eth1: 10 (unmanaged) * After user activation - br-test: 100 (connected) - eth1: 100 (connected)
2019-07-02 11:51:29 +02:00
NMAuthSubject *subject,
gboolean for_user_request)
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
{
GError *local_err = NULL;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (should_connect_slaves (nm_settings_connection_get_connection (master_connection),
master_device)) {
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
gs_free SlaveConnectionInfo *slaves = NULL;
guint i, n_slaves = 0;
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
gboolean bind_lifetime_to_profile_visibility;
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
manager: propagate the for-user-request flag for slaves autoconnection If the master is activated by user, propagate the for-user-request to slaves activations when autoconnecting slaves, so that they can manage slaves device as needed. Reproducer: ip l add eth1 type veth peer name eth2 ip l set eth1 up ip l set eth2 up sleep 2 echo " * Initial state" echo " - eth1: $(nmcli -g general.state device show eth1)" nmcli con add type ethernet ifname eth1 con-name slave-test+ master br-test slave-type bridge nmcli con add type bridge ifname br-test con-name br-test+ connection.autoconnect-slaves yes ip4 172.25.1.1/24 nmcli con up br-test+ echo " * After user activation" echo " - br-test: $(nmcli -g general.state device show br-test)" echo " - eth1: $(nmcli -g general.state device show eth1)" should give: * Initial state - eth1: 10 (unmanaged) * After user activation - br-test: 100 (connected) - eth1: 100 (connected)
2019-07-02 11:51:29 +02:00
slaves = find_slaves (self, master_connection, master_device, &n_slaves, for_user_request);
manager: sort slaves to be autoconnected by device name Autoconnect slaves based on device name order instead of activation timestamp.
2017-03-02 16:14:18 +01:00
if (n_slaves > 1) {
config: remove nm_config_data_get_value_cached() It has almost no callers, and it is a bit of a strange API. Let's not cache the last accessed value inside NMConfigData. Instead, free it right after use. It was not reused anyway, it only hangs around as convenience for the caller.
2017-10-24 08:35:42 +02:00
gs_free char *value = NULL;
value = nm_config_data_get_value (NM_CONFIG_GET_DATA,
NM_CONFIG_KEYFILE_GROUP_MAIN,
NM_CONFIG_KEYFILE_KEY_MAIN_SLAVES_ORDER,
NM_CONFIG_GET_VALUE_STRIP);
manager: sort slaves to be autoconnected by device name Autoconnect slaves based on device name order instead of activation timestamp.
2017-03-02 16:14:18 +01:00
g_qsort_with_data (slaves, n_slaves, sizeof (slaves[0]),
core: add configuration flag to choose slaves activation order Commits 39d0559d9a7a ("platform: sort links by name instead of ifindex") and 529a0a1a7f19 ("manager: sort slaves to be autoconnected by device name") changed the order of activation of slaves. Introduce a system-wide configuration property to preserve the old behavior. https://bugzilla.redhat.com/show_bug.cgi?id=1452585
2017-05-15 17:17:26 +02:00
compare_slaves,
GINT_TO_POINTER (!nm_streq0 (value, "index")));
manager: sort slaves to be autoconnected by device name Autoconnect slaves based on device name order instead of activation timestamp.
2017-03-02 16:14:18 +01:00
}
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
bind_lifetime_to_profile_visibility = n_slaves > 0
&& NM_FLAGS_HAS (nm_device_get_activation_state_flags (master_device),
NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY);
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
for (i = 0; i < n_slaves; i++) {
SlaveConnectionInfo *slave = &slaves[i];
manager: allow slave connection to auto-connect its slaves Since connection.autoconnect-slaves was introduced, we only allowed it to autoactivate slaves for connections that were not slave themselves. It seems useful to remove such limitation, but we must prevent an infinite loop if there is a circular dependency between connections. https://bugzilla.redhat.com/show_bug.cgi?id=1360386
2016-09-26 16:01:27 +02:00
const char *uuid;
/* To avoid loops when autoconnecting slaves, we propagate
* the UUID of the initial connection down to slaves until
* the same connection is found.
*/
uuid = g_object_get_qdata (G_OBJECT (master_connection),
autoconnect_root_quark ());
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
if (nm_streq0 (nm_settings_connection_get_uuid (slave->connection), uuid)) {
manager: allow slave connection to auto-connect its slaves Since connection.autoconnect-slaves was introduced, we only allowed it to autoactivate slaves for connections that were not slave themselves. It seems useful to remove such limitation, but we must prevent an infinite loop if there is a circular dependency between connections. https://bugzilla.redhat.com/show_bug.cgi?id=1360386
2016-09-26 16:01:27 +02:00
_LOGI (LOGD_CORE,
"will NOT activate slave connection '%s' (%s) as a dependency for master '%s' (%s): "
"circular dependency detected",
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
nm_settings_connection_get_id (slave->connection),
nm_settings_connection_get_uuid (slave->connection),
manager: allow slave connection to auto-connect its slaves Since connection.autoconnect-slaves was introduced, we only allowed it to autoactivate slaves for connections that were not slave themselves. It seems useful to remove such limitation, but we must prevent an infinite loop if there is a circular dependency between connections. https://bugzilla.redhat.com/show_bug.cgi?id=1360386
2016-09-26 16:01:27 +02:00
nm_settings_connection_get_id (master_connection),
nm_settings_connection_get_uuid (master_connection));
continue;
}
if (!uuid)
uuid = nm_settings_connection_get_uuid (master_connection);
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
g_object_set_qdata_full (G_OBJECT (slave->connection),
manager: allow slave connection to auto-connect its slaves Since connection.autoconnect-slaves was introduced, we only allowed it to autoactivate slaves for connections that were not slave themselves. It seems useful to remove such limitation, but we must prevent an infinite loop if there is a circular dependency between connections. https://bugzilla.redhat.com/show_bug.cgi?id=1360386
2016-09-26 16:01:27 +02:00
autoconnect_root_quark (),
g_strdup (uuid),
g_free);
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
if (!slave->device) {
manager: check that slaves connection have a compatible device When slave connections are autoactivated as dependency to master we don't check if a compatible device is available before trying to activate them, leading to the following failed assertion: nm_act_request_new: assertion 'NM_IS_DEVICE (device)' failed
2017-02-23 18:15:10 +01:00
_LOGD (LOGD_CORE,
"will NOT activate slave connection '%s' (%s) as a dependency for master '%s' (%s): "
"no compatible device found",
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
nm_settings_connection_get_id (slave->connection),
nm_settings_connection_get_uuid (slave->connection),
manager: check that slaves connection have a compatible device When slave connections are autoactivated as dependency to master we don't check if a compatible device is available before trying to activate them, leading to the following failed assertion: nm_act_request_new: assertion 'NM_IS_DEVICE (device)' failed
2017-02-23 18:15:10 +01:00
nm_settings_connection_get_id (master_connection),
nm_settings_connection_get_uuid (master_connection));
continue;
}
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGD (LOGD_CORE, "will activate slave connection '%s' (%s) as a dependency for master '%s' (%s)",
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
nm_settings_connection_get_id (slave->connection),
nm_settings_connection_get_uuid (slave->connection),
manager: use logging helpers
2016-03-02 11:38:26 +01:00
nm_settings_connection_get_id (master_connection),
nm_settings_connection_get_uuid (master_connection));
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
/* Schedule slave activation */
manager: use logging helpers
2016-03-02 11:38:26 +01:00
nm_manager_activate_connection (self,
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
slave->connection,
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
NULL,
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
NULL,
manager: rework find_slaves() to return the matching device Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
2017-02-24 09:32:05 +01:00
slave->device,
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
subject,
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
NM_ACTIVATION_TYPE_MANAGED,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
NM_ACTIVATION_REASON_AUTOCONNECT_SLAVES,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
bind_lifetime_to_profile_visibility
? NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY
: NM_ACTIVATION_STATE_FLAG_NONE,
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
&local_err);
if (local_err) {
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGW (LOGD_CORE, "Slave connection activation failed: %s", local_err->message);
manager: fix clearing error variable in autoconnect_slaves()
2017-02-24 12:31:20 +01:00
g_clear_error (&local_err);
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
}
}
}
}
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
static gboolean
_internal_activate_vpn (NMManager *self, NMActiveConnection *active, GError **error)
core: reorganize activation flow by splitting out VPN activation work Just split the VPN-specific stuff out to its own function so that nm_manager_activate_connection() isn't so large.
2012-02-23 10:04:41 -06:00
{
manager: reorder adding active-connection and queueing activation Note how recheck_assume_connection() called: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); active_connection_add (self, active); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); That differs from the order during _internal_activate_generic(), where we would end up with: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); active_connection_add (self, active); It makes more sense to me to *first* add the connection, and only then starting the activation with nm_device_queue_activation(). Also, let active_connection_add() always export the new active connection object, if it is not already exported. All callers of active_connection_add() ensured that the new object is already exported.
2018-02-05 15:17:06 +01:00
nm_assert (NM_IS_VPN_CONNECTION (active));
core: simplify looking up NMActiveConnection objects by object path
2012-09-14 15:21:29 -05:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_dbus_object_export (NM_DBUS_OBJECT (active));
manager: reorder adding active-connection and queueing activation Note how recheck_assume_connection() called: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); active_connection_add (self, active); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); That differs from the order during _internal_activate_generic(), where we would end up with: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); active_connection_add (self, active); It makes more sense to me to *first* add the connection, and only then starting the activation with nm_device_queue_activation(). Also, let active_connection_add() always export the new active connection object, if it is not already exported. All callers of active_connection_add() ensured that the new object is already exported.
2018-02-05 15:17:06 +01:00
if (!nm_vpn_manager_activate_connection (NM_MANAGER_GET_PRIVATE (self)->vpn_manager,
NM_VPN_CONNECTION (active),
error)) {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_dbus_object_unexport (NM_DBUS_OBJECT (active));
manager: reorder adding active-connection and queueing activation Note how recheck_assume_connection() called: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); active_connection_add (self, active); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); That differs from the order during _internal_activate_generic(), where we would end up with: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); active_connection_add (self, active); It makes more sense to me to *first* add the connection, and only then starting the activation with nm_device_queue_activation(). Also, let active_connection_add() always export the new active connection object, if it is not already exported. All callers of active_connection_add() ensured that the new object is already exported.
2018-02-05 15:17:06 +01:00
return FALSE;
}
manager: unexport VPN connections when the activation fails early When a VPN connection can't be activated we have to unexport and dispose it. Commit f2182fbf9b24 ("core: don't emit double PropertiesChanged signal for new active connections") removed the call to nm_exported_object_unexport() in case of failure because the active connection already gets unreferenced on failure. However, an exported object can't be disposed until it's explicitly unexported because GDBus code keeps a reference to it. The result was that the active connection was kept alive and exported, but without explicit references to it. As soon as the connection was unexported, it was also automatically disposed, causing issues like: (src/nm-exported-object.c:1025):dispose: code should not be reached #0 _g_log_abort () at /lib64/libglib-2.0.so.0 #1 g_logv () at /lib64/libglib-2.0.so.0 #2 g_log () at /lib64/libglib-2.0.so.0 #3 g_warn_message () at /lib64/libglib-2.0.so.0 #4 dispose (object=0xaaf110) at src/nm-exported-object.c:1025 #5 dispose (object=0xaaf110) at src/nm-active-connection.c:1246 #6 dispose (object=0xaaf110) at src/vpn/nm-vpn-connection.c:2642 #7 g_object_unref () at /lib64/libgobject-2.0.so.0 #8 registration_data_free () at /lib64/libgio-2.0.so.0 #9 g_hash_table_remove_internal () at /lib64/libglib-2.0.so.0 #10 g_dbus_object_manager_server_unexport_unlocked () at /lib64/libgio-2.0.so.0 #11 g_dbus_object_manager_server_unexport () at /lib64/libgio-2.0.so.0 #12 nm_bus_manager_unregister_object (self=0x9069e0, object=object@entry=0xaaf110) at src/nm-bus-manager.c:858 #13 nm_exported_object_unexport (self=0xaaf110) at src/nm-exported-object.c:714 #14 _settings_connection_removed (connection=<optimized out>, user_data=0xaaf110) at src/nm-active-connection.c:184 #15 g_closure_invoke () at /lib64/libgobject-2.0.so.0 #16 signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #17 g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #18 g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #19 nm_settings_connection_signal_remove (self=self@entry=0x9e4a80, allow_reuse=allow_reuse@entry=0) at src/settings/nm-settings-connection.c:2085 #20 do_delete (self=0x9e4a80, callback=0x58106a <con_delete_cb>, user_data=0xa84fa0) at src/settings/nm-settings-connection.c:768 #21 do_delete (connection=0x9e4a80, callback=0x58106a <con_delete_cb>, user_data=0xa84fa0) at src/settings/plugins/keyfile/nms-keyfile-connection.c:127 #22 nm_settings_connection_delete (self=self@entry=0x9e4a80, callback=callback@entry=0x58106a <con_delete_cb>, user_data=0xa84fa0) at src/settings/nm-settings-connection.c:694 #23 delete_auth_cb (self=self@entry=0x9e4a80, context=context@entry=0x7fffd80131e0, subject=0x91fb40, error=<optimized out>, data=data@entry=0x0) at src/settings/nm-settings-connection.c:1879 #24 pk_auth_cb (chain=0x7fffd00024a0, chain_error=<optimized out>, context=0x7fffd80131e0, user_data=<optimized out>) at src/settings/nm-settings-connection.c:1351 #25 auth_chain_finish (user_data=0x7fffd00024a0) at src/nm-auth-utils.c:92 #26 g_idle_dispatch () at /lib64/libglib-2.0.so.0 Restore the unexport upon failure to fix this. Fixes: f2182fbf9b2423bd8509b2f0cf218edd96dac32c https://bugzilla.redhat.com/show_bug.cgi?id=1440077 (cherry picked from commit 69fd96118e9a5e6b613644c2cb61911d554e7f3b)
2017-04-08 09:43:42 +02:00
manager: reorder adding active-connection and queueing activation Note how recheck_assume_connection() called: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); active_connection_add (self, active); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); That differs from the order during _internal_activate_generic(), where we would end up with: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); active_connection_add (self, active); It makes more sense to me to *first* add the connection, and only then starting the activation with nm_device_queue_activation(). Also, let active_connection_add() always export the new active connection object, if it is not already exported. All callers of active_connection_add() ensured that the new object is already exported.
2018-02-05 15:17:06 +01:00
active_connection_add (self, active);
return TRUE;
core: reorganize activation flow by splitting out VPN activation work Just split the VPN-specific stuff out to its own function so that nm_manager_activate_connection() isn't so large.
2012-02-23 10:04:41 -06:00
}
manager: separate the traversal to disconected to a separate routine Will be useful when we'll be able to defer the realization of the device.
2016-03-24 15:20:44 +01:00
/* Traverse the device to disconnected state. This means that the device is ready
* for connection and will proceed activating if there's an activation request
* enqueued.
*/
static void
unmanaged_to_disconnected (NMDevice *device)
{
/* when creating the software device, it can happen that the device is
* still unmanaged by NM_UNMANAGED_PLATFORM_INIT because we didn't yet
* get the udev event. At this point, we can no longer delay the activation
* and force the device to be managed. */
nm_device_set_unmanaged_by_flags (device, NM_UNMANAGED_PLATFORM_INIT, FALSE, NM_DEVICE_STATE_REASON_USER_REQUESTED);
nm_device_set_unmanaged_by_flags (device, NM_UNMANAGED_USER_EXPLICIT, FALSE, NM_DEVICE_STATE_REASON_USER_REQUESTED);
core: don't require manageable device in unmanaged_to_disconnected() It seems the assert there is too strict. I don't really understand why it fails, but I also don't see why the assert is supposed to hold. Just return in case the device is unmanagable at this point. The activation shall fail later. Traceback from a test build of commit a7aca2ab08abcc5bee02f0f6f9ffe899919f4234: #0 0x00007fdb28ffb643 in g_logv (log_domain=0x7fdb2b584cc9 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff10630200) at gmessages.c:1086 #1 0x00007fdb28ffb7bf in g_log (log_domain=log_domain@entry=0x7fdb2b584cc9 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7fdb29069190 "%s: assertion '%s' failed") at gmessages.c:1119 #2 0x00007fdb28ffb7f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7fdb2b584cc9 "NetworkManager", pretty_function=pretty_function@entry=0x7fdb2b54fee0 <__func__.38922> "unmanaged_to_disconnected", expression=expression@entry=0x7fdb2b54d450 "nm_device_get_managed (device, FALSE)") at gmessages.c:1128 #3 0x00007fdb2b36e05b in unmanaged_to_disconnected (device=device@entry=0x7fdb2d2384f0 [NMDeviceVlan]) at src/nm-manager.c:3201 #4 0x00007fdb2b37eb3a in _internal_activate_generic (error=0x7fff106303d0, active=0x7fdb2d1d4550 [NMActRequest], self=0x0) at src/nm-manager.c:3430 #5 0x00007fdb2b37eb3a in _internal_activate_generic (self=self@entry=0x7fdb2d02b090 [NMManager], active=active@entry=0x7fdb2d1d4550 [NMActRequest], error=error@entry=0x7fff10630450) at src/nm-manager.c:3458 #6 0x00007fdb2b37fe90 in _activation_auth_done (active=0x7fdb2d1d4550 [NMActRequest], success=1, error_desc=0x0, user_data1=0x7fdb2d02b090, user_data2=0x7fdb0800bec0) at src/nm-manager.c:3866 #7 0x00007fdb2b4cc9d7 in auth_done (chain=0x7fdb2d17de30, error=0x0, unused=<optimized out>, user_data=<optimized out>) at src/nm-active-connection.c:929 #8 0x00007fdb2b4d6884 in auth_chain_finish (user_data=0x7fdb2d17de30) at src/nm-auth-utils.c:92 #9 0x00007fdb28ff4d7a in g_main_context_dispatch (context=0x7fdb2cff2e00) at gmain.c:3152 #10 0x00007fdb28ff4d7a in g_main_context_dispatch (context=context@entry=0x7fdb2cff2e00) at gmain.c:3767 #11 0x00007fdb28ff50b8 in g_main_context_iterate (context=0x7fdb2cff2e00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838 #12 0x00007fdb28ff538a in g_main_loop_run (loop=0x7fdb2cff2ec0) at gmain.c:4032 #13 0x00007fdb2b349ed7 in main (argc=1, argv=0x7fff106307a8) at src/main.c:438 https://bugzilla.redhat.com/show_bug.cgi?id=1478911
2017-09-04 13:11:08 +02:00
if (!nm_device_get_managed (device, FALSE)) {
/* the device is still marked as unmanaged. Nothing to do. */
return;
}
manager: separate the traversal to disconected to a separate routine Will be useful when we'll be able to defer the realization of the device.
2016-03-24 15:20:44 +01:00
if (nm_device_get_state (device) == NM_DEVICE_STATE_UNMANAGED) {
nm_device_state_changed (device,
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
NM_DEVICE_STATE_UNAVAILABLE,
NM_DEVICE_STATE_REASON_USER_REQUESTED);
manager: separate the traversal to disconected to a separate routine Will be useful when we'll be able to defer the realization of the device.
2016-03-24 15:20:44 +01:00
}
manager: reorder conditions in unmanaged_to_disconnected() to check cheaper condition first Getting nm_device_get_state() is cheap, contrary to nm_device_is_available(). Reorder the checks.
2018-02-05 15:01:48 +01:00
if ( nm_device_get_state (device) == NM_DEVICE_STATE_UNAVAILABLE
&& nm_device_is_available (device, NM_DEVICE_CHECK_DEV_AVAILABLE_FOR_USER_REQUEST)) {
manager: separate the traversal to disconected to a separate routine Will be useful when we'll be able to defer the realization of the device.
2016-03-24 15:20:44 +01:00
nm_device_state_changed (device,
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
NM_DEVICE_STATE_DISCONNECTED,
NM_DEVICE_STATE_REASON_USER_REQUESTED);
manager: separate the traversal to disconected to a separate routine Will be useful when we'll be able to defer the realization of the device.
2016-03-24 15:20:44 +01:00
}
}
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
static NMActivationStateFlags
_activation_bind_lifetime_to_profile_visibility (NMAuthSubject *subject)
{
if ( nm_auth_subject_is_internal (subject)
|| nm_auth_subject_get_unix_process_uid (subject) == 0) {
/* internal requests and requests from root are always unbound. */
return NM_ACTIVATION_STATE_FLAG_NONE;
}
/* if the activation was not done by internal decision nor root, there
* are the following cases:
*
* - the connection has "connection.permissions" unset and the profile
* is not restricted to a user and commonly always visible. It does
* not hurt to bind the lifetime, because we expect the profile to be
* visible at the moment. If the profile changes (while still being active),
* we want to pick-up changes to the visibility and possibly disconnect.
*
* - the connection has "connection.permissions" set, and the current user
* is the owner:
*
* - Usually, we would expect that the profile is visible at the moment,
* and of course we want to bind the lifetime. The moment the user
* logs out, the connection becomes invisible and disconnects.
*
* - the profile at this time could already be invisible (e.g. if the
all: fix misspellings https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/64
2019-01-11 17:07:03 -02:00
* user didn't create a proper session (sudo) and manually activates
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
* an invisible profile. In this case, we still want to bind the
* lifetime, and it will disconnect after the user logs in and logs
* out again. NMKeepAlive takes care of that.
*/
return NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY;
}
manager: allow delaying the device activation when the parent is not real Don't try to realize our device when the parent device is not real. Instead, enqueue the activation and wait until it is active before realizing our device and progressing the device to DISCONNECTED so that it can get connected.
2016-03-24 15:20:44 +01:00
/* The parent connection is ready; we can proceed realizing the device and
* progressing the device to disconencted state.
*/
static void
active_connection_parent_active (NMActiveConnection *active,
NMActiveConnection *parent_ac,
NMManager *self)
{
NMDevice *device = nm_active_connection_get_device (active);
GError *error = NULL;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn;
manager: refactor active_connection_parent_active() to return-early Replace the if-else-if construct with "if(failure) return;". It reads nicer.
2018-02-05 15:51:33 +01:00
NMDevice *parent;
manager: allow delaying the device activation when the parent is not real Don't try to realize our device when the parent device is not real. Instead, enqueue the activation and wait until it is active before realizing our device and progressing the device to DISCONNECTED so that it can get connected.
2016-03-24 15:20:44 +01:00
g_signal_handlers_disconnect_by_func (active,
(GCallback) active_connection_parent_active,
self);
manager: refactor active_connection_parent_active() to return-early Replace the if-else-if construct with "if(failure) return;". It reads nicer.
2018-02-05 15:51:33 +01:00
if (!parent_ac) {
manager: use _LOGx() macros in nm-manager They give each logging message a "manager: " prefix.
2016-04-27 18:26:39 +02:00
_LOGW (LOGD_CORE, "The parent connection device '%s' depended on disappeared.",
nm_device_get_iface (device));
core: transit to DISCONNECTING state for NMActiveConnection Don't just directly switch to DISCONNECTED state. If we are ACTIVATING or ACTIVATED, first transition to DISCONNECTING state.
2018-02-05 16:45:33 +01:00
nm_active_connection_set_state_fail (active,
NM_ACTIVE_CONNECTION_STATE_REASON_DEVICE_REMOVED,
"parent device disappeared");
manager: refactor active_connection_parent_active() to return-early Replace the if-else-if construct with "if(failure) return;". It reads nicer.
2018-02-05 15:51:33 +01:00
return;
}
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn = nm_active_connection_get_settings_connection (active);
manager: refactor active_connection_parent_active() to return-early Replace the if-else-if construct with "if(failure) return;". It reads nicer.
2018-02-05 15:51:33 +01:00
parent = nm_active_connection_get_device (parent_ac);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (!nm_device_create_and_realize (device,
nm_settings_connection_get_connection (sett_conn),
parent,
&error)) {
manager: refactor active_connection_parent_active() to return-early Replace the if-else-if construct with "if(failure) return;". It reads nicer.
2018-02-05 15:51:33 +01:00
_LOGW (LOGD_CORE, "Could not realize device '%s': %s",
nm_device_get_iface (device), error->message);
core: transit to DISCONNECTING state for NMActiveConnection Don't just directly switch to DISCONNECTED state. If we are ACTIVATING or ACTIVATED, first transition to DISCONNECTING state.
2018-02-05 16:45:33 +01:00
nm_active_connection_set_state_fail (active,
NM_ACTIVE_CONNECTION_STATE_REASON_DEVICE_REALIZE_FAILED,
"failure to realize device");
manager: refactor active_connection_parent_active() to return-early Replace the if-else-if construct with "if(failure) return;". It reads nicer.
2018-02-05 15:51:33 +01:00
return;
manager: allow delaying the device activation when the parent is not real Don't try to realize our device when the parent device is not real. Instead, enqueue the activation and wait until it is active before realizing our device and progressing the device to DISCONNECTED so that it can get connected.
2016-03-24 15:20:44 +01:00
}
manager: refactor active_connection_parent_active() to return-early Replace the if-else-if construct with "if(failure) return;". It reads nicer.
2018-02-05 15:51:33 +01:00
/* We can now proceed to disconnected state so that activation proceeds. */
unmanaged_to_disconnected (device);
manager: allow delaying the device activation when the parent is not real Don't try to realize our device when the parent device is not real. Instead, enqueue the activation and wait until it is active before realizing our device and progressing the device to DISCONNECTED so that it can get connected.
2016-03-24 15:20:44 +01:00
}
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
static gboolean
_internal_activate_device (NMManager *self, NMActiveConnection *active, GError **error)
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
{
core: rework nm_device_steal_connection() nm_device_steal_connection() was a bit misleading. It only had one caller, and what _internal_activate_device() really wants it to deactivate all other active-connections for the same connection. Hence, it already performed a lookup for the active-connection that should be disconnected, only to then lookup the device, and tell it to steal the connection. Note, that if existing_ac happens to be neither the queued nor the currenct active connection, then previously it would have done nothing. It's unclear when that exactly can happen, however, we can avoid that question entirely. Instead of having steal-connection(), have a disconnect-active-connection(). If there is no matching device, it will just set the active-connection's state to DISCONNECTED. Which in turn does nothing, if the state is already DISCONNECTED.
2018-04-22 12:13:44 +02:00
NMDevice *device, *master_device = NULL;
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
NMConnection *applied;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn;
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
NMSettingsConnection *master_connection = NULL;
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
NMConnection *existing_connection = NULL;
core: fix a crash with autoconnect masters with autoconnect slaves 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.
2014-01-28 17:24:26 -05:00
NMActiveConnection *master_ac = NULL;
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
NMAuthSubject *subject;
core: improve error message when activating profile on device Before: $ nmcli connection up my-wired ifname eth0 Error: Connection activation failed: Connection 'my-wired' is not available on the device eth0 at this time. After: $ nmcli connection up my-wired ifname eth0 Error: Connection activation failed: Connection 'my-wired' is not available on device eth0 because device has no carrier
2018-07-10 11:17:05 +02:00
GError *local = NULL;
core: implement connection.multi-connect to activate profiles multiple times Make use of the new property, and implement it. See previous commits for the reasons why. https://bugzilla.redhat.com/show_bug.cgi?id=1555012
2018-04-18 11:08:05 +02:00
NMConnectionMultiConnect multi_connect;
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
const char *parent_spec;
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
coverity: fix various warnings detected with Coverity 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>
2013-10-31 14:13:33 +01:00
g_return_val_if_fail (NM_IS_MANAGER (self), FALSE);
g_return_val_if_fail (NM_IS_ACTIVE_CONNECTION (active), FALSE);
g_return_val_if_fail (error == NULL || *error == NULL, FALSE);
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
g_assert (NM_IS_VPN_CONNECTION (active) == FALSE);
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
core: cleanup code by using nm_auth_is_subject_in_acl_set_error()
2018-04-12 09:48:16 +02:00
device = nm_active_connection_get_device (active);
g_return_val_if_fail (device != NULL, FALSE);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn = nm_active_connection_get_settings_connection (active);
nm_assert (sett_conn);
manager: automatically pick a base connection for VPNs If let callers pass "/" for the specific object, and NM will automatically pick the default device.
2009-10-16 11:52:27 -07:00
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
applied = nm_active_connection_get_applied_connection (active);
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
/* If the device is active and its connection is not visible to the
* user that's requesting this new activation, fail, since other users
* should not be allowed to implicitly deactivate private connections
* by activating a connection of their own.
*/
existing_connection = nm_device_get_applied_connection (device);
subject = nm_active_connection_get_subject (active);
core: cleanup code by using nm_auth_is_subject_in_acl_set_error()
2018-04-12 09:48:16 +02:00
if ( existing_connection
&& !nm_auth_is_subject_in_acl_set_error (existing_connection,
subject,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
error)) {
g_prefix_error (error, "Private connection already active on the device: ");
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
return FALSE;
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
}
core: rework ignore-carrier device behavior 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.
2013-11-04 19:51:28 -06:00
/* Final connection must be available on device */
core: improve error message when activating profile on device Before: $ nmcli connection up my-wired ifname eth0 Error: Connection activation failed: Connection 'my-wired' is not available on the device eth0 at this time. After: $ nmcli connection up my-wired ifname eth0 Error: Connection activation failed: Connection 'my-wired' is not available on device eth0 because device has no carrier
2018-07-10 11:17:05 +02:00
if (!nm_device_check_connection_available (device, applied, NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST, NULL, &local)) {
core: rework ignore-carrier device behavior 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.
2013-11-04 19:51:28 -06:00
g_set_error (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_UNKNOWN_CONNECTION,
core: improve error message when activating profile on device Before: $ nmcli connection up my-wired ifname eth0 Error: Connection activation failed: Connection 'my-wired' is not available on the device eth0 at this time. After: $ nmcli connection up my-wired ifname eth0 Error: Connection activation failed: Connection 'my-wired' is not available on device eth0 because device has no carrier
2018-07-10 11:17:05 +02:00
"Connection '%s' is not available on device %s because %s",
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_settings_connection_get_id (sett_conn),
core: improve error message when activating profile on device Before: $ nmcli connection up my-wired ifname eth0 Error: Connection activation failed: Connection 'my-wired' is not available on the device eth0 at this time. After: $ nmcli connection up my-wired ifname eth0 Error: Connection activation failed: Connection 'my-wired' is not available on device eth0 because device has no carrier
2018-07-10 11:17:05 +02:00
nm_device_get_iface (device),
local->message);
g_error_free (local);
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
return FALSE;
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
}
device: set device's sys-iface-state only shortly before activating device During _new_active_connection() we just create the NMActiveConnection instance to proceed with authorization. The caller might not even authorize, so we must not touch the device yet. Do that only later.
2018-04-17 07:31:13 +02:00
if (nm_active_connection_get_activation_type (active) == NM_ACTIVATION_TYPE_MANAGED)
nm_device_sys_iface_state_set (device, NM_DEVICE_SYS_IFACE_STATE_MANAGED);
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
/* Create any backing resources the device needs */
if (!nm_device_is_real (device)) {
NMDevice *parent;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
parent = find_parent_device_for_connection (self,
nm_settings_connection_get_connection (sett_conn),
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
NULL,
&parent_spec);
if (parent_spec && !parent) {
g_set_error (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_DEPENDENCY_FAILED,
"parent device '%s' not found", parent_spec);
return FALSE;
}
manager: allow delaying the device activation when the parent is not real Don't try to realize our device when the parent device is not real. Instead, enqueue the activation and wait until it is active before realizing our device and progressing the device to DISCONNECTED so that it can get connected.
2016-03-24 15:20:44 +01:00
if (parent && !nm_device_is_real (parent)) {
NMSettingsConnection *parent_con;
NMActiveConnection *parent_ac;
parent_con = nm_device_get_best_connection (parent, NULL, error);
if (!parent_con) {
g_prefix_error (error, "%s failed to create parent: ", nm_device_get_iface (device));
return FALSE;
}
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
parent_ac = nm_manager_activate_connection (self,
parent_con,
NULL,
NULL,
parent,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
subject,
NM_ACTIVATION_TYPE_MANAGED,
nm_active_connection_get_activation_reason (active),
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
nm_active_connection_get_state_flags (active)
& NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
error);
manager: allow delaying the device activation when the parent is not real Don't try to realize our device when the parent device is not real. Instead, enqueue the activation and wait until it is active before realizing our device and progressing the device to DISCONNECTED so that it can get connected.
2016-03-24 15:20:44 +01:00
if (!parent_ac) {
g_prefix_error (error, "%s failed to activate parent: ", nm_device_get_iface (device));
return FALSE;
}
/* We can't realize now; defer until the parent device is ready. */
g_signal_connect (active,
NM_ACTIVE_CONNECTION_PARENT_ACTIVE,
(GCallback) active_connection_parent_active,
self);
nm_active_connection_set_parent (active, parent_ac);
} else {
/* We can realize now; no need to wait for a parent device. */
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (!nm_device_create_and_realize (device,
nm_settings_connection_get_connection (sett_conn),
parent,
error)) {
manager: allow delaying the device activation when the parent is not real Don't try to realize our device when the parent device is not real. Instead, enqueue the activation and wait until it is active before realizing our device and progressing the device to DISCONNECTED so that it can get connected.
2016-03-24 15:20:44 +01:00
g_prefix_error (error, "%s failed to create resources: ", nm_device_get_iface (device));
return FALSE;
}
core: create devices first and realize them later 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().
2014-09-24 16:58:07 -05:00
}
}
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
/* Try to find the master connection/device if the connection has a dependency */
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (!find_master (self,
applied,
device,
&master_connection,
&master_device,
&master_ac,
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
error)) {
g_prefix_error (error, "Can not find a master for %s: ",
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_settings_connection_get_id (sett_conn));
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
return FALSE;
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
}
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
/* Ensure there's a master active connection the new connection we're
* activating can depend on.
*/
if (master_connection || master_device) {
if (master_connection) {
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGD (LOGD_CORE, "Activation of '%s' requires master connection '%s'",
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_settings_connection_get_id (sett_conn),
manager: use logging helpers
2016-03-02 11:38:26 +01:00
nm_settings_connection_get_id (master_connection));
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
}
if (master_device) {
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGD (LOGD_CORE, "Activation of '%s' requires master device '%s'",
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_settings_connection_get_id (sett_conn),
manager: use logging helpers
2016-03-02 11:38:26 +01:00
nm_device_get_ip_iface (master_device));
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
}
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
/* Ensure eg bond slave and the candidate master is a bond master */
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if ( master_connection
&& !is_compatible_with_slave (nm_settings_connection_get_connection (master_connection),
applied)) {
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
g_set_error (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_DEPENDENCY_FAILED,
"The master connection '%s' is not compatible with '%s'",
nm_settings_connection_get_id (master_connection),
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_settings_connection_get_id (sett_conn));
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
return FALSE;
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
}
if (!master_ac) {
core: fix a crash with autoconnect masters with autoconnect slaves 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.
2014-01-28 17:24:26 -05:00
master_ac = ensure_master_active_connection (self,
nm_active_connection_get_subject (active),
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
applied,
core: fix a crash with autoconnect masters with autoconnect slaves 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.
2014-01-28 17:24:26 -05:00
device,
master_connection,
master_device,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
nm_active_connection_get_activation_reason (active),
core: fix a crash with autoconnect masters with autoconnect slaves 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.
2014-01-28 17:24:26 -05:00
error);
if (!master_ac) {
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
if (master_device) {
g_prefix_error (error, "Master device '%s' can't be activated: ",
nm_device_get_ip_iface (device));
} else {
g_prefix_error (error, "Master connection '%s' can't be activated: ",
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_settings_connection_get_id (sett_conn));
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
}
core: fix a crash with autoconnect masters with autoconnect slaves 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.
2014-01-28 17:24:26 -05:00
return FALSE;
}
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
}
core: ensure master connections are available for dependence If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
2012-02-26 17:27:42 -06:00
manager: don't let a master device go unmanaged on a slave activation If a slave device activates, we should keep the master up even though it was taken over before. This fixes an issue, where a single slave to a master would be reactivated after a daemon restart. The daemon restart would cause the master to be treated externally created (would go unmanaged when all the slaves are gone) while the reactivation would leave the master without slaves for a while. (cherry picked from commit b605fb27120cf6c8ac44d4a57e3f19e5ce0f69ed)
2017-01-25 13:27:16 +01:00
/* Now that we're activating a slave for that master, make sure the master just
* decides to go unmanaged while we're activating (perhaps because other slaves
* go away leaving him with no kids).
*/
manager: guard the flag setting by the actual device presence The parent might be an active connection w/o the device being determined.
2017-01-26 14:18:20 +01:00
if (master_device) {
nm_device_set_unmanaged_by_flags (master_device, NM_UNMANAGED_EXTERNAL_DOWN,
NM_UNMAN_FLAG_OP_FORGET, NM_DEVICE_STATE_REASON_USER_REQUESTED);
}
manager: don't let a master device go unmanaged on a slave activation If a slave device activates, we should keep the master up even though it was taken over before. This fixes an issue, where a single slave to a master would be reactivated after a daemon restart. The daemon restart would cause the master to be treated externally created (would go unmanaged when all the slaves are gone) while the reactivation would leave the master without slaves for a while. (cherry picked from commit b605fb27120cf6c8ac44d4a57e3f19e5ce0f69ed)
2017-01-25 13:27:16 +01:00
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
nm_active_connection_set_master (active, master_ac);
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGD (LOGD_CORE, "Activation of '%s' depends on active connection %p %s",
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_settings_connection_get_id (sett_conn),
manager: use logging helpers
2016-03-02 11:38:26 +01:00
master_ac,
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_dbus_object_get_path (NM_DBUS_OBJECT (master_ac)) ?: "");
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
}
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
/* Check slaves for master connection and possibly activate them */
manager: propagate the for-user-request flag for slaves autoconnection If the master is activated by user, propagate the for-user-request to slaves activations when autoconnecting slaves, so that they can manage slaves device as needed. Reproducer: ip l add eth1 type veth peer name eth2 ip l set eth1 up ip l set eth2 up sleep 2 echo " * Initial state" echo " - eth1: $(nmcli -g general.state device show eth1)" nmcli con add type ethernet ifname eth1 con-name slave-test+ master br-test slave-type bridge nmcli con add type bridge ifname br-test con-name br-test+ connection.autoconnect-slaves yes ip4 172.25.1.1/24 nmcli con up br-test+ echo " * After user activation" echo " - br-test: $(nmcli -g general.state device show br-test)" echo " - eth1: $(nmcli -g general.state device show eth1)" should give: * Initial state - eth1: 10 (unmanaged) * After user activation - br-test: 100 (connected) - eth1: 100 (connected)
2019-07-02 11:51:29 +02:00
autoconnect_slaves (self, sett_conn, device, nm_active_connection_get_subject (active),
nm_active_connection_get_activation_reason (active) == NM_ACTIVATION_REASON_USER_REQUEST);
core: activate slaves when master is activated (bgo #735052) (rh #1158529) When a master connection is activated, check all its slaves and decide whether they should be activated as well. This is done according to the autoconnect-slaves property. https://bugzilla.gnome.org/show_bug.cgi?id=735052 https://bugzilla.redhat.com/show_bug.cgi?id=1158529
2015-05-06 14:38:55 +02:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
multi_connect = _nm_connection_get_multi_connect (nm_settings_connection_get_connection (sett_conn));
core: implement connection.multi-connect to activate profiles multiple times Make use of the new property, and implement it. See previous commits for the reasons why. https://bugzilla.redhat.com/show_bug.cgi?id=1555012
2018-04-18 11:08:05 +02:00
if ( multi_connect == NM_CONNECTION_MULTI_CONNECT_MULTIPLE
|| ( multi_connect == NM_CONNECTION_MULTI_CONNECT_MANUAL_MULTIPLE
&& NM_IN_SET (nm_active_connection_get_activation_reason (active),
NM_ACTIVATION_REASON_ASSUME,
NM_ACTIVATION_REASON_AUTOCONNECT_SLAVES,
NM_ACTIVATION_REASON_USER_REQUEST))) {
/* the profile can be activated multiple times. Proceed. */
} else {
manager: disconnect all conflicting concurrent active connections in _internal_activate_device() It is possible, that there are multiple such conflicting connections. Maybe not now, but with connecition cardinality it will soon be. Find and disconnect them all.
2018-04-22 14:45:40 +02:00
gs_unref_ptrarray GPtrArray *all_ac_arr = NULL;
NMActiveConnection *ac;
guint i, n_all;
/* Disconnect the connection if already connected or queued for activation.
* The connection cannot be active multiple times (at the same time). */
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
ac = active_connection_find (self, sett_conn, NULL, NM_ACTIVE_CONNECTION_STATE_ACTIVATED,
manager: disconnect all conflicting concurrent active connections in _internal_activate_device() It is possible, that there are multiple such conflicting connections. Maybe not now, but with connecition cardinality it will soon be. Find and disconnect them all.
2018-04-22 14:45:40 +02:00
&all_ac_arr);
if (ac) {
n_all = all_ac_arr ? all_ac_arr->len : ((guint) 1);
for (i = 0; i < n_all; i++) {
nm_device_disconnect_active_connection ( all_ac_arr
? all_ac_arr->pdata[i]
device: add state-change reason argument to nm_device_disconnect_active_connection() nm_device_disconnect_active_connection() is generally useful and a prefered form to fail an active connection. The device's state-change reason is important, so it needs to be injected.
2018-11-20 14:18:01 +01:00
: ac,
device: pass active-connection's state-change reason to nm_device_disconnect_active_connection() No change in behavior, yet.
2018-11-20 14:25:42 +01:00
NM_DEVICE_STATE_REASON_NEW_ACTIVATION,
NM_ACTIVE_CONNECTION_STATE_REASON_UNKNOWN);
manager: disconnect all conflicting concurrent active connections in _internal_activate_device() It is possible, that there are multiple such conflicting connections. Maybe not now, but with connecition cardinality it will soon be. Find and disconnect them all.
2018-04-22 14:45:40 +02:00
}
}
}
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
manager: allow delaying the device activation when the parent is not real Don't try to realize our device when the parent device is not real. Instead, enqueue the activation and wait until it is active before realizing our device and progressing the device to DISCONNECTED so that it can get connected.
2016-03-24 15:20:44 +01:00
/* If the device is there, we can ready it for the activation. */
manager: abort activation if the device is still unmanaged unmanaged_to_disconnected() is supposed to mark the device as managed. However, it may easily be unable to do so, for example if the device is unmanaged by NM_UNMANAGED_USER_SETTINGS. Shortly before actually enqueuing the activation request, check and error out. Otherwise, we might hit an assertion later in _device_activate().
2018-02-05 15:06:24 +01:00
if (nm_device_is_real (device)) {
manager: allow delaying the device activation when the parent is not real Don't try to realize our device when the parent device is not real. Instead, enqueue the activation and wait until it is active before realizing our device and progressing the device to DISCONNECTED so that it can get connected.
2016-03-24 15:20:44 +01:00
unmanaged_to_disconnected (device);
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
manager: abort activation if the device is still unmanaged unmanaged_to_disconnected() is supposed to mark the device as managed. However, it may easily be unable to do so, for example if the device is unmanaged by NM_UNMANAGED_USER_SETTINGS. Shortly before actually enqueuing the activation request, check and error out. Otherwise, we might hit an assertion later in _device_activate().
2018-02-05 15:06:24 +01:00
if (!nm_device_get_managed (device, FALSE)) {
/* Unexpectedly, the device is still unmanaged. That can happen for example,
* if the device is forcibly unmanaged due to NM_UNMANAGED_USER_SETTINGS. */
g_set_error_literal (error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_DEPENDENCY_FAILED,
"Activation failed because the device is unmanaged");
return FALSE;
}
}
core: export ActiveConnection before handing it to the device (bgo #723783) The AC doesn't get a D-Bus path until it's exported, but that happens after it's handed to the Device it will be activated on. The Device emits a PropertyChanged event when it's handed the AC, but it ignores ACs that aren't exported yet. Thus when activating, the Device doesn't emit the AC's path at all in the ActiveConnection property because it's NULL. Fix that by exporting the AC immediately before starting activation with it. Second, move the notification of the Device.ActiveConnection property to be emitted along with the state change to PREPARE instead of long before it. While we don't guarantee signal ordering in general, this seems like a more correct ordering. https://bugzilla.gnome.org/show_bug.cgi?id=723783
2014-03-20 11:22:19 -05:00
/* Export the new ActiveConnection to clients and start it on the device */
manager: reorder adding active-connection and queueing activation Note how recheck_assume_connection() called: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); active_connection_add (self, active); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); That differs from the order during _internal_activate_generic(), where we would end up with: nm_exported_object_export (NM_EXPORTED_OBJECT (active)); nm_device_queue_activation (device, NM_ACT_REQUEST (active)); active_connection_add (self, active); It makes more sense to me to *first* add the connection, and only then starting the activation with nm_device_queue_activation(). Also, let active_connection_add() always export the new active connection object, if it is not already exported. All callers of active_connection_add() ensured that the new object is already exported.
2018-02-05 15:17:06 +01:00
active_connection_add (self, active);
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
nm_device_queue_activation (device, NM_ACT_REQUEST (active));
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
return TRUE;
}
static gboolean
_internal_activate_generic (NMManager *self, NMActiveConnection *active, GError **error)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
gboolean success = FALSE;
core: correctly handle pre-activation dependency failure (rh #1069695) Dependencies may fail before the activation actually starts, like when a software device gets removed while the activation is scheduled but before it has started. In these cases, the activation request should fail.
2014-02-26 13:18:16 -06:00
/* Ensure activation request is still valid, eg that its device hasn't gone
* away or that some other dependency has not failed.
*/
if (nm_active_connection_get_state (active) >= NM_ACTIVE_CONNECTION_STATE_DEACTIVATING) {
g_set_error_literal (error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_DEPENDENCY_FAILED,
"Activation failed because dependencies failed.");
return FALSE;
}
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
if (NM_IS_VPN_CONNECTION (active))
success = _internal_activate_vpn (self, active, error);
else
success = _internal_activate_device (self, active, error);
if (success) {
/* Force an update of the Manager's activating-connection property.
* The device changes state before the AC gets exported, which causes
* the manager's 'activating-connection' property to be NULL since the
* AC only gets a D-Bus path when it's exported. So now that the AC
* is exported, make sure the manager's activating-connection property
* is up-to-date.
*/
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
policy_activating_ac_changed (G_OBJECT (priv->policy), NULL, self);
core: export new active connection from the manager 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.
2013-04-22 13:29:36 -05:00
}
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
return success;
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
}
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
static NMActiveConnection *
_new_active_connection (NMManager *self,
manager: add is-vpn argument to _new_active_connection() and avoid searching existing activations - pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection() would re-determine whether a connection is a VPN type, although that was already established previously. The confusing part is: will they come to the same result? Why? What if not? Instead pass it as argument and assert that we got it right. - the check for existing connections should look whether there is an existing active connection of type NMVpnConnection. Instead, what matters is, - do we have a connection of type VPN (otherwise, don't even bother to search for existing-ac) - is the connection already active? Checking whether the connection is already active, and ask backwards whether it's of type NMVpnConnection is odd, maybe even wrong in some cases.
2018-04-12 11:32:18 +02:00
gboolean is_vpn,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
NMConnection *incompl_conn,
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
NMConnection *applied,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
const char *specific_object,
NMDevice *device,
NMAuthSubject *subject,
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
NMActivationType activation_type,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
NMActivationReason activation_reason,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
NMActivationStateFlags initial_state_flags,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
GError **error)
{
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
manager: fix assertions when activating VPNs _new_active_connection() can be called with both a device and a specific object set when activating secondaries. Fixes: 10753c36168a82cd658df8a7da800960fddd78ed
2018-04-19 15:30:31 +02:00
NMDevice *parent_device;
core: don't allow activating the same connection twice (rh #997998) Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
2013-09-12 10:28:21 -04:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_assert (!sett_conn || NM_IS_SETTINGS_CONNECTION (sett_conn));
nm_assert (!incompl_conn || NM_IS_CONNECTION (incompl_conn));
nm_assert ((!incompl_conn) ^ (!sett_conn));
nm_assert (NM_IS_AUTH_SUBJECT (subject));
nm_assert (is_vpn == _connection_is_vpn (sett_conn
? nm_settings_connection_get_connection (sett_conn)
: incompl_conn));
manager: fix assertions when activating VPNs _new_active_connection() can be called with both a device and a specific object set when activating secondaries. Fixes: 10753c36168a82cd658df8a7da800960fddd78ed
2018-04-19 15:30:31 +02:00
nm_assert (is_vpn || NM_IS_DEVICE (device));
manager: ensure valid specific_object path is passed to _new_active_connection() From the D-Bus layer, no specific-object is represented by "/". We should early on normalize such values to NULL, and not expect or handle them later (like during _new_active_connection()).
2018-04-12 14:02:39 +02:00
nm_assert (!nm_streq0 (specific_object, "/"));
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_assert (!applied || NM_IS_CONNECTION (applied));
nm_assert (!is_vpn || !applied);
manager: ensure valid specific_object path is passed to _new_active_connection() From the D-Bus layer, no specific-object is represented by "/". We should early on normalize such values to NULL, and not expect or handle them later (like during _new_active_connection()).
2018-04-12 14:02:39 +02:00
manager: add is-vpn argument to _new_active_connection() and avoid searching existing activations - pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection() would re-determine whether a connection is a VPN type, although that was already established previously. The confusing part is: will they come to the same result? Why? What if not? Instead pass it as argument and assert that we got it right. - the check for existing connections should look whether there is an existing active connection of type NMVpnConnection. Instead, what matters is, - do we have a connection of type VPN (otherwise, don't even bother to search for existing-ac) - is the connection already active? Checking whether the connection is already active, and ask backwards whether it's of type NMVpnConnection is odd, maybe even wrong in some cases.
2018-04-12 11:32:18 +02:00
if (is_vpn) {
manager: ensure valid specific_object path is passed to _new_active_connection() From the D-Bus layer, no specific-object is represented by "/". We should early on normalize such values to NULL, and not expect or handle them later (like during _new_active_connection()).
2018-04-12 14:02:39 +02:00
NMActiveConnection *parent;
manager: add is-vpn argument to _new_active_connection() and avoid searching existing activations - pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection() would re-determine whether a connection is a VPN type, although that was already established previously. The confusing part is: will they come to the same result? Why? What if not? Instead pass it as argument and assert that we got it right. - the check for existing connections should look whether there is an existing active connection of type NMVpnConnection. Instead, what matters is, - do we have a connection of type VPN (otherwise, don't even bother to search for existing-ac) - is the connection already active? Checking whether the connection is already active, and ask backwards whether it's of type NMVpnConnection is odd, maybe even wrong in some cases.
2018-04-12 11:32:18 +02:00
/* FIXME: for VPN connections, we don't allow re-activating an
* already active connection. It's a bug, and should be fixed together
* when reworking VPN handling. */
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (active_connection_find_by_connection (self,
sett_conn,
incompl_conn,
NM_ACTIVE_CONNECTION_STATE_ACTIVATED,
NULL)) {
manager: add is-vpn argument to _new_active_connection() and avoid searching existing activations - pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection() would re-determine whether a connection is a VPN type, although that was already established previously. The confusing part is: will they come to the same result? Why? What if not? Instead pass it as argument and assert that we got it right. - the check for existing connections should look whether there is an existing active connection of type NMVpnConnection. Instead, what matters is, - do we have a connection of type VPN (otherwise, don't even bother to search for existing-ac) - is the connection already active? Checking whether the connection is already active, and ask backwards whether it's of type NMVpnConnection is odd, maybe even wrong in some cases.
2018-04-12 11:32:18 +02:00
g_set_error (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_CONNECTION_ALREADY_ACTIVE,
"Connection '%s' is already active",
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn ? nm_settings_connection_get_id (sett_conn) : nm_connection_get_id (incompl_conn));
manager: add is-vpn argument to _new_active_connection() and avoid searching existing activations - pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection() would re-determine whether a connection is a VPN type, although that was already established previously. The confusing part is: will they come to the same result? Why? What if not? Instead pass it as argument and assert that we got it right. - the check for existing connections should look whether there is an existing active connection of type NMVpnConnection. Instead, what matters is, - do we have a connection of type VPN (otherwise, don't even bother to search for existing-ac) - is the connection already active? Checking whether the connection is already active, and ask backwards whether it's of type NMVpnConnection is odd, maybe even wrong in some cases.
2018-04-12 11:32:18 +02:00
return NULL;
}
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
if (activation_type != NM_ACTIVATION_TYPE_MANAGED)
g_return_val_if_reached (NULL);
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
if (specific_object) {
/* Find the specific connection the client requested we use */
parent = active_connection_get_by_path (self, specific_object);
if (!parent) {
g_set_error_literal (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_CONNECTION_NOT_ACTIVE,
"Base connection for VPN connection not active.");
return NULL;
}
} else
parent = priv->primary_connection;
if (!parent) {
g_set_error_literal (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_UNKNOWN_CONNECTION,
"Could not find source connection.");
return NULL;
}
manager: fix assertions when activating VPNs _new_active_connection() can be called with both a device and a specific object set when activating secondaries. Fixes: 10753c36168a82cd658df8a7da800960fddd78ed
2018-04-19 15:30:31 +02:00
parent_device = nm_active_connection_get_device (parent);
if (!parent_device) {
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
g_set_error_literal (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_UNKNOWN_DEVICE,
"Source connection had no active device");
return NULL;
}
manager: fix assertions when activating VPNs _new_active_connection() can be called with both a device and a specific object set when activating secondaries. Fixes: 10753c36168a82cd658df8a7da800960fddd78ed
2018-04-19 15:30:31 +02:00
if (device && device != parent_device) {
g_set_error_literal (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_UNKNOWN_DEVICE,
"The device doesn't match the active connection.");
return NULL;
}
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
return (NMActiveConnection *) nm_vpn_connection_new (sett_conn,
manager: fix assertions when activating VPNs _new_active_connection() can be called with both a device and a specific object set when activating secondaries. Fixes: 10753c36168a82cd658df8a7da800960fddd78ed
2018-04-19 15:30:31 +02:00
parent_device,
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
nm_dbus_object_get_path (NM_DBUS_OBJECT (parent)),
activation_reason,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
initial_state_flags,
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
subject);
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
}
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
return (NMActiveConnection *) nm_act_request_new (sett_conn,
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
applied,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
specific_object,
subject,
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
activation_type,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
activation_reason,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
initial_state_flags,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
device);
}
static void
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
_internal_activation_auth_done (NMManager *self,
NMActiveConnection *active,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
gboolean success,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
const char *error_desc)
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
{
manager: reuse an active connection, if the same activation is pending When a master & slaves get activated at the same time, they all submit separate active connections which race for the device after activation.
2015-06-23 20:52:04 +02:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
NMActiveConnection *ac;
gs_free_error GError *error = NULL;
core: more flattening of PendingActivation objects 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.
2012-09-13 16:51:58 -05:00
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
nm_assert (NM_IS_ACTIVE_CONNECTION (active));
manager: reuse an active connection, if the same activation is pending When a master & slaves get activated at the same time, they all submit separate active connections which race for the device after activation.
2015-06-23 20:52:04 +02:00
manager: some refactoring of error paths to return early Often, functions perform a series of steps, and when they fail, they bail out. It's simpler if the code is structured that way, so you can read it from top to bottom and whenever something is wrong, either return directly (or goto a cleanup label at the bottom).
2018-04-12 15:40:32 +02:00
if (!success)
goto fail;
core: only abort conflicting activations for certain activation types There are various places where we do an internal activation (with an internal auth-subject). In several of these places, the ACTIVATION_REASON is USER_REQUEST. I think it is wrong to generally abort all internal activations, except AUTOCONNECT_SLAVES ones. I think, aborting an activation should be opt-in instead of opt-out. To me it seems, we want to abort the activation based on the activation reason. For now, opt-in to EXTERNAL, ASSUME and AUTOCONNECT only. If there are additional cases where we should abort activation, we should add yet another reason and not use USER_REQUEST.
2018-04-19 13:28:38 +02:00
/* Don't continue with an autoconnect-activation if a more important activation
* already exists.
* We also check this earlier, but there we may fail to detect a duplicate
* if the existing active connection was undergoing authorization.
manager: avoid that auto-activations preempt user activations In _internal_activate_device(), we try to find an existing master AC for the slave AC, and we create a new one in case of failure. The master AC may already exist, but it may not be detected by find_master() because it is undergoing authorization. The result is that we auto-activate the master when there is already a user activation in place, and the auto-activation will cancel the user one. This is bad, as user-activation should always have precedence. To fix this, introduce a last-minute check before activating internal connections. https://bugzilla.redhat.com/show_bug.cgi?id=1450219
2017-06-16 10:59:35 +02:00
*/
core: only abort conflicting activations for certain activation types There are various places where we do an internal activation (with an internal auth-subject). In several of these places, the ACTIVATION_REASON is USER_REQUEST. I think it is wrong to generally abort all internal activations, except AUTOCONNECT_SLAVES ones. I think, aborting an activation should be opt-in instead of opt-out. To me it seems, we want to abort the activation based on the activation reason. For now, opt-in to EXTERNAL, ASSUME and AUTOCONNECT only. If there are additional cases where we should abort activation, we should add yet another reason and not use USER_REQUEST.
2018-04-19 13:28:38 +02:00
if (NM_IN_SET (nm_active_connection_get_activation_reason (active), NM_ACTIVATION_REASON_EXTERNAL,
NM_ACTIVATION_REASON_ASSUME,
NM_ACTIVATION_REASON_AUTOCONNECT)) {
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
c_list_for_each_entry (ac, &priv->active_connections_lst_head, active_connections_lst) {
if ( nm_active_connection_get_device (ac) == nm_active_connection_get_device (active)
&& nm_active_connection_get_settings_connection (ac) == nm_active_connection_get_settings_connection (active)
manager: relax condition when checking for duplicate ACs An active connection started by user could be queued in state UNKNOWN which means the device hasn't started activating yet. Eventually it will, and we don't want to cancel the user activation because of an internal autoconnection attempt.
2019-05-13 14:30:48 +02:00
&& nm_active_connection_get_state (ac) <= NM_ACTIVE_CONNECTION_STATE_ACTIVATED) {
manager: avoid that auto-activations preempt user activations In _internal_activate_device(), we try to find an existing master AC for the slave AC, and we create a new one in case of failure. The master AC may already exist, but it may not be detected by find_master() because it is undergoing authorization. The result is that we auto-activate the master when there is already a user activation in place, and the auto-activation will cancel the user one. This is bad, as user-activation should always have precedence. To fix this, introduce a last-minute check before activating internal connections. https://bugzilla.redhat.com/show_bug.cgi?id=1450219
2017-06-16 10:59:35 +02:00
g_set_error (&error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_CONNECTION_ALREADY_ACTIVE,
"Connection '%s' is already active",
nm_active_connection_get_settings_connection_id (active));
manager: some refactoring of error paths to return early Often, functions perform a series of steps, and when they fail, they bail out. It's simpler if the code is structured that way, so you can read it from top to bottom and whenever something is wrong, either return directly (or goto a cleanup label at the bottom).
2018-04-12 15:40:32 +02:00
goto fail;
manager: avoid that auto-activations preempt user activations In _internal_activate_device(), we try to find an existing master AC for the slave AC, and we create a new one in case of failure. The master AC may already exist, but it may not be detected by find_master() because it is undergoing authorization. The result is that we auto-activate the master when there is already a user activation in place, and the auto-activation will cancel the user one. This is bad, as user-activation should always have precedence. To fix this, introduce a last-minute check before activating internal connections. https://bugzilla.redhat.com/show_bug.cgi?id=1450219
2017-06-16 10:59:35 +02:00
}
}
}
manager: some refactoring of error paths to return early Often, functions perform a series of steps, and when they fail, they bail out. It's simpler if the code is structured that way, so you can read it from top to bottom and whenever something is wrong, either return directly (or goto a cleanup label at the bottom).
2018-04-12 15:40:32 +02:00
if (_internal_activate_generic (self, active, &error))
return;
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
manager: some refactoring of error paths to return early Often, functions perform a series of steps, and when they fail, they bail out. It's simpler if the code is structured that way, so you can read it from top to bottom and whenever something is wrong, either return directly (or goto a cleanup label at the bottom).
2018-04-12 15:40:32 +02:00
fail:
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
nm_assert (error_desc || error);
manager: use nm_active_connection_set_state_fail() instead of _internal_activation_failed() There is a small change in behavior: Previously, the DEACTIVATING/DEACTIVATED states were set if and only if the previous state was less or equal then ACTIVATED. For example, if the state was already DEACTIVATING, it would have done nothing. Now, nm_active_connection_set_state_fail() transitions the states depending on the previous state. E.g. it would only set DEACTIVATING state, if the previous state was ACTIVATING/ACTIVATED. On the other hand, it would always progress the state to DEACTIVATED. The new behavior makes more sense to me, although I doubt that there is a visible difference.
2018-02-05 16:41:10 +01:00
nm_active_connection_set_state_fail (active,
NM_ACTIVE_CONNECTION_STATE_REASON_UNKNOWN,
error_desc ?: error->message);
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
}
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
/**
* nm_manager_activate_connection():
* @self: the #NMManager
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
* @sett_conn: the #NMSettingsConnection to activate on @device
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
* @applied: (allow-none): the applied connection to activate on @device
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
* @specific_object: the specific object path, if any, for the activation
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
* @device: the #NMDevice to activate @sett_conn on. Can be %NULL for VPNs.
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
* @subject: the subject which requested activation
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
* @activation_type: whether to assume the connection. That is, take over gracefully,
* non-destructible.
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
* @activation_reason: the reason for activation
all: fix misspellings https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/64
2019-01-11 17:07:03 -02:00
* @initial_state_flags: the initial state flags for the activation.
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
* @error: return location for an error
*
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
* Begins a new internally-initiated activation of @sett_conn on @device.
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
* @subject should be the subject of the activation that triggered this
* one, or if this is an autoconnect request, a new internal subject.
* The returned #NMActiveConnection is owned by the Manager and should be
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
* referenced by the caller if the caller continues to use it. If @applied
* is supplied, it shall not be modified by the caller afterwards.
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
*
* Returns: (transfer none): the new #NMActiveConnection that tracks
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
* activation of @sett_conn on @device
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
*/
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
NMActiveConnection *
nm_manager_activate_connection (NMManager *self,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
NMConnection *applied,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
const char *specific_object,
NMDevice *device,
NMAuthSubject *subject,
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
NMActivationType activation_type,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
NMActivationReason activation_reason,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
NMActivationStateFlags initial_state_flags,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
GError **error)
{
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
NMManagerPrivate *priv;
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
NMActiveConnection *active;
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
AsyncOpData *async_op_data;
manager: fix assertion in nm_manager_activate_connection() nm_manager_activate_connection() should not require a device to be passed in for VPN connections because when the argument is NULL the actual device will be determined by _new_active_connection(). Fixes: 10753c36168a82cd658df8a7da800960fddd78ed https://bugzilla.redhat.com/show_bug.cgi?id=1570545 https://github.com/NetworkManager/NetworkManager/pull/109
2018-04-30 09:50:04 +02:00
gboolean is_vpn;
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
g_return_val_if_fail (NM_IS_MANAGER (self), NULL);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
g_return_val_if_fail (NM_IS_SETTINGS_CONNECTION (sett_conn), NULL);
is_vpn = _connection_is_vpn (nm_settings_connection_get_connection (sett_conn));
manager: fix assertion in nm_manager_activate_connection() nm_manager_activate_connection() should not require a device to be passed in for VPN connections because when the argument is NULL the actual device will be determined by _new_active_connection(). Fixes: 10753c36168a82cd658df8a7da800960fddd78ed https://bugzilla.redhat.com/show_bug.cgi?id=1570545 https://github.com/NetworkManager/NetworkManager/pull/109
2018-04-30 09:50:04 +02:00
g_return_val_if_fail (is_vpn || NM_IS_DEVICE (device), NULL);
core: cleanup code by using nm_auth_is_subject_in_acl_set_error()
2018-04-12 09:48:16 +02:00
g_return_val_if_fail (!error || !*error, NULL);
manager: ensure valid specific_object path is passed to _new_active_connection() From the D-Bus layer, no specific-object is represented by "/". We should early on normalize such values to NULL, and not expect or handle them later (like during _new_active_connection()).
2018-04-12 14:02:39 +02:00
nm_assert (!nm_streq0 (specific_object, "/"));
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
priv = NM_MANAGER_GET_PRIVATE (self);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (!nm_auth_is_subject_in_acl_set_error (nm_settings_connection_get_connection (sett_conn),
core: cleanup code by using nm_auth_is_subject_in_acl_set_error()
2018-04-12 09:48:16 +02:00
subject,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
error))
core: respect connection permissions for internal activation requests 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.
2014-01-21 13:41:18 -06:00
return NULL;
manager: reuse an active connection, if the same activation is pending When a master & slaves get activated at the same time, they all submit separate active connections which race for the device after activation.
2015-06-23 20:52:04 +02:00
/* Look for a active connection that's equivalent and is already pending authorization
* and eventual activation. This is used to de-duplicate concurrent activations which would
* otherwise race and cause the device to disconnect and reconnect repeatedly.
* In particular, this allows the master and multiple slaves to concurrently auto-activate
* while all the slaves would use the same active-connection. */
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
c_list_for_each_entry (async_op_data, &priv->async_op_lst_head, async_op_lst) {
manager: reuse an active connection, if the same activation is pending When a master & slaves get activated at the same time, they all submit separate active connections which race for the device after activation.
2015-06-23 20:52:04 +02:00
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
if (async_op_data->async_op_type != ASYNC_OP_TYPE_AC_AUTH_ACTIVATE_INTERNAL)
continue;
active = async_op_data->ac_auth.active;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if ( sett_conn == nm_active_connection_get_settings_connection (active)
manager: ensure valid specific_object path is passed to _new_active_connection() From the D-Bus layer, no specific-object is represented by "/". We should early on normalize such values to NULL, and not expect or handle them later (like during _new_active_connection()).
2018-04-12 14:02:39 +02:00
&& nm_streq0 (nm_active_connection_get_specific_object (active), specific_object)
manager: fix assertion in nm_manager_activate_connection() nm_manager_activate_connection() should not require a device to be passed in for VPN connections because when the argument is NULL the actual device will be determined by _new_active_connection(). Fixes: 10753c36168a82cd658df8a7da800960fddd78ed https://bugzilla.redhat.com/show_bug.cgi?id=1570545 https://github.com/NetworkManager/NetworkManager/pull/109
2018-04-30 09:50:04 +02:00
&& (!device || nm_active_connection_get_device (active) == device)
manager: reuse an active connection, if the same activation is pending When a master & slaves get activated at the same time, they all submit separate active connections which race for the device after activation.
2015-06-23 20:52:04 +02:00
&& nm_auth_subject_is_internal (nm_active_connection_get_subject (active))
manager: don't coalesce duplicate internal activations with different reasons When combining internal activations, do that only if their reason also matches. Fixes: 4985ca5ada9b9c24118b57c3288c5aa37c38ab81
2018-04-12 15:47:40 +02:00
&& nm_auth_subject_is_internal (subject)
&& nm_active_connection_get_activation_reason (active) == activation_reason)
manager: reuse an active connection, if the same activation is pending When a master & slaves get activated at the same time, they all submit separate active connections which race for the device after activation.
2015-06-23 20:52:04 +02:00
return active;
}
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
active = _new_active_connection (self,
manager: fix assertion in nm_manager_activate_connection() nm_manager_activate_connection() should not require a device to be passed in for VPN connections because when the argument is NULL the actual device will be determined by _new_active_connection(). Fixes: 10753c36168a82cd658df8a7da800960fddd78ed https://bugzilla.redhat.com/show_bug.cgi?id=1570545 https://github.com/NetworkManager/NetworkManager/pull/109
2018-04-30 09:50:04 +02:00
is_vpn,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn,
NULL,
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
applied,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
specific_object,
device,
subject,
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
activation_type,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
activation_reason,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
initial_state_flags,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
error);
manager: some refactoring of error paths to return early Often, functions perform a series of steps, and when they fail, they bail out. It's simpler if the code is structured that way, so you can read it from top to bottom and whenever something is wrong, either return directly (or goto a cleanup label at the bottom).
2018-04-12 15:40:32 +02:00
if (!active)
return NULL;
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
nm_active_connection_authorize (active,
NULL,
_async_op_complete_ac_auth_cb,
_async_op_data_new_authorize_activate_internal (self,
active));
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
return active;
2007-09-28 Tambet Ingo <tambet@gmail.com> * src/nm-manager.c: * src/nm-manager.h: Implement device activation through NMManager. Implement "pending device activation" here - If the connection isn't found, we try to wait for up to 5 seconds for the connection to be provided. Add NMConnectionType argument to "connection-added" and "connection-removed" signals. (nm_manager_get): Remove. Finally. * src/nm-activation-request.c: * src/nm-activation-request.h: Remove all the deferred activation code. * src/nm-device.c: Remove all the deferred activation code. Once * the device activation is started, it's started. Update the activation virtual function signature. * src/nm-device-interface.c: * src/nm-device-interface.h: Device activation now takes only NMActRequest argument. Don't expose device activation directly on dbus, it's supposed to go through NMManager now. * src/NetworkManagerPolicy.c (nm_policy_device_change_check): * Make the code a bit more compact. Use the new device activation methods through NMManager. * introspection/nm-manager-client.xml: * introspection/nm-manager.xml: * libnm-glib/nm-client.c: * libnm-glib/nm-client.h: Add device activation method. * libnm-glib/nm-device.c: * libnm-glib/nm-device.h: * introspection/nm-device.xml: Remove device activation method. It's done through NMManager now. * src/vpn-manager/nm-vpn-manager.c (impl_vpn_manager_connect): * Use the shiny new (nm_manager_get_device_by_path) function, get rid of our own )find_device). git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2915 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-10-01 15:38:39 +00:00
}
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
/**
* validate_activation_request:
* @self: the #NMManager
* @context: the D-Bus context of the requestor
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
* @sett_conn: the #NMSettingsConnection to be activated, or %NULL if there
* is only a partial activation.
* @connection: the partial #NMConnection to be activated (if @sett_conn is unspecified)
core: use nm_utils_dbus_normalize_object_path() to cleanup D-Bus argument
2018-04-11 17:05:00 +02:00
* @device_path: the object path of the device to be activated, or NULL
docs: misc. typos pt2 Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
2018-09-15 07:20:54 -04:00
* @out_device: on successful return, the #NMDevice to be activated with @connection
core: cleanup NMManager's validate_activation_request() - there are only two callers of validate_activation_request(). One of them, might already lookup the device before calling the validate function. Safe to looking up again. But this is not only an optimization, more importantly, it feels odd to first lookup a device, and then later look it up again. Are we guaranteed to use the same path? Why? Just avoid that question. - re-order some error checking for missing device, so that it is clearer. - use cleanup attribute to handle return value and drop the "goto error".
2018-04-12 10:34:11 +02:00
* The caller may pass in a device which shortcuts the lookup by path.
* In this case, the passed in device must have the matching @device_path
* already.
manager/trivial: rename boolean variable "vpn" to "is_vpn"
2018-04-12 11:15:42 +02:00
* @out_is_vpn: on successful return, %TRUE if @connection is a VPN connection
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
* @error: location to store an error on failure
*
* Performs basic validation on an activation request, including ensuring that
* the requestor is a valid Unix process, is not disallowed in @connection
* permissions, and that a device exists that can activate @connection.
*
* Returns: on success, the #NMAuthSubject representing the requestor, or
* %NULL on error
*/
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
static NMAuthSubject *
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
validate_activation_request (NMManager *self,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn,
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
NMConnection *connection,
const char *device_path,
NMDevice **out_device,
manager/trivial: rename boolean variable "vpn" to "is_vpn"
2018-04-12 11:15:42 +02:00
gboolean *out_is_vpn,
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
GError **error)
{
NMDevice *device = NULL;
manager/trivial: rename boolean variable "vpn" to "is_vpn"
2018-04-12 11:15:42 +02:00
gboolean is_vpn = FALSE;
manager: fix auth-subject cleanup Fixes: bac7a2821f3a52107f5c5dc447f337fdc56e3233
2018-04-19 11:52:19 +02:00
gs_unref_object NMAuthSubject *subject = NULL;
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_assert (!sett_conn || NM_IS_SETTINGS_CONNECTION (sett_conn));
nm_assert (!connection || NM_IS_CONNECTION (connection));
nm_assert (sett_conn || connection);
nm_assert (!connection || !sett_conn || connection == nm_settings_connection_get_connection (sett_conn));
core: downgrade assertion to nm_assert() It can be easily verified, that these assertions should not ever fail. Disable in production builds.
2018-04-11 17:35:23 +02:00
nm_assert (out_device);
manager/trivial: rename boolean variable "vpn" to "is_vpn"
2018-04-12 11:15:42 +02:00
nm_assert (out_is_vpn);
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (!connection)
connection = nm_settings_connection_get_connection (sett_conn);
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
/* Validate the caller */
auth: rework polkit autorization to use DBUS interface directly This makes NetworkManager independent of <polkit/polkit.h> development headers and libpolkit-gobject-1.so library. Instead communicate directly with polkit using its DBUS interface. PolicyKit support is now always compiled in. You can control polkit authorization with the configuration option [main] auth-polkit=yes|no If the configure option is omitted, a build time default value is used. This default value can be set with the configure option --enable-polkit. This commit adds a new class NMAuthManager that reimplements the relevant DBUS client parts. It takes source code from the polkit library. https://bugzilla.gnome.org/show_bug.cgi?id=734146 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-14 13:34:57 +02:00
subject = nm_auth_subject_new_unix_process_from_context (context);
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
if (!subject) {
core: more flattening of PendingActivation objects 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.
2012-09-13 16:51:58 -05:00
g_set_error_literal (error,
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_UID_UKNOWN);
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
return NULL;
core: more flattening of PendingActivation objects 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.
2012-09-13 16:51:58 -05:00
}
core: cleanup code by using nm_auth_is_subject_in_acl_set_error()
2018-04-12 09:48:16 +02:00
if (!nm_auth_is_subject_in_acl_set_error (connection,
subject,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
error))
core: cleanup NMManager's validate_activation_request() - there are only two callers of validate_activation_request(). One of them, might already lookup the device before calling the validate function. Safe to looking up again. But this is not only an optimization, more importantly, it feels odd to first lookup a device, and then later look it up again. Are we guaranteed to use the same path? Why? Just avoid that question. - re-order some error checking for missing device, so that it is clearer. - use cleanup attribute to handle return value and drop the "goto error".
2018-04-12 10:34:11 +02:00
return NULL;
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
manager: add _connection_is_vpn() helper to unify checks for VPN type
2018-04-12 11:19:06 +02:00
is_vpn = _connection_is_vpn (connection);
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
core: cleanup NMManager's validate_activation_request() - there are only two callers of validate_activation_request(). One of them, might already lookup the device before calling the validate function. Safe to looking up again. But this is not only an optimization, more importantly, it feels odd to first lookup a device, and then later look it up again. Are we guaranteed to use the same path? Why? Just avoid that question. - re-order some error checking for missing device, so that it is clearer. - use cleanup attribute to handle return value and drop the "goto error".
2018-04-12 10:34:11 +02:00
if (*out_device) {
device = *out_device;
nm_assert (NM_IS_DEVICE (device));
nm_assert (device_path);
nm_assert (nm_streq0 (device_path, nm_dbus_object_get_path (NM_DBUS_OBJECT (device))));
nm_assert (device == nm_manager_get_device_by_path (self, device_path));
} else if (device_path) {
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
device = nm_manager_get_device_by_path (self, device_path);
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
if (!device) {
g_set_error_literal (error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_UNKNOWN_DEVICE,
"Device not found");
core: cleanup NMManager's validate_activation_request() - there are only two callers of validate_activation_request(). One of them, might already lookup the device before calling the validate function. Safe to looking up again. But this is not only an optimization, more importantly, it feels odd to first lookup a device, and then later look it up again. Are we guaranteed to use the same path? Why? Just avoid that question. - re-order some error checking for missing device, so that it is clearer. - use cleanup attribute to handle return value and drop the "goto error".
2018-04-12 10:34:11 +02:00
return NULL;
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
}
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
} else if (!is_vpn) {
core: improve error message when activating profile Before: $ nmcli connection up my-wired Error: Connection activation failed: No suitable device found for this connection. After: $ nmcli connection up my-wired Error: Connection activation failed: No suitable device found for this connection (device eth0 not available because device has no carrier). This relies on nm_manager_get_best_device_for_connection() giving a suitable error. That is however a bit complicated, because if no suitable device is found, it's not immediately clear what is the exact reason. E.g. if you try to activate a Wi-Fi profile, the failure reason "SSID is not visible" is better than "Wi-Fi profile cannot activate on ethernet device". This is controlled by carefully setting the failure codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_* to indicate an absolute relevance of the failure. And subsequently, by selecting the failure with the highest relevance. This might still need some improvements, for example by reordering checks (so that more relevant failures are handled first) and tweaking the error relevance.
2018-07-10 11:17:05 +02:00
gs_free_error GError *local = NULL;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
device = nm_manager_get_best_device_for_connection (self, sett_conn, connection, TRUE, NULL, &local);
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
if (!device) {
core: cleanup NMManager's validate_activation_request() - there are only two callers of validate_activation_request(). One of them, might already lookup the device before calling the validate function. Safe to looking up again. But this is not only an optimization, more importantly, it feels odd to first lookup a device, and then later look it up again. Are we guaranteed to use the same path? Why? Just avoid that question. - re-order some error checking for missing device, so that it is clearer. - use cleanup attribute to handle return value and drop the "goto error".
2018-04-12 10:34:11 +02:00
gs_free char *iface = NULL;
/* VPN and software-device connections don't need a device yet,
* but non-virtual connections do ... */
if (!nm_connection_is_virtual (connection)) {
core: improve error message when activating profile Before: $ nmcli connection up my-wired Error: Connection activation failed: No suitable device found for this connection. After: $ nmcli connection up my-wired Error: Connection activation failed: No suitable device found for this connection (device eth0 not available because device has no carrier). This relies on nm_manager_get_best_device_for_connection() giving a suitable error. That is however a bit complicated, because if no suitable device is found, it's not immediately clear what is the exact reason. E.g. if you try to activate a Wi-Fi profile, the failure reason "SSID is not visible" is better than "Wi-Fi profile cannot activate on ethernet device". This is controlled by carefully setting the failure codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_* to indicate an absolute relevance of the failure. And subsequently, by selecting the failure with the highest relevance. This might still need some improvements, for example by reordering checks (so that more relevant failures are handled first) and tweaking the error relevance.
2018-07-10 11:17:05 +02:00
g_set_error (error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_UNKNOWN_DEVICE,
"No suitable device found for this connection (%s).",
local->message);
core: cleanup NMManager's validate_activation_request() - there are only two callers of validate_activation_request(). One of them, might already lookup the device before calling the validate function. Safe to looking up again. But this is not only an optimization, more importantly, it feels odd to first lookup a device, and then later look it up again. Are we guaranteed to use the same path? Why? Just avoid that question. - re-order some error checking for missing device, so that it is clearer. - use cleanup attribute to handle return value and drop the "goto error".
2018-04-12 10:34:11 +02:00
return NULL;
}
manager: reuse a device connection is active on if none was given upon activation If a connection is already active let's keep it on the same device. This makes it possible to reactivate a connection without client knowing which device is it active on. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
core: cleanup NMManager's validate_activation_request() - there are only two callers of validate_activation_request(). One of them, might already lookup the device before calling the validate function. Safe to looking up again. But this is not only an optimization, more importantly, it feels odd to first lookup a device, and then later look it up again. Are we guaranteed to use the same path? Why? Just avoid that question. - re-order some error checking for missing device, so that it is clearer. - use cleanup attribute to handle return value and drop the "goto error".
2018-04-12 10:34:11 +02:00
/* Look for an existing device with the connection's interface name */
manager: don't activate device if the parent is missing In multiple places we currently proceed to creating a virtual device even if the connection specifies a parent device which is missing. This can be easily reproduced with: nmcli con add type vxlan ifname vxlan1 \ vxlan.parent not-exists \ id 43 remote 172.25.1.1 which creates a vxlan1 interface without activating any connection. Add a check to prevent this. https://bugzilla.redhat.com/show_bug.cgi?id=1774074 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/344
2019-11-21 18:05:11 +01:00
iface = nm_manager_get_connection_iface (self, connection, NULL, NULL, error);
core: cleanup NMManager's validate_activation_request() - there are only two callers of validate_activation_request(). One of them, might already lookup the device before calling the validate function. Safe to looking up again. But this is not only an optimization, more importantly, it feels odd to first lookup a device, and then later look it up again. Are we guaranteed to use the same path? Why? Just avoid that question. - re-order some error checking for missing device, so that it is clearer. - use cleanup attribute to handle return value and drop the "goto error".
2018-04-12 10:34:11 +02:00
if (!iface)
return NULL;
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
core: cleanup NMManager's validate_activation_request() - there are only two callers of validate_activation_request(). One of them, might already lookup the device before calling the validate function. Safe to looking up again. But this is not only an optimization, more importantly, it feels odd to first lookup a device, and then later look it up again. Are we guaranteed to use the same path? Why? Just avoid that question. - re-order some error checking for missing device, so that it is clearer. - use cleanup attribute to handle return value and drop the "goto error".
2018-04-12 10:34:11 +02:00
device = find_device_by_iface (self, iface, connection, NULL);
if (!device) {
g_set_error_literal (error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_UNKNOWN_DEVICE,
"Failed to find a compatible device for this connection");
return NULL;
}
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
}
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d 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.
2014-10-15 21:17:45 -05:00
}
manager: accept non-null device for VPN activations Commit 10753c36168a ("manager: merge VPN handling into _new_active_connection()") added a check to fail the activation of VPNs when a device is passed to ActivateConnection(), since the device argument is ignored for VPNs. This broke activating VPNs from nm-applet as nm-applet sets both the specific_object (parent-connection) and device arguments in the activation request. Note that we already check in _new_active_connection() that when a device is supplied, it matches the device of the parent connection. Therefore, the check can be dropped. Reported-by: Michael Biebl <biebl@debian.org> Fixes: 10753c36168a82cd658df8a7da800960fddd78ed https://github.com/NetworkManager/NetworkManager/pull/159
2018-07-06 15:54:16 +02:00
nm_assert (is_vpn || NM_IS_DEVICE (device));
manager: merge VPN handling into _new_active_connection() Merge _new_vpn_active_connection() into _new_active_connection(). It was the only caller, and it is simpler to have all the code visible at one place. That also shows, that the device argument is ignored and not handled. Ensure that no device is specified for VPN type activations.
2018-04-12 13:37:40 +02:00
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
*out_device = device;
manager/trivial: rename boolean variable "vpn" to "is_vpn"
2018-04-12 11:15:42 +02:00
*out_is_vpn = is_vpn;
core: cleanup NMManager's validate_activation_request() - there are only two callers of validate_activation_request(). One of them, might already lookup the device before calling the validate function. Safe to looking up again. But this is not only an optimization, more importantly, it feels odd to first lookup a device, and then later look it up again. Are we guaranteed to use the same path? Why? Just avoid that question. - re-order some error checking for missing device, so that it is clearer. - use cleanup attribute to handle return value and drop the "goto error".
2018-04-12 10:34:11 +02:00
return g_steal_pointer (&subject);
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: more flattening of PendingActivation objects 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.
2012-09-13 16:51:58 -05:00
core: PolicyKit protect connection activation
2010-06-03 23:20:11 -07:00
static void
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
_activation_auth_done (NMManager *self,
NMActiveConnection *active,
GDBusMethodInvocation *invocation,
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
gboolean success,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
const char *error_desc)
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
{
GError *error = NULL;
manager: add audit support
2015-07-14 10:26:54 +02:00
NMAuthSubject *subject;
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
NMSettingsConnection *connection;
core: rework passing user-data to nm_active_connection_authorize() Previously, nm_active_connection_authorize() accepts two user-data pointers for convenience. nm_active_connection_authorize() has three callers. One only requires one user-data, one passes two user-data pointers, and one requires three pointer. Also, the way how the third passes the user data (via g_object_set_qdata_full()) is not great. Let's only use one user-data pointer. We commonly do that, and it's easy enough to allocate a buffer to pack multiple pointers together.
2018-04-17 14:59:27 +02:00
manager: add audit support
2015-07-14 10:26:54 +02:00
subject = nm_active_connection_get_subject (active);
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
connection = nm_active_connection_get_settings_connection (active);
core: more flattening of PendingActivation objects 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.
2012-09-13 16:51:58 -05:00
manager: some refactoring of error paths to return early Often, functions perform a series of steps, and when they fail, they bail out. It's simpler if the code is structured that way, so you can read it from top to bottom and whenever something is wrong, either return directly (or goto a cleanup label at the bottom).
2018-04-12 15:40:32 +02:00
if (!success) {
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
error = g_error_new_literal (NM_MANAGER_ERROR,
trivial: fix whitespace
2016-01-12 09:46:28 +01:00
NM_MANAGER_ERROR_PERMISSION_DENIED,
error_desc);
manager: some refactoring of error paths to return early Often, functions perform a series of steps, and when they fail, they bail out. It's simpler if the code is structured that way, so you can read it from top to bottom and whenever something is wrong, either return directly (or goto a cleanup label at the bottom).
2018-04-12 15:40:32 +02:00
goto fail;
core: more flattening of PendingActivation objects 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.
2012-09-13 16:51:58 -05:00
}
manager: some refactoring of error paths to return early Often, functions perform a series of steps, and when they fail, they bail out. It's simpler if the code is structured that way, so you can read it from top to bottom and whenever something is wrong, either return directly (or goto a cleanup label at the bottom).
2018-04-12 15:40:32 +02:00
if (!_internal_activate_generic (self, active, &error))
goto fail;
nm_settings_connection_autoconnect_blocked_reason_set (connection,
NM_SETTINGS_AUTO_CONNECT_BLOCKED_REASON_USER_REQUEST,
FALSE);
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
g_dbus_method_invocation_return_value (invocation,
manager: some refactoring of error paths to return early Often, functions perform a series of steps, and when they fail, they bail out. It's simpler if the code is structured that way, so you can read it from top to bottom and whenever something is wrong, either return directly (or goto a cleanup label at the bottom).
2018-04-12 15:40:32 +02:00
g_variant_new ("(o)",
nm_dbus_object_get_path (NM_DBUS_OBJECT (active))));
nm_audit_log_connection_op (NM_AUDIT_OP_CONN_ACTIVATE, connection, TRUE, NULL,
subject, NULL);
return;
fail:
audit: log changed properties when updating a connection The main purpose of audit logging is to understand who did what to the system configuration, so it is useful to log also the list of changed properties when a connection is updated: op="connection-update" uuid="2f3e48fc-5f47-41d9-9278-d2871378df43" name="pppoe1" args="pppoe.username,pppoe.password" <======== pid=9523 uid=1001 result="success"
2016-04-20 12:10:55 +02:00
nm_audit_log_connection_op (NM_AUDIT_OP_CONN_ACTIVATE, connection, FALSE, NULL,
manager: add audit support
2015-07-14 10:26:54 +02:00
subject, error->message);
manager: use nm_active_connection_set_state_fail() instead of _internal_activation_failed() There is a small change in behavior: Previously, the DEACTIVATING/DEACTIVATED states were set if and only if the previous state was less or equal then ACTIVATED. For example, if the state was already DEACTIVATING, it would have done nothing. Now, nm_active_connection_set_state_fail() transitions the states depending on the previous state. E.g. it would only set DEACTIVATING state, if the previous state was ACTIVATING/ACTIVATED. On the other hand, it would always progress the state to DEACTIVATED. The new behavior makes more sense to me, although I doubt that there is a visible difference.
2018-02-05 16:41:10 +01:00
nm_active_connection_set_state_fail (active,
NM_ACTIVE_CONNECTION_STATE_REASON_UNKNOWN,
error->message);
manager: add audit support
2015-07-14 10:26:54 +02:00
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
g_dbus_method_invocation_take_error (invocation, error);
2008-11-21 Dan Williams <dcbw@redhat.com> * src/nm-dbus-manager.c src/nm-dbus-manager.h - (nm_dbus_manager_get_name_owner): return error * src/nm-manager.c - (impl_manager_activate_connection): perform additional validation on ActivateConnection calls of user connections - (is_user_request_authorized): ensure that the requestor is the same UID as the UID that owns the user settings service; users shouldn't be able to control another user's connections git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4325 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-21 18:11:15 +00:00
}
2007-09-28 Tambet Ingo <tambet@gmail.com> * src/nm-manager.c: * src/nm-manager.h: Implement device activation through NMManager. Implement "pending device activation" here - If the connection isn't found, we try to wait for up to 5 seconds for the connection to be provided. Add NMConnectionType argument to "connection-added" and "connection-removed" signals. (nm_manager_get): Remove. Finally. * src/nm-activation-request.c: * src/nm-activation-request.h: Remove all the deferred activation code. * src/nm-device.c: Remove all the deferred activation code. Once * the device activation is started, it's started. Update the activation virtual function signature. * src/nm-device-interface.c: * src/nm-device-interface.h: Device activation now takes only NMActRequest argument. Don't expose device activation directly on dbus, it's supposed to go through NMManager now. * src/NetworkManagerPolicy.c (nm_policy_device_change_check): * Make the code a bit more compact. Use the new device activation methods through NMManager. * introspection/nm-manager-client.xml: * introspection/nm-manager.xml: * libnm-glib/nm-client.c: * libnm-glib/nm-client.h: Add device activation method. * libnm-glib/nm-device.c: * libnm-glib/nm-device.h: * introspection/nm-device.xml: Remove device activation method. It's done through NMManager now. * src/vpn-manager/nm-vpn-manager.c (impl_vpn_manager_connect): * Use the shiny new (nm_manager_get_device_by_path) function, get rid of our own )find_device). git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2915 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-10-01 15:38:39 +00:00
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_activate_connection (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *dbus_connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
manager: use cleanup functions for impl_manager_activate_connection() Also, drop two redundant g_assert(). If we proceed, we will very soon afterwards hit a SEGFAULT or a g_return_val_if_fail(), which is just as good.
2018-02-05 14:51:27 +01:00
gs_unref_object NMActiveConnection *active = NULL;
gs_unref_object NMAuthSubject *subject = NULL;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn = NULL;
core: make nm_manager_activate_connection() take a Device, not a path Simpler; everywhere that called it has an NMDevice already anyway.
2012-09-13 15:57:36 -05:00
NMDevice *device = NULL;
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
gboolean is_vpn = FALSE;
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
GError *error = NULL;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
const char *connection_path;
const char *device_path;
const char *specific_object_path;
g_variant_get (parameters, "(&o&o&o)", &connection_path, &device_path, &specific_object_path);
2007-10-16 Dan Williams <dcbw@redhat.com> * libnm-util/nm-client.c - (nm_client_activate_device): convert NULL specific_object to "/", which is used in place of NULL * src/nm-manager.c - (impl_manager_activate_device): convert "/" specific_object back into NULL git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2979 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-10-16 18:59:36 +00:00
core: use nm_utils_dbus_normalize_object_path() to cleanup D-Bus argument
2018-04-11 17:05:00 +02:00
connection_path = nm_utils_dbus_normalize_object_path (connection_path);
specific_object_path = nm_utils_dbus_normalize_object_path (specific_object_path);
device_path = nm_utils_dbus_normalize_object_path (device_path);
core: extend ActivateConnection to allow NULL connection paths 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.
2013-07-24 10:41:39 -05:00
/* If the connection path is given and valid, that connection is activated.
* Otherwise the "best" connection for the device is chosen and activated,
* regardless of whether that connection is autoconnect-enabled or not
* (since this is an explicit request, not an auto-activation request).
*/
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
if (connection_path) {
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn = nm_settings_get_connection_by_path (priv->settings, connection_path);
if (!sett_conn) {
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
error = g_error_new_literal (NM_MANAGER_ERROR,
core: minor refactoring condition in validate_activation_request()
2017-06-01 17:03:46 +02:00
NM_MANAGER_ERROR_UNKNOWN_CONNECTION,
"Connection could not be found.");
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
goto error;
}
} else {
core: extend ActivateConnection to allow NULL connection paths 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.
2013-07-24 10:41:39 -05:00
/* If no connection is given, find a suitable connection for the given device path */
if (!device_path) {
error = g_error_new_literal (NM_MANAGER_ERROR, NM_MANAGER_ERROR_UNKNOWN_DEVICE,
"Only devices may be activated without a specifying a connection");
goto error;
}
device = nm_manager_get_device_by_path (self, device_path);
if (!device) {
error = g_error_new (NM_MANAGER_ERROR, NM_MANAGER_ERROR_UNKNOWN_DEVICE,
manager: make some error reporting a bit more specific Make sure there's always the device and connection as well as the reason when a slave activation fails. The slave connection could in fact be chosen automatically on "nmcli d connect" and the user might not be aware activation of which connection was attempted: $ nmcli d connect enp0s25 Error: Device activation failed: Master connection not found or invalid
2016-03-30 09:00:06 +02:00
"Can not activate an unknown device '%s'", device_path);
core: extend ActivateConnection to allow NULL connection paths 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.
2013-07-24 10:41:39 -05:00
goto error;
}
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn = nm_device_get_best_connection (device, specific_object_path, &error);
if (!sett_conn)
core: extend ActivateConnection to allow NULL connection paths 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.
2013-07-24 10:41:39 -05:00
goto error;
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
}
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
subject = validate_activation_request (self,
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
invocation,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn,
NULL,
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
device_path,
&device,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
&is_vpn,
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
&error);
if (!subject)
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
goto error;
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
active = _new_active_connection (self,
manager: add is-vpn argument to _new_active_connection() and avoid searching existing activations - pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection() would re-determine whether a connection is a VPN type, although that was already established previously. The confusing part is: will they come to the same result? Why? What if not? Instead pass it as argument and assert that we got it right. - the check for existing connections should look whether there is an existing active connection of type NMVpnConnection. Instead, what matters is, - do we have a connection of type VPN (otherwise, don't even bother to search for existing-ac) - is the connection already active? Checking whether the connection is already active, and ask backwards whether it's of type NMVpnConnection is odd, maybe even wrong in some cases.
2018-04-12 11:32:18 +02:00
is_vpn,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn,
NULL,
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
NULL,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
specific_object_path,
device,
subject,
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
NM_ACTIVATION_TYPE_MANAGED,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
NM_ACTIVATION_REASON_USER_REQUEST,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
_activation_bind_lifetime_to_profile_visibility (subject),
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
&error);
if (!active)
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
goto error;
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
manager: fix failed assertion on user activations We can't use g_steal_pointer(&active) in the argument list if another argument uses @active because the order of evaluation is not defined. This fixes the following bug: src/nm-manager.c:511:_async_op_complete_ac_auth_cb: assertion failed: (active == async_op_data->ac_auth.active) Fixes: f4fc62bad8559715bde501e5a2383a2fc78a2d97 https://bugzilla.redhat.com/show_bug.cgi?id=1585494
2018-06-04 10:36:52 +02:00
nm_active_connection_authorize (active,
manager: use cleanup functions for impl_manager_activate_connection() Also, drop two redundant g_assert(). If we proceed, we will very soon afterwards hit a SEGFAULT or a g_return_val_if_fail(), which is just as good.
2018-02-05 14:51:27 +01:00
NULL,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
_async_op_complete_ac_auth_cb,
_async_op_data_new_ac_auth_activate_user (self,
active,
invocation));
manager: fix failed assertion on user activations We can't use g_steal_pointer(&active) in the argument list if another argument uses @active because the order of evaluation is not defined. This fixes the following bug: src/nm-manager.c:511:_async_op_complete_ac_auth_cb: assertion failed: (active == async_op_data->ac_auth.active) Fixes: f4fc62bad8559715bde501e5a2383a2fc78a2d97 https://bugzilla.redhat.com/show_bug.cgi?id=1585494
2018-06-04 10:36:52 +02:00
/* we passed the pointer on to _async_op_data_new_ac_auth_activate_user() */
g_steal_pointer (&active);
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
return;
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
error:
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (sett_conn) {
nm_audit_log_connection_op (NM_AUDIT_OP_CONN_ACTIVATE, sett_conn, FALSE, NULL,
manager: add audit support
2015-07-14 10:26:54 +02:00
subject, error->message);
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_take_error (invocation, error);
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: more flattening of PendingActivation objects 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.
2012-09-13 16:51:58 -05:00
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
static void
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
activation_add_done (NMSettings *settings,
core: more flattening of PendingActivation objects 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.
2012-09-13 16:51:58 -05:00
NMSettingsConnection *new_connection,
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
GError *error,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
settings: add audit support
2015-07-15 14:44:45 +02:00
NMAuthSubject *subject,
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
gpointer user_data)
{
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
NMManager *self;
gs_unref_object NMActiveConnection *active = NULL;
manager: use cleanup attribute in impl_manager_add_and_activate_connection() and related Also, in _add_and_activate_auth_done(), always steal the connection from active's user-data. Otherwise, the lifetime of the connection is extended until active gets destroyed. For example, if we would leak active, we would also leak connection that way.
2018-04-12 12:01:25 +02:00
gs_free_error GError *local = NULL;
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
gpointer async_op_type_ptr;
AsyncOpType async_op_type;
GVariant *result_floating;
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
nm_utils_user_data_unpack (user_data, &self, &active, &async_op_type_ptr);
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
async_op_type = GPOINTER_TO_INT (async_op_type_ptr);
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
core: cleanup error path in activation_add_done() Don't return success from a nested code path. Handle all errors first, and return early. Well, we cannot really return right away because we need to handle the failure. So, at least, check for errors and "goto fail".
2018-12-19 17:35:17 +01:00
if (error)
goto fail;
nm_active_connection_set_settings_connection (active, new_connection);
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
if (!_internal_activate_generic (self, active, &local))
core: cleanup error path in activation_add_done() Don't return success from a nested code path. Handle all errors first, and return early. Well, we cannot really return right away because we need to handle the failure. So, at least, check for errors and "goto fail".
2018-12-19 17:35:17 +01:00
goto fail;
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
if (async_op_type == ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE) {
result_floating = g_variant_new ("(oo)",
nm_dbus_object_get_path (NM_DBUS_OBJECT (new_connection)),
nm_dbus_object_get_path (NM_DBUS_OBJECT (active)));
} else {
manager: Fix GVariant format strings for AddAndActivate2 return value AddAndActivate2 returns an empty a{sv} dictionary for extensibility. The format strings to create the methods return value were slightly wrong, causing assertion failures. Fixes: fbb038af5e5d675c994de26da676edfd8e73ffbe https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/73
2019-01-29 13:24:43 +01:00
result_floating = g_variant_new ("(oo@a{sv})",
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
nm_dbus_object_get_path (NM_DBUS_OBJECT (new_connection)),
nm_dbus_object_get_path (NM_DBUS_OBJECT (active)),
manager: Fix GVariant format strings for AddAndActivate2 return value AddAndActivate2 returns an empty a{sv} dictionary for extensibility. The format strings to create the methods return value were slightly wrong, causing assertion failures. Fixes: fbb038af5e5d675c994de26da676edfd8e73ffbe https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/73
2019-01-29 13:24:43 +01:00
g_variant_new_array (G_VARIANT_TYPE ("{sv}"), NULL, 0));
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
}
g_dbus_method_invocation_return_value (context, result_floating);
core: cleanup error path in activation_add_done() Don't return success from a nested code path. Handle all errors first, and return early. Well, we cannot really return right away because we need to handle the failure. So, at least, check for errors and "goto fail".
2018-12-19 17:35:17 +01:00
nm_audit_log_connection_op (NM_AUDIT_OP_CONN_ADD_ACTIVATE,
nm_active_connection_get_settings_connection (active),
TRUE,
NULL,
nm_active_connection_get_subject (active),
NULL);
return;
fail:
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
if (local) {
nm_assert (!error);
error = local;
} else
nm_assert (error);
manager: use cleanup attribute in impl_manager_add_and_activate_connection() and related Also, in _add_and_activate_auth_done(), always steal the connection from active's user-data. Otherwise, the lifetime of the connection is extended until active gets destroyed. For example, if we would leak active, we would also leak connection that way.
2018-04-12 12:01:25 +02:00
manager: use nm_active_connection_set_state_fail() instead of _internal_activation_failed() There is a small change in behavior: Previously, the DEACTIVATING/DEACTIVATED states were set if and only if the previous state was less or equal then ACTIVATED. For example, if the state was already DEACTIVATING, it would have done nothing. Now, nm_active_connection_set_state_fail() transitions the states depending on the previous state. E.g. it would only set DEACTIVATING state, if the previous state was ACTIVATING/ACTIVATED. On the other hand, it would always progress the state to DEACTIVATED. The new behavior makes more sense to me, although I doubt that there is a visible difference.
2018-02-05 16:41:10 +01:00
nm_active_connection_set_state_fail (active,
NM_ACTIVE_CONNECTION_STATE_REASON_UNKNOWN,
error->message);
manager: better handle failures in AddAndActivateConnection nm_settings_add_connection_dbus() invokes the activation_add_done() callback with a NULL @new_connection in case of error: add a check to prevent a crash.
2016-12-23 14:02:58 +01:00
if (new_connection)
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
nm_settings_connection_delete (new_connection, FALSE);
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
g_dbus_method_invocation_return_gerror (context, error);
manager: add audit support
2015-07-14 10:26:54 +02:00
nm_audit_log_connection_op (NM_AUDIT_OP_CONN_ADD_ACTIVATE,
audit-manager: don't log connection whose addition fails In AddAndActivate the uuid and id make no sense until authorization succeeds and the connection is saved.
2015-08-10 12:33:01 +02:00
NULL,
manager: add audit support
2015-07-14 10:26:54 +02:00
FALSE,
audit: log changed properties when updating a connection The main purpose of audit logging is to understand who did what to the system configuration, so it is useful to log also the list of changed properties when a connection is updated: op="connection-update" uuid="2f3e48fc-5f47-41d9-9278-d2871378df43" name="pppoe1" args="pppoe.username,pppoe.password" <======== pid=9523 uid=1001 result="success"
2016-04-20 12:10:55 +02:00
NULL,
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
nm_active_connection_get_subject (active),
manager: add audit support
2015-07-14 10:26:54 +02:00
error->message);
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
}
static void
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
_add_and_activate_auth_done (NMManager *self,
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
AsyncOpType async_op_type,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
NMActiveConnection *active,
NMConnection *connection,
GDBusMethodInvocation *invocation,
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
NMSettingsConnectionPersistMode persist_mode,
gboolean is_volatile,
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
gboolean success,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
const char *error_desc)
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
{
core: rework passing user-data to nm_active_connection_authorize() Previously, nm_active_connection_authorize() accepts two user-data pointers for convenience. nm_active_connection_authorize() has three callers. One only requires one user-data, one passes two user-data pointers, and one requires three pointer. Also, the way how the third passes the user data (via g_object_set_qdata_full()) is not great. Let's only use one user-data pointer. We commonly do that, and it's easy enough to allocate a buffer to pack multiple pointers together.
2018-04-17 14:59:27 +02:00
NMManagerPrivate *priv;
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
GError *error = NULL;
core: more flattening of PendingActivation objects 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.
2012-09-13 16:51:58 -05:00
manager: use cleanup attribute in impl_manager_add_and_activate_connection() and related Also, in _add_and_activate_auth_done(), always steal the connection from active's user-data. Otherwise, the lifetime of the connection is extended until active gets destroyed. For example, if we would leak active, we would also leak connection that way.
2018-04-12 12:01:25 +02:00
if (!success) {
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
error_desc);
manager: add audit support
2015-07-14 10:26:54 +02:00
nm_audit_log_connection_op (NM_AUDIT_OP_CONN_ADD_ACTIVATE,
audit-manager: don't log connection whose addition fails In AddAndActivate the uuid and id make no sense until authorization succeeds and the connection is saved.
2015-08-10 12:33:01 +02:00
NULL,
manager: add audit support
2015-07-14 10:26:54 +02:00
FALSE,
audit: log changed properties when updating a connection The main purpose of audit logging is to understand who did what to the system configuration, so it is useful to log also the list of changed properties when a connection is updated: op="connection-update" uuid="2f3e48fc-5f47-41d9-9278-d2871378df43" name="pppoe1" args="pppoe.username,pppoe.password" <======== pid=9523 uid=1001 result="success"
2016-04-20 12:10:55 +02:00
NULL,
manager: add audit support
2015-07-14 10:26:54 +02:00
nm_active_connection_get_subject (active),
error->message);
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
g_dbus_method_invocation_take_error (invocation, error);
manager: use cleanup attribute in impl_manager_add_and_activate_connection() and related Also, in _add_and_activate_auth_done(), always steal the connection from active's user-data. Otherwise, the lifetime of the connection is extended until active gets destroyed. For example, if we would leak active, we would also leak connection that way.
2018-04-12 12:01:25 +02:00
return;
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
}
core: ensure ActiveConnections stay alive over activation paths With some upcoming changes, ActiveConnection objects could change to DEACTIVATED state during activation, for example if the AC's device was removed while the AC was being authorized. To ensure the AC stays alive and is not used after being freed, keep a reference to the AC across authorization operations.
2014-02-26 16:04:45 -06:00
core: rework passing user-data to nm_active_connection_authorize() Previously, nm_active_connection_authorize() accepts two user-data pointers for convenience. nm_active_connection_authorize() has three callers. One only requires one user-data, one passes two user-data pointers, and one requires three pointer. Also, the way how the third passes the user data (via g_object_set_qdata_full()) is not great. Let's only use one user-data pointer. We commonly do that, and it's easy enough to allocate a buffer to pack multiple pointers together.
2018-04-17 14:59:27 +02:00
priv = NM_MANAGER_GET_PRIVATE (self);
core/trivial: add FIXME comments about clean shutdown at exit
2018-04-18 10:23:22 +02:00
/* FIXME(shutdown): nm_settings_add_connection_dbus() cannot be cancelled. It should be made
* cancellable and tracked via AsyncOpData to be able to do a clean
* shutdown. */
manager: use cleanup attribute in impl_manager_add_and_activate_connection() and related Also, in _add_and_activate_auth_done(), always steal the connection from active's user-data. Otherwise, the lifetime of the connection is extended until active gets destroyed. For example, if we would leak active, we would also leak connection that way.
2018-04-12 12:01:25 +02:00
nm_settings_add_connection_dbus (priv->settings,
connection,
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
persist_mode,
core,libnm: add AddConnection2() D-Bus API to block autoconnect from the start It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
2019-07-09 15:22:01 +02:00
NM_SETTINGS_CONNECTION_ADD_REASON_NONE,
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
( is_volatile
? NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE
: NM_SETTINGS_CONNECTION_INT_FLAGS_NONE),
settings: pass in authentication subject to nm_settings_add_connection_dbus() nm_settings_add_connection_dbus() has two callers. One of them is NMManager during AddAndActivate. In this case, the NMActiveConnection already created an auth-subject. Re-use it. Note how creating an auth-subject involves reading procfs to determine whether the process still exists. This is not about the additional overhead of that, but about the race where the process could drop of in the meantime. The calling process might be gone now, and we would fail creating the auth-subject. There is no need for that, because we already evaluated all information we need. Quite likely, in the case of this race, PolicyKit will also determine that the process is gone and fail authorization too. But that's PolicyKit's decision to make, not nm_settings_add_connection_dbus()'s.
2018-04-18 10:10:30 +02:00
nm_active_connection_get_subject (active),
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
invocation,
manager: use cleanup attribute in impl_manager_add_and_activate_connection() and related Also, in _add_and_activate_auth_done(), always steal the connection from active's user-data. Otherwise, the lifetime of the connection is extended until active gets destroyed. For example, if we would leak active, we would also leak connection that way.
2018-04-12 12:01:25 +02:00
activation_add_done,
manager: use nm_utils_user_data_pack() instead of explicit AddAndActivateInfo structure
2018-04-17 15:29:10 +02:00
nm_utils_user_data_pack (self,
core: Add persist option to AddAndActivateConnection2 This option allows setting the rules for how long the connection should be stored. Valid values are "disk" (the default), "memory" and "volatile". If "memory" or "volatile" is selected, the connection will not be saved to disk and with "volatile" it will be automatically removed when it is deactivated again.
2018-10-25 16:54:37 +02:00
g_object_ref (active),
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
GINT_TO_POINTER (async_op_type)));
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
}
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_add_and_activate_connection (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *dbus_connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
gs_unref_object NMConnection *incompl_conn = NULL;
core: Add option to AddAndActivateConnection2 to bind the lifetime This allows binding the lifetime of the created connection to the existance of the requesting dbus client. This feature is useful if one has a service specific connection (e.g. P2P wireless) which will not be useful without the specific service. This is simply a mechanism to ensure proper connection cleanup if the requesting service has a failure.
2018-10-26 13:17:31 +02:00
gs_unref_object NMActiveConnection *active = NULL;
manager: use cleanup attribute in impl_manager_add_and_activate_connection() and related Also, in _add_and_activate_auth_done(), always steal the connection from active's user-data. Otherwise, the lifetime of the connection is extended until active gets destroyed. For example, if we would leak active, we would also leak connection that way.
2018-04-12 12:01:25 +02:00
gs_unref_object NMAuthSubject *subject = NULL;
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
GError *error = NULL;
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
NMDevice *device = NULL;
manager/trivial: rename boolean variable "vpn" to "is_vpn"
2018-04-12 11:15:42 +02:00
gboolean is_vpn = FALSE;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
gs_unref_variant GVariant *settings = NULL;
core: Add an AddAndActivateConnection2 routine with options parameter This adds a new routine to be able to handle an arbitrary set of further options for AddAndActivateConnection. Note that no options are accepted for now.
2018-10-30 16:40:40 +01:00
gs_unref_variant GVariant *options = NULL;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
const char *device_path;
const char *specific_object_path;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
gs_free NMConnection **conns = NULL;
settings/trivial: rename NM_SETTINGS_CONNECTION_PERSIST_MODE_DISK to NM_SETTINGS_CONNECTION_PERSIST_MODE_TO_DISK NM_SETTINGS_CONNECTION_PERSIST_MODE_DISK really directly corresponds to NM_SETTINGS_UPDATE2_FLAG_TO_DISK. Rename, so that this is better reflected.
2019-07-22 21:56:05 +02:00
NMSettingsConnectionPersistMode persist_mode = NM_SETTINGS_CONNECTION_PERSIST_MODE_TO_DISK;
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
gboolean is_volatile = FALSE;
manager: fix checking for bind-lifetime setting in add-and-activate Previously, @bind_lifetime was a string. While parsing the @options, we would set the string to the content of the parsed GVariant. Note that the GVariant is unrefed before we access @bind_lifetime, thus it's not guaranteed that it will still exist. Arguably, the string GVariant's lifetime is tied to the @options dictionary, so indeed it lives long enough. But that is not-obviously the case. Fix that by using a boolean instead. Also, rename @bind_lifetime to @bind_dbus_client.
2018-11-18 11:52:13 +01:00
gboolean bind_dbus_client = FALSE;
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
AsyncOpType async_op_type;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
if (nm_streq (method_info->parent.name, "AddAndActivateConnection2")) {
async_op_type = ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE2;
core: Add an AddAndActivateConnection2 routine with options parameter This adds a new routine to be able to handle an arbitrary set of further options for AddAndActivateConnection. Note that no options are accepted for now.
2018-10-30 16:40:40 +01:00
g_variant_get (parameters, "(@a{sa{sv}}&o&o@a{sv})", &settings, &device_path, &specific_object_path, &options);
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
} else {
nm_assert (nm_streq (method_info->parent.name, "AddAndActivateConnection"));
async_op_type = ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE;
core: Add an AddAndActivateConnection2 routine with options parameter This adds a new routine to be able to handle an arbitrary set of further options for AddAndActivateConnection. Note that no options are accepted for now.
2018-10-30 16:40:40 +01:00
g_variant_get (parameters, "(@a{sa{sv}}&o&o)", &settings, &device_path, &specific_object_path);
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
}
core: Add an AddAndActivateConnection2 routine with options parameter This adds a new routine to be able to handle an arbitrary set of further options for AddAndActivateConnection. Note that no options are accepted for now.
2018-10-30 16:40:40 +01:00
if (options) {
GVariantIter iter;
const char *option_name;
GVariant *option_value;
g_variant_iter_init (&iter, options);
while (g_variant_iter_next (&iter, "{&sv}", &option_name, &option_value)) {
gs_unref_variant GVariant *option_value_free = NULL;
core: Add persist option to AddAndActivateConnection2 This option allows setting the rules for how long the connection should be stored. Valid values are "disk" (the default), "memory" and "volatile". If "memory" or "volatile" is selected, the connection will not be saved to disk and with "volatile" it will be automatically removed when it is deactivated again.
2018-10-25 16:54:37 +02:00
const char *s;
core: Add an AddAndActivateConnection2 routine with options parameter This adds a new routine to be able to handle an arbitrary set of further options for AddAndActivateConnection. Note that no options are accepted for now.
2018-10-30 16:40:40 +01:00
option_value_free = option_value;
manager: prefer nm_streq over strcmp in impl_manager_add_and_activate_connection() - use nm_streq() instead of g_strcmp0(). I think streq() is easier to understand. - the strings that are checked here must never be %NULL, because they come from string variants. Use nm_streq() instead of nm_streq0() or g_strcmp0(). - don't add a "." to the GError messages. GError messages are commonly embedded in a larger message, and shoult not themself contain the dot.
2018-11-17 15:54:49 +01:00
if ( nm_streq (option_name, "persist")
&& g_variant_is_of_type (option_value, G_VARIANT_TYPE_STRING)) {
core: Add persist option to AddAndActivateConnection2 This option allows setting the rules for how long the connection should be stored. Valid values are "disk" (the default), "memory" and "volatile". If "memory" or "volatile" is selected, the connection will not be saved to disk and with "volatile" it will be automatically removed when it is deactivated again.
2018-10-25 16:54:37 +02:00
s = g_variant_get_string (option_value, NULL);
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
is_volatile = FALSE;
settings/trivial: rename NM_SETTINGS_CONNECTION_PERSIST_MODE_DISK to NM_SETTINGS_CONNECTION_PERSIST_MODE_TO_DISK NM_SETTINGS_CONNECTION_PERSIST_MODE_DISK really directly corresponds to NM_SETTINGS_UPDATE2_FLAG_TO_DISK. Rename, so that this is better reflected.
2019-07-22 21:56:05 +02:00
persist_mode = NM_SETTINGS_CONNECTION_PERSIST_MODE_TO_DISK;
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
if (nm_streq (s, "volatile")) {
persist_mode = NM_SETTINGS_CONNECTION_PERSIST_MODE_IN_MEMORY_ONLY;
is_volatile = TRUE;
} else if (nm_streq (s, "memory"))
persist_mode = NM_SETTINGS_CONNECTION_PERSIST_MODE_IN_MEMORY_ONLY;
else if (nm_streq (s, "disk")) {
/* pass */
} else {
core: Add persist option to AddAndActivateConnection2 This option allows setting the rules for how long the connection should be stored. Valid values are "disk" (the default), "memory" and "volatile". If "memory" or "volatile" is selected, the connection will not be saved to disk and with "volatile" it will be automatically removed when it is deactivated again.
2018-10-25 16:54:37 +02:00
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_INVALID_ARGUMENTS,
manager: prefer nm_streq over strcmp in impl_manager_add_and_activate_connection() - use nm_streq() instead of g_strcmp0(). I think streq() is easier to understand. - the strings that are checked here must never be %NULL, because they come from string variants. Use nm_streq() instead of nm_streq0() or g_strcmp0(). - don't add a "." to the GError messages. GError messages are commonly embedded in a larger message, and shoult not themself contain the dot.
2018-11-17 15:54:49 +01:00
"Option \"persist\" must be one of \"volatile\", \"memory\" or \"disk\"");
core: Add persist option to AddAndActivateConnection2 This option allows setting the rules for how long the connection should be stored. Valid values are "disk" (the default), "memory" and "volatile". If "memory" or "volatile" is selected, the connection will not be saved to disk and with "volatile" it will be automatically removed when it is deactivated again.
2018-10-25 16:54:37 +02:00
goto error;
}
all: rename "bind" option for AddAndActivateConnection2 to "bind-activation" "bind" specifically binds the lifetime of the activation (NMActiveConnection). In combination with "persist=volatile", the lifetime of the NMSettingsConnection is indirectly bound to the NMActiveConnection. But still these concepts make sense independently. In the future, it may make sense to also bind the lifetime of the NMSettingsConnection to the D-Bus client. Hence, rename the option to allow for the distinction. Also, belatedly fix libnm comment about "bind" only working with "persist" "volatile". Fixes: eb883e34a5889812d35e5c2d7bc6051723001a3a
2018-11-19 11:16:44 +01:00
} else if ( nm_streq (option_name, "bind-activation")
manager: prefer nm_streq over strcmp in impl_manager_add_and_activate_connection() - use nm_streq() instead of g_strcmp0(). I think streq() is easier to understand. - the strings that are checked here must never be %NULL, because they come from string variants. Use nm_streq() instead of nm_streq0() or g_strcmp0(). - don't add a "." to the GError messages. GError messages are commonly embedded in a larger message, and shoult not themself contain the dot.
2018-11-17 15:54:49 +01:00
&& g_variant_is_of_type (option_value, G_VARIANT_TYPE_STRING)) {
core: Add option to AddAndActivateConnection2 to bind the lifetime This allows binding the lifetime of the created connection to the existance of the requesting dbus client. This feature is useful if one has a service specific connection (e.g. P2P wireless) which will not be useful without the specific service. This is simply a mechanism to ensure proper connection cleanup if the requesting service has a failure.
2018-10-26 13:17:31 +02:00
s = g_variant_get_string (option_value, NULL);
manager: fix checking for bind-lifetime setting in add-and-activate Previously, @bind_lifetime was a string. While parsing the @options, we would set the string to the content of the parsed GVariant. Note that the GVariant is unrefed before we access @bind_lifetime, thus it's not guaranteed that it will still exist. Arguably, the string GVariant's lifetime is tied to the @options dictionary, so indeed it lives long enough. But that is not-obviously the case. Fix that by using a boolean instead. Also, rename @bind_lifetime to @bind_dbus_client.
2018-11-18 11:52:13 +01:00
if (nm_streq (s, "dbus-client"))
bind_dbus_client = TRUE;
else if (nm_streq (s, "none"))
bind_dbus_client = FALSE;
else {
core: Add option to AddAndActivateConnection2 to bind the lifetime This allows binding the lifetime of the created connection to the existance of the requesting dbus client. This feature is useful if one has a service specific connection (e.g. P2P wireless) which will not be useful without the specific service. This is simply a mechanism to ensure proper connection cleanup if the requesting service has a failure.
2018-10-26 13:17:31 +02:00
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_INVALID_ARGUMENTS,
all: rename "bind" option for AddAndActivateConnection2 to "bind-activation" "bind" specifically binds the lifetime of the activation (NMActiveConnection). In combination with "persist=volatile", the lifetime of the NMSettingsConnection is indirectly bound to the NMActiveConnection. But still these concepts make sense independently. In the future, it may make sense to also bind the lifetime of the NMSettingsConnection to the D-Bus client. Hence, rename the option to allow for the distinction. Also, belatedly fix libnm comment about "bind" only working with "persist" "volatile". Fixes: eb883e34a5889812d35e5c2d7bc6051723001a3a
2018-11-19 11:16:44 +01:00
"Option \"bind-activation\" must be one of \"dbus-client\" or \"none\"");
core: Add option to AddAndActivateConnection2 to bind the lifetime This allows binding the lifetime of the created connection to the existance of the requesting dbus client. This feature is useful if one has a service specific connection (e.g. P2P wireless) which will not be useful without the specific service. This is simply a mechanism to ensure proper connection cleanup if the requesting service has a failure.
2018-10-26 13:17:31 +02:00
goto error;
}
core: Add persist option to AddAndActivateConnection2 This option allows setting the rules for how long the connection should be stored. Valid values are "disk" (the default), "memory" and "volatile". If "memory" or "volatile" is selected, the connection will not be saved to disk and with "volatile" it will be automatically removed when it is deactivated again.
2018-10-25 16:54:37 +02:00
} else {
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_INVALID_ARGUMENTS,
manager: prefer nm_streq over strcmp in impl_manager_add_and_activate_connection() - use nm_streq() instead of g_strcmp0(). I think streq() is easier to understand. - the strings that are checked here must never be %NULL, because they come from string variants. Use nm_streq() instead of nm_streq0() or g_strcmp0(). - don't add a "." to the GError messages. GError messages are commonly embedded in a larger message, and shoult not themself contain the dot.
2018-11-17 15:54:49 +01:00
"Unknown extra option passed");
core: Add persist option to AddAndActivateConnection2 This option allows setting the rules for how long the connection should be stored. Valid values are "disk" (the default), "memory" and "volatile". If "memory" or "volatile" is selected, the connection will not be saved to disk and with "volatile" it will be automatically removed when it is deactivated again.
2018-10-25 16:54:37 +02:00
goto error;
}
core: Add an AddAndActivateConnection2 routine with options parameter This adds a new routine to be able to handle an arbitrary set of further options for AddAndActivateConnection. Note that no options are accepted for now.
2018-10-30 16:40:40 +01:00
}
}
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
core: use nm_utils_dbus_normalize_object_path() to cleanup D-Bus argument
2018-04-11 17:05:00 +02:00
specific_object_path = nm_utils_dbus_normalize_object_path (specific_object_path);
device_path = nm_utils_dbus_normalize_object_path (device_path);
core: normalize object paths on add_and_activate_connection Without this patch I can not setup new hotspot connection. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-10 10:51:15 +01:00
core: again allow calling AddAndActivateConnection() without a connection 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 a878cd814564e9d349eb8fd4f7d7d5d81d4aecaf
2013-11-01 13:59:57 +01:00
/* Try to create a new connection with the given settings.
* We allow empty settings for AddAndActivateConnection(). In that case,
trivial: fix whitespace and spelling error Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-10 11:13:55 +01:00
* the connection will be completed in nm_utils_complete_generic() or
core: again allow calling AddAndActivateConnection() without a connection 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 a878cd814564e9d349eb8fd4f7d7d5d81d4aecaf
2013-11-01 13:59:57 +01:00
* nm_device_complete_connection() below. Just make sure we don't expect
* specific data being in the connection till then (especially in
* validate_activation_request()).
*/
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
incompl_conn = nm_simple_connection_new ();
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
if (settings && g_variant_n_children (settings))
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
_nm_connection_replace_settings (incompl_conn, settings, NM_SETTING_PARSE_FLAGS_STRICT, NULL);
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
subject = validate_activation_request (self,
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
invocation,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NULL,
incompl_conn,
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
device_path,
&device,
manager/trivial: rename boolean variable "vpn" to "is_vpn"
2018-04-12 11:15:42 +02:00
&is_vpn,
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
&error);
if (!subject)
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
goto error;
manager/trivial: rename boolean variable "vpn" to "is_vpn"
2018-04-12 11:15:42 +02:00
if (is_vpn) {
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
/* Try to fill the VPN's connection setting and name at least */
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (!nm_connection_get_setting_vpn (incompl_conn)) {
libnm-core, core: move NMManagerError to nm-errors Move the definition of NMManagerError to nm-errors, register it with D-Bus, and verify in the tests that it maps correctly. NM_MANAGER_ERROR_INTERNAL gets renamed to NM_MANAGER_ERROR_FAILED for consistency. NM_MANAGER_ERROR_UNMANAGED_DEVICE is dropped since that name doesn't really describe the one place it was previously used in. NM_MANAGER_ERROR_SYSTEM_CONNECTION is dropped because it was't being used. NM_MANAGER_ERROR_UNSUPPORTED_CONNECTION_TYPE is dropped because it can be replaced with an NM_CONNECTION_ERROR. NM_MANAGER_ERROR_AUTOCONNECT_NOT_ALLOWED is turned into the more generic NM_MANAGER_ERROR_CONNECTION_NOT_AVAILABLE. Also, remove the <tp:possible-errors> sections from nm-manager.xml, since they were completely out of date.
2014-10-15 15:27:25 -04:00
error = g_error_new_literal (NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_MISSING_SETTING,
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
"VPN connections require a 'vpn' setting");
libnm-core, core: move NMManagerError to nm-errors Move the definition of NMManagerError to nm-errors, register it with D-Bus, and verify in the tests that it maps correctly. NM_MANAGER_ERROR_INTERNAL gets renamed to NM_MANAGER_ERROR_FAILED for consistency. NM_MANAGER_ERROR_UNMANAGED_DEVICE is dropped since that name doesn't really describe the one place it was previously used in. NM_MANAGER_ERROR_SYSTEM_CONNECTION is dropped because it was't being used. NM_MANAGER_ERROR_UNSUPPORTED_CONNECTION_TYPE is dropped because it can be replaced with an NM_CONNECTION_ERROR. NM_MANAGER_ERROR_AUTOCONNECT_NOT_ALLOWED is turned into the more generic NM_MANAGER_ERROR_CONNECTION_NOT_AVAILABLE. Also, remove the <tp:possible-errors> sections from nm-manager.xml, since they were completely out of date.
2014-10-15 15:27:25 -04:00
g_prefix_error (&error, "%s: ", NM_SETTING_VPN_SETTING_NAME);
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
goto error;
}
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
conns = nm_settings_connections_array_to_connections (nm_settings_get_connections (priv->settings, NULL), -1);
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
nm_utils_complete_generic (priv->platform,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
incompl_conn,
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
NM_SETTING_VPN_SETTING_NAME,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
conns,
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
NULL,
core: refactor nm_utils_complete_generic() not to use a dynamic format string For NMDeviceWifi and NMDeviceWimax, the printf format string for nm_utils_complete_generic() was created based on ssid/nsp. Since these input strings are untrusted, this is a serious bug. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-25 16:21:59 +02:00
_("VPN connection"),
core: abstract out the duplicated default-ifname-generating code NMDeviceBond, NMDeviceBridge, and NMDeviceTeam all used basically the same code to generate a default interface name. Move it into nm_utils_complete_generic().
2014-08-05 17:11:57 -04:00
NULL,
utils: add ifname argument to nm_utils_complete_generic() It's a common thing to complete a connection with an interface name; adding it to the common path is goint to save as a few tens of lines later on.
2019-05-07 10:15:10 +02:00
NULL,
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
FALSE); /* No IPv6 by default for now */
} else {
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
conns = nm_settings_connections_array_to_connections (nm_settings_get_connections (priv->settings, NULL), -1);
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
/* Let each device subclass complete the connection */
if (!nm_device_complete_connection (device,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
incompl_conn,
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
specific_object_path,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
conns,
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
&error))
goto error;
}
core: PolicyKit protect connection activation
2010-06-03 23:20:11 -07:00
core: ensure normalized connection during add-and-activate nm_connection_verify() returns success for fully valid (normalized) connections and also connections that are NM_SETTING_VERIFY_NORMALIZABLE. We really want to fully normalize the profiles during add-and-activate.
2019-06-20 15:45:34 +02:00
nm_assert (_nm_connection_verify (incompl_conn, NULL) == NM_SETTING_VERIFY_SUCCESS);
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
active = _new_active_connection (self,
manager: add is-vpn argument to _new_active_connection() and avoid searching existing activations - pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection() would re-determine whether a connection is a VPN type, although that was already established previously. The confusing part is: will they come to the same result? Why? What if not? Instead pass it as argument and assert that we got it right. - the check for existing connections should look whether there is an existing active connection of type NMVpnConnection. Instead, what matters is, - do we have a connection of type VPN (otherwise, don't even bother to search for existing-ac) - is the connection already active? Checking whether the connection is already active, and ask backwards whether it's of type NMVpnConnection is odd, maybe even wrong in some cases.
2018-04-12 11:32:18 +02:00
is_vpn,
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NULL,
incompl_conn,
core: allow passing an applied connection to nm_act_request_new() This is useful for the checkpoint/restore functionality to revert both the applied and the settings connections.
2016-09-07 17:47:26 +02:00
NULL,
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
specific_object_path,
device,
subject,
core: add activation-type property to active-connection It is still unused, but will be useful to mark a connection whether it is a full activation or assumed.
2017-03-07 11:04:36 +01:00
NM_ACTIVATION_TYPE_MANAGED,
core: specify an activation reason for active connections Specify a reason when creating active connections. The reason will be used in the next commit to tell whether slaves must be reconnected or not if a master has autoconnect-slaves=yes.
2018-03-28 17:18:04 +02:00
NM_ACTIVATION_REASON_USER_REQUEST,
core: improve and fix keeping connection active based on "connection.permissions" By setting "connection.permissions", a profile is restricted to a particular user. That means for example, that another user cannot see, modify, delete, activate or deactivate the profile. It also means, that the profile will only autoconnect when the user is logged in (has a session). Note that root is always able to activate the profile. Likewise, the user is also allowed to manually activate the own profile, even if no session currently exists (which can easily happen with `sudo`). When the user logs out (the session goes away), we want do disconnect the profile, however there are conflicting goals here: 1) if the profile was activate by root user, then logging out the user should not disconnect the profile. The patch fixes that by not binding the activation to the connection, if the activation is done by the root user. 2) if the profile was activated by the owner when it had no session, then it should stay alive until the user logs in (once) and logs out again. This is already handled by the previous commit. Yes, this point is odd. If you first do $ sudo -u $OTHER_USER nmcli connection up $PROFILE the profile activates despite not having a session. If you then $ ssh guest@localhost nmcli device you'll still see the profile active. However, the moment the SSH session ends, a session closes and the profile disconnects. It's unclear, how to solve that any better. I think, a user who cares about this, should not activate the profile without having a session in the first place. There are quite some special cases, in particular with internal activations. In those cases we need to decide whether to bind the activation to the profile's visibility. Also, expose the "bind" setting in the D-Bus API. Note, that in the future this flag may be modified via D-Bus API. Like we may also add related API that allows to tweak the lifetime of the activation. Also, I think we broke handling of connection visiblity with 37e8c53eeed "core: Introduce helper class to track connection keep alive". This should be fixed now too, with improved behavior. Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394 https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
_activation_bind_lifetime_to_profile_visibility (subject),
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
&error);
if (!active)
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
goto error;
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
keep-alive: use NMKeepAlive API directly instead of via NMActiveConnection NMKeepAlive is a proper GObject type, with a specific API that on the one end allows to configure watches/bindings, and on the other end exposes and is-alive property and the owner instance. That's great, as NMActiveConnection is not concerned with either end (moving complexity away from "nm-active-connection.c") and as we later can reuse NMKeepAlive with NMSettingsConnection. However, we don't need to wrap this API by NMActiveConnection. Doing so means, we need to expose all the watch/bind functions also as part of NMActiveConnection API. The only ugliness here is, that NMPolicy subscribes to property changed signal of the keep alive instance, which would fail horribly if NMActiveConnection ever decides to swap the keep alive instance (in which case NMPolicy would have to disconnect the signal, and possibly reconnect it to another NMKeepAlive instance). We avoid that by just not doing that and documenting it.
2018-11-20 14:51:22 +01:00
if (bind_dbus_client) {
NMKeepAlive *keep_alive;
keep_alive = nm_active_connection_get_keep_alive (active);
nm_keep_alive_set_dbus_client_watch (keep_alive, dbus_connection, sender);
nm_keep_alive_arm (keep_alive);
}
core: Add option to AddAndActivateConnection2 to bind the lifetime This allows binding the lifetime of the created connection to the existance of the requesting dbus client. This feature is useful if one has a service specific connection (e.g. P2P wireless) which will not be useful without the specific service. This is simply a mechanism to ensure proper connection cleanup if the requesting service has a failure.
2018-10-26 13:17:31 +02:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
nm_active_connection_authorize (active,
incompl_conn,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
_async_op_complete_ac_auth_cb,
_async_op_data_new_ac_auth_add_and_activate (self,
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
async_op_type,
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
active,
invocation,
core: Add persist option to AddAndActivateConnection2 This option allows setting the rules for how long the connection should be stored. Valid values are "disk" (the default), "memory" and "volatile". If "memory" or "volatile" is selected, the connection will not be saved to disk and with "volatile" it will be automatically removed when it is deactivated again.
2018-10-25 16:54:37 +02:00
incompl_conn,
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
persist_mode,
is_volatile));
manager: use cleanup attribute in impl_manager_add_and_activate_connection() and related Also, in _add_and_activate_auth_done(), always steal the connection from active's user-data. Otherwise, the lifetime of the connection is extended until active gets destroyed. For example, if we would leak active, we would also leak connection that way.
2018-04-12 12:01:25 +02:00
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
/* we passed the pointers on to _async_op_data_new_ac_auth_add_and_activate() */
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
g_steal_pointer (&incompl_conn);
manager: use cleanup attribute in impl_manager_add_and_activate_connection() and related Also, in _add_and_activate_auth_done(), always steal the connection from active's user-data. Otherwise, the lifetime of the connection is extended until active gets destroyed. For example, if we would leak active, we would also leak connection that way.
2018-04-12 12:01:25 +02:00
g_steal_pointer (&active);
core: kill PendingActivation and move authorization to NMActiveConnection 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).
2013-08-28 16:19:20 -05:00
return;
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
core: move connection completion code closer to callers 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.
2012-09-13 13:17:46 -05:00
error:
audit: log changed properties when updating a connection The main purpose of audit logging is to understand who did what to the system configuration, so it is useful to log also the list of changed properties when a connection is updated: op="connection-update" uuid="2f3e48fc-5f47-41d9-9278-d2871378df43" name="pppoe1" args="pppoe.username,pppoe.password" <======== pid=9523 uid=1001 result="success"
2016-04-20 12:10:55 +02:00
nm_audit_log_connection_op (NM_AUDIT_OP_CONN_ADD_ACTIVATE, NULL, FALSE, NULL, subject, error->message);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_take_error (invocation, error);
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: more flattening of PendingActivation objects 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.
2012-09-13 16:51:58 -05:00
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
gboolean
nm_manager_deactivate_connection (NMManager *manager,
manager: avoid an extra path to ac translation The ac might already be unexported which would lead to a crash. In any case, it's just unnecessary.
2017-01-26 14:20:01 +01:00
NMActiveConnection *active,
2008-10-11 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h introspection/nm-device.xml include/NetworkManagerVPN.h - Add a few more state reasons for the device deactivated state * src/nm-device-interface.c src/nm-device-interface.h - (nm_device_interface_deactivate): add a 'reason' argument * src/nm-device.c src/nm-device.h - (nm_device_deactivate, nm_device_take_down): add a 'reason' argument - (nm_device_state_changed): pass the state change reason to nm_device_take_down() - (nm_device_set_managed): take a 'reason' argument, and pass it along to the state change function * src/nm-manager.c src/nm-manager.h - (remove_one_device, handle_unmanaged_devices, sync_devices, impl_manager_sleep): pass a reason code to nm_device_set_managed() - (nm_manager_deactivate_connection): add a 'reason' argument and pass something reasonable along to VPN deactivation * src/vpn-manager/nm-vpn-manager.c src/vpn-manager/nm-vpn-manager.h - (nm_vpn_manager_deactivate_connection): add a 'reason' argument and pass that along to nm_vpn_connection_disconnect() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4174 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-10-11 19:57:45 +00:00
NMDeviceStateReason reason,
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
GError **error)
2007-10-03 Dan Williams <dcbw@redhat.com> Add a GetActiveConnections() method on the Manager object. * src/nm-manager.c src/nm-manager.h introspection/nm-manager.xml - (connection_get_settings_cb): keep connection type around too - (impl_manager_get_active_connections, add_one_connection_element): implement; returns all active connections and what devices they apply to * libnm-glib/nm-client.c libnm-glib/nm-client.h introspection/nm-manager-client.xml - (nm_client_get_devices): GPtrArray elements are allocated and owned by the caller; free here to avoid memory leak - (nm_client_get_active_connections): implement; return the list of active connections - (nm_client_free_active_connection_element): implement; free an element of the GSList returned by nm_client_get_active_connections() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2927 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-10-03 14:48:25 +00:00
{
core: simplify looking up NMActiveConnection objects by object path
2012-09-14 15:21:29 -05:00
if (NM_IS_VPN_CONNECTION (active)) {
vpn-connection: use NMActiveConnectionStateReason
2017-03-11 14:39:07 +01:00
NMActiveConnectionStateReason vpn_reason = NM_ACTIVE_CONNECTION_STATE_REASON_USER_DISCONNECTED;
2007-10-03 Dan Williams <dcbw@redhat.com> Add a GetActiveConnections() method on the Manager object. * src/nm-manager.c src/nm-manager.h introspection/nm-manager.xml - (connection_get_settings_cb): keep connection type around too - (impl_manager_get_active_connections, add_one_connection_element): implement; returns all active connections and what devices they apply to * libnm-glib/nm-client.c libnm-glib/nm-client.h introspection/nm-manager-client.xml - (nm_client_get_devices): GPtrArray elements are allocated and owned by the caller; free here to avoid memory leak - (nm_client_get_active_connections): implement; return the list of active connections - (nm_client_free_active_connection_element): implement; free an element of the GSList returned by nm_client_get_active_connections() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2927 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-10-03 14:48:25 +00:00
device: mark uses of device's state-reason with nm_device_state_reason_check() The state-change of a device has a reason argument, which is mostly for information only. There are many places in code that are the source of a state-reason. Mostly these are calls to: - nm_device_state_changed() - nm_device_queue_state() - nm_device_queue_recheck_available() - nm_device_set_unmanaged_by_*() - nm_device_master_release_one_slave() - nm_device_ip_method_failed() - nm_modem_emit_prepare_result() - nm_modem_emit_ppp_failed() - nm_manager_deactivate_connection() - NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_*); However, there are a few places in code that look at the reason to decide how to proceed. I think this is a bad pattern, because cause and effect are decoupled and it gets hard to understand where a certain reason is set and what consequences that has. Add a nop-function nm_device_state_reason_check() to mark all uses of the device state reason that derive decisions from it. That is, highlight the "effect" part.
2017-02-23 15:19:03 +01:00
if (nm_device_state_reason_check (reason) == NM_DEVICE_STATE_REASON_CONNECTION_REMOVED)
vpn-connection: use NMActiveConnectionStateReason
2017-03-11 14:39:07 +01:00
vpn_reason = NM_ACTIVE_CONNECTION_STATE_REASON_CONNECTION_REMOVED;
device: mark uses of device's state-reason with nm_device_state_reason_check() The state-change of a device has a reason argument, which is mostly for information only. There are many places in code that are the source of a state-reason. Mostly these are calls to: - nm_device_state_changed() - nm_device_queue_state() - nm_device_queue_recheck_available() - nm_device_set_unmanaged_by_*() - nm_device_master_release_one_slave() - nm_device_ip_method_failed() - nm_modem_emit_prepare_result() - nm_modem_emit_ppp_failed() - nm_manager_deactivate_connection() - NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_*); However, there are a few places in code that look at the reason to decide how to proceed. I think this is a bad pattern, because cause and effect are decoupled and it gets hard to understand where a certain reason is set and what consequences that has. Add a nop-function nm_device_state_reason_check() to mark all uses of the device state reason that derive decisions from it. That is, highlight the "effect" part.
2017-02-23 15:19:03 +01:00
manager: fail early from nm_manager_deactivate_connection() Drop the @success variable, and just return on error right away.
2018-11-20 14:38:38 +01:00
if (!nm_vpn_connection_deactivate (NM_VPN_CONNECTION (active), vpn_reason, FALSE)) {
core: set GError on failure in nm_manager_deactivate_connection() (rh #976627) It fixes NM crash (abort) when VPN connection can't be disconnected.
2013-06-28 14:04:29 +02:00
g_set_error_literal (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_CONNECTION_NOT_ACTIVE,
"The VPN connection was not active.");
manager: fail early from nm_manager_deactivate_connection() Drop the @success variable, and just return on error right away.
2018-11-20 14:38:38 +01:00
return FALSE;
}
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
} else {
manager: use nm_device_disconnect_active_connection() in nm_manager_deactivate_connection() We should not blindly change the device's state. Instead, call nm_device_disconnect_active_connection() which will figure out whether the device state needs to change. Note that it is very possible that the active-connection instance is still queued, not yet queued, or already disconnected. nm_device_disconnect_active_connection() does the right thing in all cases.
2018-11-20 14:41:14 +01:00
nm_assert (NM_IS_ACT_REQUEST (active));
nm_device_disconnect_active_connection (active,
reason,
NM_ACTIVE_CONNECTION_STATE_REASON_UNKNOWN);
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
}
manager: fail early from nm_manager_deactivate_connection() Drop the @success variable, and just return on error right away.
2018-11-20 14:38:38 +01:00
_notify (manager, PROP_ACTIVE_CONNECTIONS);
return TRUE;
2008-03-26 Dan Williams <dcbw@redhat.com> Rework VPN connection handling for a more consistent D-Bus API. The VPNManager object has been removed, and active VPN connections are now the same as any other active connection. The Manager object's ActivateConnection and DeactivateConnection methods are used to start and stop a VPN connection, and the VPNConnection objects are subclasses of the ActiveConnection objects. When activating a VPN connection, pass the path of the active connection to which the VPN connection is tied in the 'specific_object' argument. Consequently, the libnm-glib API has been reworked to match this arrangement, with the VPNManager object removed, and the NMVPNConnection objects now being subclasses of NMActiveConnection. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-26 13:43:01 +00:00
}
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
static void
deactivate_net_auth_done_cb (NMAuthChain *chain,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
gpointer user_data)
{
NMManager *self = NM_MANAGER (user_data);
core: consolidate PolicyKit code Use one global PolkitAuthority object; we only really need to use it in one place anyway. So consolidate the code that uses polkit into nm-manager-auth.c.
2011-05-18 22:20:24 -05:00
GError *error = NULL;
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
NMAuthCallResult result;
manager: add audit support
2015-07-14 10:26:54 +02:00
NMActiveConnection *active;
char *path;
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
nm_assert (G_IS_DBUS_METHOD_INVOCATION (context));
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_unlink (nm_auth_chain_parent_lst_list (chain));
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
manager: add audit support
2015-07-14 10:26:54 +02:00
path = nm_auth_chain_get_data (chain, "path");
core: use same codepaths for root and non-root during authentication 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.
2012-10-08 12:52:15 -05:00
result = nm_auth_chain_get_result (chain, NM_AUTH_PERMISSION_NETWORK_CONTROL);
manager: avoid an extra path to ac translation The ac might already be unexported which would lead to a crash. In any case, it's just unnecessary.
2017-01-26 14:20:01 +01:00
active = active_connection_get_by_path (self, path);
core: use same codepaths for root and non-root during authentication 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.
2012-10-08 12:52:15 -05:00
core: remove unused error argument from NMAuthChainResultFunc NMAuthChain usually requests several permissions at once. Hence, an error argument in the overall callback does not make sense, because you wouldn't know which request failed. If at all, it could only mean that the overall request failed (like an D-Bus failure communicating to D-Bus *for all permisssions*), but we don't need to handle that specially. In fact, we don't really care why permission was not granted, whether it's due to an error or legitimate reasons. The error in the callback was always set to %NULL. Remove it.
2019-05-04 09:37:54 +02:00
if (result != NM_AUTH_CALL_RESULT_YES) {
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
"Not authorized to deactivate connections");
manager: avoid an extra path to ac translation The ac might already be unexported which would lead to a crash. In any case, it's just unnecessary.
2017-01-26 14:20:01 +01:00
} else if (!active) {
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_CONNECTION_NOT_ACTIVE,
"The connection was not active.");
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
} else {
/* success; deactivation allowed */
core: consolidate PolicyKit code Use one global PolkitAuthority object; we only really need to use it in one place anyway. So consolidate the code that uses polkit into nm-manager-auth.c.
2011-05-18 22:20:24 -05:00
if (!nm_manager_deactivate_connection (self,
manager: avoid an extra path to ac translation The ac might already be unexported which would lead to a crash. In any case, it's just unnecessary.
2017-01-26 14:20:01 +01:00
active,
core: consolidate PolicyKit code Use one global PolkitAuthority object; we only really need to use it in one place anyway. So consolidate the code that uses polkit into nm-manager-auth.c.
2011-05-18 22:20:24 -05:00
NM_DEVICE_STATE_REASON_USER_REQUESTED,
&error))
all: clean-up usage of GError Functions that take a GError** MUST fill it in on error. There is no need to check whether error is NULL if the function it was passed to had a failing return value. Likewise, a proper GError must have a non-NULL message, so there's no need to double-check that either. Based-on-patch-by: Dan Winship <danw@gnome.org>
2016-02-28 16:25:36 +01:00
nm_assert (error);
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
}
manager: add audit support
2015-07-14 10:26:54 +02:00
if (active) {
nm_audit_log_connection_op (NM_AUDIT_OP_CONN_DEACTIVATE,
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
nm_active_connection_get_settings_connection (active),
manager: add audit support
2015-07-14 10:26:54 +02:00
!error,
audit: log changed properties when updating a connection The main purpose of audit logging is to understand who did what to the system configuration, so it is useful to log also the list of changed properties when a connection is updated: op="connection-update" uuid="2f3e48fc-5f47-41d9-9278-d2871378df43" name="pppoe1" args="pppoe.username,pppoe.password" <======== pid=9523 uid=1001 result="success"
2016-04-20 12:10:55 +02:00
NULL,
manager: add audit support
2015-07-14 10:26:54 +02:00
nm_auth_chain_get_subject (chain),
error ? error->message : NULL);
}
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
if (error)
g_dbus_method_invocation_take_error (context, error);
else
g_dbus_method_invocation_return_value (context, NULL);
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
}
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_deactivate_connection (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *dbus_connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core/manager: use active_connection_get_by_path() in impl_manager_deactivate_connection()
2015-08-12 18:29:10 +02:00
NMActiveConnection *ac;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
NMSettingsConnection *sett_conn = NULL;
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
GError *error = NULL;
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
NMAuthSubject *subject = NULL;
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
NMAuthChain *chain;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
const char *active_path;
g_variant_get (parameters, "(&o)", &active_path);
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
/* Find the connection by its object path */
core/manager: use active_connection_get_by_path() in impl_manager_deactivate_connection()
2015-08-12 18:29:10 +02:00
ac = active_connection_get_by_path (self, active_path);
if (ac)
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
sett_conn = nm_active_connection_get_settings_connection (ac);
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (!sett_conn) {
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_CONNECTION_NOT_ACTIVE,
"The connection was not active.");
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
goto done;
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
}
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
/* Validate the caller */
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
subject = nm_auth_subject_new_unix_process_from_context (invocation);
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
if (!subject) {
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_UID_UKNOWN);
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
goto done;
}
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (!nm_auth_is_subject_in_acl_set_error (nm_settings_connection_get_connection (sett_conn),
core: cleanup code by using nm_auth_is_subject_in_acl_set_error()
2018-04-12 09:48:16 +02:00
subject,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
&error))
core: respect connection user permissions for activation/deactivation 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
2014-01-17 11:18:23 -06:00
goto done;
auth: move common nm_dbus_manager_get_caller_info() functionality into nm_auth_chain_new() 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.
2012-12-16 12:30:41 -06:00
/* Validate the user request */
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
chain = nm_auth_chain_new_subject (subject, invocation, deactivate_net_auth_done_cb, self);
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
if (!chain) {
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_AUTH_FAILED);
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
goto done;
core: PolicyKit protect Deactivate and Disconnect
2010-06-04 00:42:10 -07:00
}
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
nm_auth_chain_set_data (chain, "path", g_strdup (active_path), g_free);
nm_auth_chain_add_call (chain, NM_AUTH_PERMISSION_NETWORK_CONTROL, TRUE);
done:
manager: add audit support
2015-07-14 10:26:54 +02:00
if (error) {
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (sett_conn) {
nm_audit_log_connection_op (NM_AUDIT_OP_CONN_DEACTIVATE,
sett_conn, FALSE, NULL,
manager: add audit support
2015-07-14 10:26:54 +02:00
subject, error->message);
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_take_error (invocation, error);
manager: add audit support
2015-07-14 10:26:54 +02:00
}
g_clear_object (&subject);
2007-10-03 Dan Williams <dcbw@redhat.com> Add a GetActiveConnections() method on the Manager object. * src/nm-manager.c src/nm-manager.h introspection/nm-manager.xml - (connection_get_settings_cb): keep connection type around too - (impl_manager_get_active_connections, add_one_connection_element): implement; returns all active connections and what devices they apply to * libnm-glib/nm-client.c libnm-glib/nm-client.h introspection/nm-manager-client.xml - (nm_client_get_devices): GPtrArray elements are allocated and owned by the caller; free here to avoid memory leak - (nm_client_get_active_connections): implement; return the list of active connections - (nm_client_free_active_connection_element): implement; free an element of the GSList returned by nm_client_get_active_connections() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2927 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-10-03 14:48:25 +00:00
}
manager: disconnect devices before unmanaging them on suspend/sleep So that dispatcher scripts are run and other applications notified of the change in connectivity. https://bugzilla.redhat.com/show_bug.cgi?id=1330694 https://bugzilla.gnome.org/show_bug.cgi?id=748531
2016-05-05 14:14:40 +02:00
static gboolean
sleep_devices_add (NMManager *self, NMDevice *device, gboolean suspending)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMSleepMonitorInhibitorHandle *handle = NULL;
if (g_hash_table_lookup_extended (priv->sleep_devices, device, NULL, (gpointer *) &handle)) {
if (suspending) {
/* if we are suspending, always insert a new handle in sleep_devices.
* Even if we had an old handle, it might be stale by now. */
g_hash_table_insert (priv->sleep_devices, device,
nm_sleep_monitor_inhibit_take (priv->sleep_monitor));
if (handle)
nm_sleep_monitor_inhibit_release (priv->sleep_monitor, handle);
}
return FALSE;
}
g_hash_table_insert (priv->sleep_devices,
g_object_ref (device),
suspending
? nm_sleep_monitor_inhibit_take (priv->sleep_monitor)
: NULL);
g_signal_connect (device, "notify::" NM_DEVICE_STATE, (GCallback) device_sleep_cb, self);
return TRUE;
}
static gboolean
sleep_devices_remove (NMManager *self, NMDevice *device)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMSleepMonitorInhibitorHandle *handle;
if (!g_hash_table_lookup_extended (priv->sleep_devices, device, NULL, (gpointer *) &handle))
return FALSE;
if (handle)
nm_sleep_monitor_inhibit_release (priv->sleep_monitor, handle);
/* Remove device from hash */
g_signal_handlers_disconnect_by_func (device, device_sleep_cb, self);
g_hash_table_remove (priv->sleep_devices, device);
g_object_unref (device);
return TRUE;
}
static void
sleep_devices_clear (NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMDevice *device;
NMSleepMonitorInhibitorHandle *handle;
GHashTableIter iter;
if (!priv->sleep_devices)
return;
g_hash_table_iter_init (&iter, priv->sleep_devices);
while (g_hash_table_iter_next (&iter, (gpointer *) &device, (gpointer *) &handle)) {
g_signal_handlers_disconnect_by_func (device, device_sleep_cb, self);
if (handle)
nm_sleep_monitor_inhibit_release (priv->sleep_monitor, handle);
g_object_unref (device);
g_hash_table_iter_remove (&iter);
}
}
static void
device_sleep_cb (NMDevice *device,
GParamSpec *pspec,
NMManager *self)
{
switch (nm_device_get_state (device)) {
case NM_DEVICE_STATE_DISCONNECTED:
_LOGD (LOGD_SUSPEND, "sleep: unmanaging device %s", nm_device_get_ip_iface (device));
nm_device_set_unmanaged_by_flags_queue (device,
NM_UNMANAGED_SLEEPING,
TRUE,
NM_DEVICE_STATE_REASON_SLEEPING);
break;
case NM_DEVICE_STATE_UNMANAGED:
_LOGD (LOGD_SUSPEND, "sleep: device %s is ready", nm_device_get_ip_iface (device));
if (!sleep_devices_remove (self, device))
g_return_if_reached ();
break;
default:
return;
}
}
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
static void
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
do_sleep_wake (NMManager *self, gboolean sleeping_changed)
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
{
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
gboolean suspending, waking_from_suspend;
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *device;
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
suspending = sleeping_changed && priv->sleeping;
waking_from_suspend = sleeping_changed && !priv->sleeping;
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
if (manager_sleeping (self)) {
core: avoid duplicate <info> logging message when sleeping/waking <debug> [1511941494.1809] manager: Received resuming signal <info> [1511941494.1809] manager: wake requested (sleeping: yes enabled: yes) <info> [1511941494.1809] manager: waking up...
2017-11-29 09:42:39 +01:00
_LOGD (LOGD_SUSPEND, "sleep: %s...", suspending ? "sleeping" : "disabling");
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
/* FIXME: are there still hardware devices that need to be disabled around
* suspend/resume?
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
*/
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
manager: unmanage software devices when networking gets disabled If a user disables networking, we consider that as an indication that also software devices must be disconnected. OTOH, we don't want to destroy them for external events as a system suspend.
2019-04-23 15:30:53 +02:00
if (nm_device_is_software (device)) {
/* If a user disables networking we consider that as an
* indication that also software devices must be disconnected.
* But we don't want to destroy them for external events as
* a system suspend.
*/
if (suspending)
continue;
}
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
/* Wake-on-LAN devices will be taken down post-suspend rather than pre- */
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
if ( suspending
&& device_is_wake_on_lan (priv->platform, device)) {
manager: disconnect devices before unmanaging them on suspend/sleep So that dispatcher scripts are run and other applications notified of the change in connectivity. https://bugzilla.redhat.com/show_bug.cgi?id=1330694 https://bugzilla.gnome.org/show_bug.cgi?id=748531
2016-05-05 14:14:40 +02:00
_LOGD (LOGD_SUSPEND, "sleep: device %s has wake-on-lan, skipping",
nm_device_get_ip_iface (device));
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
continue;
manager: disconnect devices before unmanaging them on suspend/sleep So that dispatcher scripts are run and other applications notified of the change in connectivity. https://bugzilla.redhat.com/show_bug.cgi?id=1330694 https://bugzilla.gnome.org/show_bug.cgi?id=748531
2016-05-05 14:14:40 +02:00
}
if (nm_device_is_activating (device) ||
nm_device_get_state (device) == NM_DEVICE_STATE_ACTIVATED) {
_LOGD (LOGD_SUSPEND, "sleep: wait disconnection of device %s",
nm_device_get_ip_iface (device));
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
manager: disconnect devices before unmanaging them on suspend/sleep So that dispatcher scripts are run and other applications notified of the change in connectivity. https://bugzilla.redhat.com/show_bug.cgi?id=1330694 https://bugzilla.gnome.org/show_bug.cgi?id=748531
2016-05-05 14:14:40 +02:00
if (sleep_devices_add (self, device, suspending))
nm_device_queue_state (device, NM_DEVICE_STATE_DEACTIVATING, NM_DEVICE_STATE_REASON_SLEEPING);
} else {
nm_device_set_unmanaged_by_flags (device, NM_UNMANAGED_SLEEPING, TRUE, NM_DEVICE_STATE_REASON_SLEEPING);
}
core: when suspending, don't take down virtual devices (rh #1038158) 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.)
2013-12-17 14:24:39 -05:00
}
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
} else {
core: avoid duplicate <info> logging message when sleeping/waking <debug> [1511941494.1809] manager: Received resuming signal <info> [1511941494.1809] manager: wake requested (sleeping: yes enabled: yes) <info> [1511941494.1809] manager: waking up...
2017-11-29 09:42:39 +01:00
_LOGD (LOGD_SUSPEND, "sleep: %s...", waking_from_suspend ? "waking up" : "re-enabling");
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
if (waking_from_suspend) {
manager: disconnect devices before unmanaging them on suspend/sleep So that dispatcher scripts are run and other applications notified of the change in connectivity. https://bugzilla.redhat.com/show_bug.cgi?id=1330694 https://bugzilla.gnome.org/show_bug.cgi?id=748531
2016-05-05 14:14:40 +02:00
sleep_devices_clear (self);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
if (nm_device_is_software (device))
continue;
manager: fix state transition on resuming from sleep When going to sleep, we unmanage devices setting the unmanaged flags immediately but delaying the state transition (because we do it from another state transition). The signal handler can be executed after the wake and, especially, after we have already re-managed the device, making the device unmanaged again. Detect such situation and force the state to UNMANAGED (which will also clear any pending state change), so that later we manage the device again and it will try to activate any available connection. Fixes: 81ea812362de2757979e2c675774fc445400c59f https://bugzilla.redhat.com/show_bug.cgi?id=1382526
2016-11-16 11:46:29 +01:00
/* Belatedly take down Wake-on-LAN devices; ideally we wouldn't have to do this
* but for now it's the only way to make sure we re-check their connectivity.
*/
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
if (device_is_wake_on_lan (priv->platform, device))
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_by_flags (device, NM_UNMANAGED_SLEEPING, TRUE, NM_DEVICE_STATE_REASON_SLEEPING);
manager: fix state transition on resuming from sleep When going to sleep, we unmanage devices setting the unmanaged flags immediately but delaying the state transition (because we do it from another state transition). The signal handler can be executed after the wake and, especially, after we have already re-managed the device, making the device unmanaged again. Detect such situation and force the state to UNMANAGED (which will also clear any pending state change), so that later we manage the device again and it will try to activate any available connection. Fixes: 81ea812362de2757979e2c675774fc445400c59f https://bugzilla.redhat.com/show_bug.cgi?id=1382526
2016-11-16 11:46:29 +01:00
/* Check if the device is unmanaged but the state transition is still pending.
* If so, change state now so that later we re-manage the device forcing a
* re-check of available connections.
*/
if ( !nm_device_get_managed (device, FALSE)
&& nm_device_get_state (device) != NM_DEVICE_STATE_UNMANAGED) {
nm_device_state_changed (device, NM_DEVICE_STATE_UNMANAGED, NM_DEVICE_STATE_REASON_SLEEPING);
}
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
}
}
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
wifi: poll rfkill status for ipw2x00 devices The ipw2x00 drivers won't be converted over to the kernel's rfkill subsystem until 2.6.33, and thus listening for udev rfkill change events on these devices doesn't work. So until then, poll rfkill state for ipw2x00 devices every few seconds in addition to listening to other rfkill sources.
2009-11-24 10:43:43 -08:00
/* Ensure rfkill state is up-to-date since we don't respond to state
* changes during sleep.
*/
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
nm_manager_rfkill_update (self, RFKILL_TYPE_UNKNOWN);
wifi: poll rfkill status for ipw2x00 devices The ipw2x00 drivers won't be converted over to the kernel's rfkill subsystem until 2.6.33, and thus listening for udev rfkill change events on these devices doesn't work. So until then, poll rfkill state for ipw2x00 devices every few seconds in addition to listening to other rfkill sources.
2009-11-24 10:43:43 -08:00
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
/* Re-manage managed devices */
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
guint i;
wifi: ensure wifi devices are enabled on wakeup if not rfkilled Since rfkill state is saved but not acted upon during sleep (since NM shouldn't be touching devices while sleeping) we have to remember to act on the new state when waking up.
2009-11-20 09:11:46 -08:00
manager: clear unmanaged-sleeping flag on software devices on resume When networking is disabled at NM startup we unmanage all devices (including software ones) due to SLEEPING. After networking gets enabled again we must clear the unmanaged-sleeping flag on software devices.
2019-04-23 16:39:17 +02:00
if ( nm_device_is_software (device)
&& !nm_device_get_unmanaged_flags (device, NM_UNMANAGED_SLEEPING)) {
/* DHCP leases of software devices could have gone stale
* so we need to renew them. */
device: renew dhcp leases on awake for software devices This makes sure that devices like bond get their dhcp renewed [thaller@redhat.com: original patch modified to rename now-public function update_dynamic_ip_setup()] https://bugzilla.gnome.org/show_bug.cgi?id=764398
2016-03-26 01:26:36 -04:00
nm_device_update_dynamic_ip_setup (device);
core: when suspending, don't take down virtual devices (rh #1038158) 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.)
2013-12-17 14:24:39 -05:00
continue;
device: renew dhcp leases on awake for software devices This makes sure that devices like bond get their dhcp renewed [thaller@redhat.com: original patch modified to rename now-public function update_dynamic_ip_setup()] https://bugzilla.gnome.org/show_bug.cgi?id=764398
2016-03-26 01:26:36 -04:00
}
core: when suspending, don't take down virtual devices (rh #1038158) 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.)
2013-12-17 14:24:39 -05:00
wifi: ensure wifi devices are enabled on wakeup if not rfkilled Since rfkill state is saved but not acted upon during sleep (since NM shouldn't be touching devices while sleeping) we have to remember to act on the new state when waking up.
2009-11-20 09:11:46 -08:00
/* enable/disable wireless devices since that we don't respond
* to killswitch changes during sleep.
*/
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
for (i = 0; i < RFKILL_TYPE_MAX; i++) {
RadioState *rstate = &priv->radio_states[i];
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
gboolean enabled = radio_enabled_for_rstate (rstate, TRUE);
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
wifi: fix disabled wifi devices on resume (rh #578141) RFKILL_TYPE_WLAN is 0, and we while we had allocated the structure for WIMAX rfkill in the manager's priv->radio_states, we hadn't filled it in. That meant that priv->radio_states[RFKILL_TYPE_WIMAX].rtype was 0, and thus various operations thought that wifi devices were wimax devices, and since WiMAX rfkill is never updated because it's not yet used, wifi would never be enabled after resume.
2010-04-08 18:23:43 -07:00
if (rstate->desc) {
manager: add "rfkill" prefix to related logging messages
2017-06-07 13:13:55 +02:00
_LOGD (LOGD_RFKILL, "rfkill: %s %s devices (hw_enabled %d, sw_enabled %d, user_enabled %d)",
manager: use logging helpers
2016-03-02 11:38:26 +01:00
enabled ? "enabling" : "disabling",
rstate->desc, rstate->hw_enabled, rstate->sw_enabled, rstate->user_enabled);
wifi: fix disabled wifi devices on resume (rh #578141) RFKILL_TYPE_WLAN is 0, and we while we had allocated the structure for WIMAX rfkill in the manager's priv->radio_states, we hadn't filled it in. That meant that priv->radio_states[RFKILL_TYPE_WIMAX].rtype was 0, and thus various operations thought that wifi devices were wimax devices, and since WiMAX rfkill is never updated because it's not yet used, wifi would never be enabled after resume.
2010-04-08 18:23:43 -07:00
}
core: clean up per-device rfkill handling Add an accessor for device rfkill type and use that instead of GObject properties, and also use that accessor when claiming a new device instead of checking NM_IS_DEVICE_xxxx(). Allows us to move one step closer to making WiMAX a plugin.
2011-11-18 12:02:58 -06:00
if (nm_device_get_rfkill_type (device) == rstate->rtype)
core: move nm_device_interface_set_enabled() to nm-device.c
2011-11-17 23:38:08 -06:00
nm_device_set_enabled (device, enabled);
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
}
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_by_flags (device, NM_UNMANAGED_SLEEPING, FALSE, NM_DEVICE_STATE_REASON_NOW_MANAGED);
2008-05-22 Tambet Ingo <tambet@gmail.com> * src/nm-manager.c (impl_manager_sleep): No need to schedule the sync anymore, do it right away. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3681 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-05-22 14:27:40 +00:00
}
2007-02-08 Tambet Ingo <tambet@ximian.com> * src/NetworkManager.c: - Set up all the shiny new managers. * src/NetworkManagerPolicy.c: - Add the beginnings of new NMPolicy code. Instead of requireing all classes to call into policy code, make the policy code kind of like a supervisor that monitors what's going on and drives the whole NM. * src/nm-hal-manager.c: * src/nm-hal-manager.h: - Collect all libhal code scattered around NM to this one class. - Listen libhal and NMManager events and add/remove devices to NMManager. * src/nm-manager.c: * src/nm-manager.h: - Implment a replacement for NMData. NMData is now officially deprecated. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2291 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-08 15:34:26 +00:00
}
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
nm_manager_update_state (self);
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
}
core: PolicyKit-protect sleep/wake Default to 'not allowed', distros that need backwards compatibility can flip this to 'yes' if they need to. At this point, only power management scripts should call these functions.
2010-05-29 23:11:45 -07:00
static void
_internal_sleep (NMManager *self, gboolean do_sleep)
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
{
manager: use _LOGx() macros in nm-manager They give each logging message a "manager: " prefix.
2016-04-27 18:26:39 +02:00
NMManagerPrivate *priv;
g_return_if_fail (NM_IS_MANAGER (self));
priv = NM_MANAGER_GET_PRIVATE (self);
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
core: listen to UPower for suspend/resume signals This means you don't need pm-utils anymore, and that gnome-power-manager doesn't need to poke NM explicitly for suspend/resume operations. The old explicit sleep/wake request is still around for pm-utils or gpm to use, but NM will listen for UPower events and act on them regardless of what pm-utils or gpm do.
2010-08-31 15:45:55 -05:00
if (priv->sleeping == do_sleep)
return;
core: avoid duplicate <info> logging message when sleeping/waking <debug> [1511941494.1809] manager: Received resuming signal <info> [1511941494.1809] manager: wake requested (sleeping: yes enabled: yes) <info> [1511941494.1809] manager: waking up...
2017-11-29 09:42:39 +01:00
_LOGI (LOGD_SUSPEND, "sleep: %s requested (sleeping: %s enabled: %s)",
manager: use logging helpers
2016-03-02 11:38:26 +01:00
do_sleep ? "sleep" : "wake",
priv->sleeping ? "yes" : "no",
priv->net_enabled ? "yes" : "no");
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
core: don't shadow 'sleep'
2010-05-28 13:06:14 -07:00
priv->sleeping = do_sleep;
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
do_sleep_wake (self, TRUE);
core: clear invalid tag on failed connections when sleeping So they'll get tried again on wakeup/resume.
2009-10-20 15:25:04 -07:00
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
_notify (self, PROP_SLEEPING);
core: PolicyKit-protect sleep/wake Default to 'not allowed', distros that need backwards compatibility can flip this to 'yes' if they need to. At this point, only power management scripts should call these functions.
2010-05-29 23:11:45 -07:00
}
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_sleep (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: root can always enable/disable and sleep/wake
2010-05-30 08:30:37 -07:00
GError *error = NULL;
manager: add audit support
2015-07-14 10:26:54 +02:00
gs_unref_object NMAuthSubject *subject = NULL;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
gboolean do_sleep;
core: PolicyKit-protect sleep/wake Default to 'not allowed', distros that need backwards compatibility can flip this to 'yes' if they need to. At this point, only power management scripts should call these functions.
2010-05-29 23:11:45 -07:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_variant_get (parameters, "(b)", &do_sleep);
core: PolicyKit-protect sleep/wake Default to 'not allowed', distros that need backwards compatibility can flip this to 'yes' if they need to. At this point, only power management scripts should call these functions.
2010-05-29 23:11:45 -07:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
subject = nm_auth_subject_new_unix_process_from_context (invocation);
core: PolicyKit-protect sleep/wake Default to 'not allowed', distros that need backwards compatibility can flip this to 'yes' if they need to. At this point, only power management scripts should call these functions.
2010-05-29 23:11:45 -07:00
if (priv->sleeping == do_sleep) {
error = g_error_new (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_ALREADY_ASLEEP_OR_AWAKE,
"Already %s", do_sleep ? "asleep" : "awake");
manager: add audit support
2015-07-14 10:26:54 +02:00
nm_audit_log_control_op (NM_AUDIT_OP_SLEEP_CONTROL, do_sleep ? "on" : "off", FALSE, subject,
error->message);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_take_error (invocation, error);
core: PolicyKit-protect sleep/wake Default to 'not allowed', distros that need backwards compatibility can flip this to 'yes' if they need to. At this point, only power management scripts should call these functions.
2010-05-29 23:11:45 -07:00
return;
}
core: ignore authorization for sleep/wake requests (but restrict to root) (rh #638640) Everyone uses pm-utils still for sleep/wake support, and that's traditionally how NM was put to sleep and woken up. But pm-utils uses dbus-send without --print-reply so dbus-send quits immediately after sending the message. That doesn't give NM enough time to get the senders UID and thus validate the request, so the request gets denied, and sometimes NM stays asleep after the machine is woken up. Instead, don't get the sender's UID and try to authorize it, but just let the request go through. Rely on D-Bus permissions to make sure that only root can call sleep/wake methods.
2010-10-15 10:28:38 -05:00
/* Unconditionally allow the request. Previously it was polkit protected
* but unfortunately that doesn't work for short-lived processes like
* pm-utils. It uses dbus-send without --print-reply, which quits
* immediately after sending the request, and NM is unable to obtain the
* sender's UID as dbus-send has already dropped off the bus. Thus NM
* fails the request. Instead, don't validate the request, but rely on
* D-Bus permissions to restrict the call to root.
*/
_internal_sleep (self, do_sleep);
manager: add audit support
2015-07-14 10:26:54 +02:00
nm_audit_log_control_op (NM_AUDIT_OP_SLEEP_CONTROL, do_sleep ? "on" : "off", TRUE, subject, NULL);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_return_value (invocation, NULL);
core: ignore authorization for sleep/wake requests (but restrict to root) (rh #638640) Everyone uses pm-utils still for sleep/wake support, and that's traditionally how NM was put to sleep and woken up. But pm-utils uses dbus-send without --print-reply so dbus-send quits immediately after sending the message. That doesn't give NM enough time to get the senders UID and thus validate the request, so the request gets denied, and sometimes NM stays asleep after the machine is woken up. Instead, don't get the sender's UID and try to authorize it, but just let the request go through. Rely on D-Bus permissions to make sure that only root can call sleep/wake methods.
2010-10-15 10:28:38 -05:00
return;
2007-02-12 Tambet Ingo <tambet@ximian.com> Totally break NetworkManager. Please use 0.6 branch until futher notice. * src/: - Remove old low-level dbus interface implementations and replace them with dbus-glib one. * configure.in: - Require dbus-glib >= 0.72. - Plug in new sources to build. * libnm-glib/: - Implement GObject wrappers on top of DBUS glib auto-generated bindings to make it more convenient to use from GObject based programs. * introspection/: - Implement DBUS XML introspection files, used by both NM and libnm-glib. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2309 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-12 09:23:43 +00:00
}
core: listen to UPower for suspend/resume signals This means you don't need pm-utils anymore, and that gnome-power-manager doesn't need to poke NM explicitly for suspend/resume operations. The old explicit sleep/wake request is still around for pm-utils or gpm to use, but NM will listen for UPower events and act on them regardless of what pm-utils or gpm do.
2010-08-31 15:45:55 -05:00
static void
sleep-monitor: merge RESUMING signal into NMSleepMonitor's SLEEPING signal Having two signals is more complicated and everybody who cares about one signal also cares about the other.
2016-04-27 18:21:28 +02:00
sleeping_cb (NMSleepMonitor *monitor, gboolean is_about_to_suspend, gpointer user_data)
core: listen to UPower for suspend/resume signals This means you don't need pm-utils anymore, and that gnome-power-manager doesn't need to poke NM explicitly for suspend/resume operations. The old explicit sleep/wake request is still around for pm-utils or gpm to use, but NM will listen for UPower events and act on them regardless of what pm-utils or gpm do.
2010-08-31 15:45:55 -05:00
{
manager: use _LOGx() macros in nm-manager They give each logging message a "manager: " prefix.
2016-04-27 18:26:39 +02:00
NMManager *self = user_data;
core: avoid duplicate <info> logging message when sleeping/waking <debug> [1511941494.1809] manager: Received resuming signal <info> [1511941494.1809] manager: wake requested (sleeping: yes enabled: yes) <info> [1511941494.1809] manager: waking up...
2017-11-29 09:42:39 +01:00
_LOGT (LOGD_SUSPEND, "sleep: received %s signal", is_about_to_suspend ? "sleeping" : "resuming");
sleep-monitor: merge RESUMING signal into NMSleepMonitor's SLEEPING signal Having two signals is more complicated and everybody who cares about one signal also cares about the other.
2016-04-27 18:21:28 +02:00
_internal_sleep (self, is_about_to_suspend);
core: listen to UPower for suspend/resume signals This means you don't need pm-utils anymore, and that gnome-power-manager doesn't need to poke NM explicitly for suspend/resume operations. The old explicit sleep/wake request is still around for pm-utils or gpm to use, but NM will listen for UPower events and act on them regardless of what pm-utils or gpm do.
2010-08-31 15:45:55 -05:00
}
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
static void
_internal_enable (NMManager *self, gboolean enable)
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
{
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
core: rename nm_config_run_state* to nm_config_state* After all, this state is stored persistently to /var/lib/NetworkManager, and not to volatile storage in /var/run. Hence the name is better. It's also shorter, so rename it. The commit is mostly trivial, including update of code comments and logging messages. Fixes: 1b43c880ba43260fe551b0ac923826f16737484f
2016-04-07 18:42:24 +02:00
nm_config_state_set (priv->config, TRUE, FALSE,
NM_CONFIG_STATE_PROPERTY_NETWORKING_ENABLED, enable);
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGI (LOGD_SUSPEND, "%s requested (sleeping: %s enabled: %s)",
enable ? "enable" : "disable",
priv->sleeping ? "yes" : "no",
priv->net_enabled ? "yes" : "no");
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
priv->net_enabled = enable;
core: leave wake-on-LAN devices up over suspend/resume Taking down a wake-on-LAN device before suspending will effectively disable wake-on-LAN. So don't do that. Based on a patch from Stanislaw Gruszka. https://bugzilla.gnome.org/show_bug.cgi?id=712745 https://bugzilla.redhat.com/show_bug.cgi?id=826652 https://bugzilla.redhat.com/show_bug.cgi?id=1025009
2014-04-03 15:14:00 -04:00
do_sleep_wake (self, FALSE);
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
_notify (self, PROP_NETWORKING_ENABLED);
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
}
static void
enable_net_done_cb (NMAuthChain *chain,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
gpointer user_data)
{
NMManager *self = NM_MANAGER (user_data);
NMAuthCallResult result;
gboolean enable;
manager: add audit support
2015-07-14 10:26:54 +02:00
NMAuthSubject *subject;
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
nm_assert (G_IS_DBUS_METHOD_INVOCATION (context));
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_unlink (nm_auth_chain_parent_lst_list (chain));
manager: add audit support
2015-07-14 10:26:54 +02:00
enable = GPOINTER_TO_UINT (nm_auth_chain_get_data (chain, "enable"));
subject = nm_auth_chain_get_subject (chain);
core: simplify auth chain permission callback handling
2010-06-02 02:16:14 -07:00
core: use same codepaths for root and non-root during authentication 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.
2012-10-08 12:52:15 -05:00
result = nm_auth_chain_get_result (chain, NM_AUTH_PERMISSION_ENABLE_DISABLE_NETWORK);
core: remove unused error argument from NMAuthChainResultFunc NMAuthChain usually requests several permissions at once. Hence, an error argument in the overall callback does not make sense, because you wouldn't know which request failed. If at all, it could only mean that the overall request failed (like an D-Bus failure communicating to D-Bus *for all permisssions*), but we don't need to handle that specially. In fact, we don't really care why permission was not granted, whether it's due to an error or legitimate reasons. The error in the callback was always set to %NULL. Remove it.
2019-05-04 09:37:54 +02:00
if (result != NM_AUTH_CALL_RESULT_YES) {
GError *ret_error;
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
ret_error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
"Not authorized to enable/disable networking");
manager: add audit support
2015-07-14 10:26:54 +02:00
nm_audit_log_control_op (NM_AUDIT_OP_NET_CONTROL, enable ? "on" : "off", FALSE,
subject, ret_error->message);
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
g_dbus_method_invocation_take_error (context, ret_error);
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
return;
core: use same codepaths for root and non-root during authentication 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.
2012-10-08 12:52:15 -05:00
}
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
_internal_enable (self, enable);
g_dbus_method_invocation_return_value (context, NULL);
nm_audit_log_control_op (NM_AUDIT_OP_NET_CONTROL, enable ? "on" : "off", TRUE,
subject, NULL);
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
}
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_enable (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
NMAuthChain *chain;
core: root can always enable/disable and sleep/wake
2010-05-30 08:30:37 -07:00
GError *error = NULL;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
gboolean enable;
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_variant_get (parameters, "(b)", &enable);
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
if (priv->net_enabled == enable) {
error = g_error_new (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_ALREADY_ENABLED_OR_DISABLED,
"Already %s", enable ? "enabled" : "disabled");
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
goto done;
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
chain = nm_auth_chain_new_context (invocation, enable_net_done_cb, self);
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
if (!chain) {
core: root can always enable/disable and sleep/wake
2010-05-30 08:30:37 -07:00
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_AUTH_FAILED);
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
goto done;
core: root can always enable/disable and sleep/wake
2010-05-30 08:30:37 -07:00
}
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
nm_auth_chain_set_data (chain, "enable", GUINT_TO_POINTER (enable), NULL);
nm_auth_chain_add_call (chain, NM_AUTH_PERMISSION_ENABLE_DISABLE_NETWORK, TRUE);
done:
if (error)
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_take_error (invocation, error);
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
}
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
/* Permissions */
static void
get_permissions_done_cb (NMAuthChain *chain,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
gpointer user_data)
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
{
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GVariantBuilder results;
core: don't duplicate list of known permissions in impl_manager_get_permissions() Reuse the list of all permissions and don't duplicate it. Also, now the result of GetPermissions() on D-Bus contains the permissions sorted by name. We get it almost for free, and it's a nice property.
2019-12-05 14:55:28 +01:00
int i;
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
nm_assert (G_IS_DBUS_METHOD_INVOCATION (context));
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_unlink (nm_auth_chain_parent_lst_list (chain));
core: use same codepaths for root and non-root during authentication 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.
2012-10-08 12:52:15 -05:00
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
g_variant_builder_init (&results, G_VARIANT_TYPE ("a{ss}"));
core: use same codepaths for root and non-root during authentication 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.
2012-10-08 12:52:15 -05:00
core: don't duplicate list of known permissions in impl_manager_get_permissions() Reuse the list of all permissions and don't duplicate it. Also, now the result of GetPermissions() on D-Bus contains the permissions sorted by name. We get it almost for free, and it's a nice property.
2019-12-05 14:55:28 +01:00
for (i = 0; i < (int) G_N_ELEMENTS (nm_auth_permission_sorted); i++) {
const char *permission = nm_auth_permission_names_by_idx[nm_auth_permission_sorted[i] - 1];
NMAuthCallResult result;
core: use nm_client_permission_result_to_string() to map permission result In NetworkManager we have NMAuthCallResult, which is really a duplicate of NMClientPermissionResult. Maybe NMAuthCallResult should be entirely replaced by NMClientPermissionResult. But the name NMClientPermissionResult is a bit awkward. But then the duplication is even more awkward... fixing this is left for another day.
2019-12-05 15:20:18 +01:00
const char *result_str;
core: don't duplicate list of known permissions in impl_manager_get_permissions() Reuse the list of all permissions and don't duplicate it. Also, now the result of GetPermissions() on D-Bus contains the permissions sorted by name. We get it almost for free, and it's a nice property.
2019-12-05 14:55:28 +01:00
result = nm_auth_chain_get_result (chain, permission);
core: use nm_client_permission_result_to_string() to map permission result In NetworkManager we have NMAuthCallResult, which is really a duplicate of NMClientPermissionResult. Maybe NMAuthCallResult should be entirely replaced by NMClientPermissionResult. But the name NMClientPermissionResult is a bit awkward. But then the duplication is even more awkward... fixing this is left for another day.
2019-12-05 15:20:18 +01:00
result_str = nm_client_permission_result_to_string (nm_auth_call_result_to_client (result));
g_variant_builder_add (&results, "{ss}", permission, result_str);
core: don't duplicate list of known permissions in impl_manager_get_permissions() Reuse the list of all permissions and don't duplicate it. Also, now the result of GetPermissions() on D-Bus contains the permissions sorted by name. We get it almost for free, and it's a nice property.
2019-12-05 14:55:28 +01:00
}
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
g_dbus_method_invocation_return_value (context,
g_variant_new ("(a{ss})", &results));
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
}
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_get_permissions (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMAuthChain *chain;
core: don't duplicate list of known permissions in impl_manager_get_permissions() Reuse the list of all permissions and don't duplicate it. Also, now the result of GetPermissions() on D-Bus contains the permissions sorted by name. We get it almost for free, and it's a nice property.
2019-12-05 14:55:28 +01:00
int i;
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
chain = nm_auth_chain_new_context (invocation, get_permissions_done_cb, self);
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
if (!chain) {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_return_error_literal (invocation,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_AUTH_FAILED);
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
return;
core: use same codepaths for root and non-root during authentication 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.
2012-10-08 12:52:15 -05:00
}
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
core: don't duplicate list of known permissions in impl_manager_get_permissions() Reuse the list of all permissions and don't duplicate it. Also, now the result of GetPermissions() on D-Bus contains the permissions sorted by name. We get it almost for free, and it's a nice property.
2019-12-05 14:55:28 +01:00
for (i = 0; i < (int) G_N_ELEMENTS (nm_auth_permission_sorted); i++) {
const char *permission = nm_auth_permission_names_by_idx[nm_auth_permission_sorted[i] - 1];
nm_auth_chain_add_call_unsafe (chain, permission, FALSE);
}
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
}
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_state (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
core: bring the state() D-Bus method back It's a lot easier for app developers to use.
2011-03-08 12:57:35 -06:00
{
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMManager *self = NM_MANAGER (obj);
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
nm_manager_update_state (self);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_return_value (invocation,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
g_variant_new ("(u)", NM_MANAGER_GET_PRIVATE (self)->state));
core: bring the state() D-Bus method back It's a lot easier for app developers to use.
2011-03-08 12:57:35 -06:00
}
core: enforce permissions for SetLogging This was always protected by D-Bus policy permissions, but just to be paranoid, ensure it's also protected by explicit checks on the UID.
2014-01-22 13:07:24 -06:00
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_set_logging (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
core: enforce permissions for SetLogging This was always protected by D-Bus policy permissions, but just to be paranoid, ensure it's also protected by explicit checks on the UID.
2014-01-22 13:07:24 -06:00
GError *error = NULL;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
const char *level;
const char *domains;
core: enforce permissions for SetLogging This was always protected by D-Bus policy permissions, but just to be paranoid, ensure it's also protected by explicit checks on the UID.
2014-01-22 13:07:24 -06:00
core: check valid uid for D-Bus load_connection(s)/set_logging calls Commit 4c7fa8dfdcbf ("core: drop root requirement for load_connection(s)/set_logging D-Bus calls") removed the enforcing of permission in the daemon for such methods since the D-Bus daemon configuration already does that. That change also allows clients to send a request and not wait for a response, since we don't have to check the caller credentials in the daemon. In the future we might switch to polkit for these methods, breaking clients that don't wait for a reponse, so it seems better to prevent from beginning such behavior. Fixes: 4c7fa8dfdcbf13f3633b565af53896ac79366912 (cherry picked from commit dd27b79c4e726fca4a192b27453221d6942e4717)
2016-08-23 09:38:40 +02:00
/* The permission is already enforced by the D-Bus daemon, but we ensure
* that the caller is still alive so that clients are forced to wait and
* we'll be able to switch to polkit without breaking behavior.
*/
core: rework lookup for exported objects by path to use index We already track an index of exported objects in NMDBusManager. Actually, that index was unused previously. We either could drop it, or use it. Let's use it.
2018-03-23 21:49:41 +01:00
if (!nm_dbus_manager_ensure_uid (nm_dbus_object_get_manager (NM_DBUS_OBJECT (self)),
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
invocation,
G_MAXULONG,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED))
core: check valid uid for D-Bus load_connection(s)/set_logging calls Commit 4c7fa8dfdcbf ("core: drop root requirement for load_connection(s)/set_logging D-Bus calls") removed the enforcing of permission in the daemon for such methods since the D-Bus daemon configuration already does that. That change also allows clients to send a request and not wait for a response, since we don't have to check the caller credentials in the daemon. In the future we might switch to polkit for these methods, breaking clients that don't wait for a reponse, so it seems better to prevent from beginning such behavior. Fixes: 4c7fa8dfdcbf13f3633b565af53896ac79366912 (cherry picked from commit dd27b79c4e726fca4a192b27453221d6942e4717)
2016-08-23 09:38:40 +02:00
return;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_variant_get (parameters, "(&s&s)", &level, &domains);
core: enforce permissions for SetLogging This was always protected by D-Bus policy permissions, but just to be paranoid, ensure it's also protected by explicit checks on the UID.
2014-01-22 13:07:24 -06:00
if (nm_logging_setup (level, domains, NULL, &error)) {
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGI (LOGD_CORE, "logging: level '%s' domains '%s'",
nm_logging_level_to_string (), nm_logging_domains_to_string ());
logging: add D-Bus method to change logging
2010-04-08 08:56:17 -07:00
}
core: enforce permissions for SetLogging This was always protected by D-Bus policy permissions, but just to be paranoid, ensure it's also protected by explicit checks on the UID.
2014-01-22 13:07:24 -06:00
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
if (error)
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_take_error (invocation, error);
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
else
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_return_value (invocation, NULL);
logging: add D-Bus method to change logging
2010-04-08 08:56:17 -07:00
}
2007-08-14 Tambet Ingo <tambet@gmail.com> * libnm-glib/Makefile.am: Use nm-manager-client.xml to produce * nm-client-bindings. * introspection/nm-manager-client.xml: Add a horrible horrbile * hack to work around an issue with dbus-glib bindings generator. The issue is, the generated C caller functions for dbus methods "Sleep(bool)" and "sleep()" both have the same function name and different arguments and it won't compile anymore. To fix this, we now have two copies of nm-manager.xml file. nm-manager.xml contains the actual interface, that is new API + compatibility API and used by the daemon. The other, nm-manager-client.xml is only the new API without compatibility bits and is used by libnm-glib to make it compile. * introspection/nm-manager.xml: Define compatibility methods * (sleep, wake, state). * src/nm-manager.c (impl_manager_legacy_sleep) (impl_manager_legacy_wake, impl_manager_legacy_state): Implement the compatibility interface functions for 0.6 branch. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2688 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-08-15 07:52:25 +00:00
core: add GetLogging() D-Bus call to org.freedesktop.NetworkManager Returns current logging level and domains set.
2012-12-12 14:21:40 +01:00
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_get_logging (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
g_dbus_method_invocation_return_value (invocation,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
g_variant_new ("(ss)",
nm_logging_level_to_string (),
nm_logging_domains_to_string ()));
core: add GetLogging() D-Bus call to org.freedesktop.NetworkManager Returns current logging level and domains set.
2012-12-12 14:21:40 +01:00
}
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
typedef struct {
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
NMManager *self;
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
GDBusMethodInvocation *context;
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
guint remaining;
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
} ConnectivityCheckData;
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
static void
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
device_connectivity_done (NMDevice *device,
NMDeviceConnectivityHandle *handle,
NMConnectivityState state,
GError *error,
gpointer user_data)
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
{
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
ConnectivityCheckData *data = user_data;
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
NMManager *self;
NMManagerPrivate *priv;
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
nm_assert (data);
nm_assert (data->remaining > 0);
nm_assert (NM_IS_MANAGER (data->self));
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
data->remaining--;
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
self = data->self;
priv = NM_MANAGER_GET_PRIVATE (self);
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
if ( data->context
&& ( data->remaining == 0
|| ( state == NM_CONNECTIVITY_FULL
&& priv->connectivity_state == NM_CONNECTIVITY_FULL))) {
/* despite having a @handle and @state returned by the requests, we always
* return the current connectivity_state. That is, because the connectivity_state
* and the answer to the connectivity check shall agree.
*
* However, if one of the requests (early) returns full connectivity and agrees with
* the accumulated connectivity state, we no longer have to wait. The result is set.
*
all: replace "it's" with "its" where needed
2018-04-18 14:13:28 +02:00
* This also works well, because NMDevice first emits change signals to its own
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
* connectivity state, which is then taken into account for the accumulated global
* state. All this happens, before the callback is invoked. */
g_dbus_method_invocation_return_value (g_steal_pointer (&data->context),
g_variant_new ("(u)",
(guint) priv->connectivity_state));
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
}
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
if (data->remaining == 0) {
g_object_unref (self);
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
g_slice_free (ConnectivityCheckData, data);
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
}
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
}
static void
check_connectivity_auth_done_cb (NMAuthChain *chain,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
gpointer user_data)
{
NMManager *self = NM_MANAGER (user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
GError *error = NULL;
NMAuthCallResult result;
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
ConnectivityCheckData *data;
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
NMDevice *device;
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_unlink (nm_auth_chain_parent_lst_list (chain));
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
result = nm_auth_chain_get_result (chain, NM_AUTH_PERMISSION_NETWORK_CONTROL);
core: remove unused error argument from NMAuthChainResultFunc NMAuthChain usually requests several permissions at once. Hence, an error argument in the overall callback does not make sense, because you wouldn't know which request failed. If at all, it could only mean that the overall request failed (like an D-Bus failure communicating to D-Bus *for all permisssions*), but we don't need to handle that specially. In fact, we don't really care why permission was not granted, whether it's due to an error or legitimate reasons. The error in the callback was always set to %NULL. Remove it.
2019-05-04 09:37:54 +02:00
if (result != NM_AUTH_CALL_RESULT_YES) {
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
"Not authorized to recheck connectivity");
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
}
if (error) {
g_dbus_method_invocation_take_error (context, error);
core: don't call nm_auth_chain_destroy() from the callback NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
2019-05-02 10:08:09 +02:00
return;
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
}
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
data = g_slice_new (ConnectivityCheckData);
data->self = g_object_ref (self);
data->context = context;
data->remaining = 0;
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
connectivity: schedule connectivity timers per-device and probe for short outages It might happen, that connectivitiy is lost only for a moment and returns soon after. Based on that assumption, when we loose connectivity we want to have a probe interval where we check for returning connectivity more frequently. For that, we handle tracking of the timeouts per-device. The intervall shall start with 1 seconds, and double the interval time until the full interval is reached. Actually, due to the implementation, it's unlikely that we already perform the second check 1 second later. That is because commonly the first check returns before the one second timeout is reached and bumps the interval to 2 seconds right away. Also, we go through extra lengths so that manual connectivity check delay the periodic checks. By being more smart about that, we can reduce the number of connectivity checks, but still keeping the promise to check at least within the requested interval. The complexity of book keeping the timeouts is remarkable. But I think it is worth the effort and we should try hard to - have a connectivity state as accurate as possible. Clearly, connectivity checking means that we probing, so being more intelligent about timeout and backoff timers can result in a better connectivity state. The connectivity state is important because we use it for the default-route penaly and the GUI indicates bad connectivity. - be intelligent about avoiding redundant connectivity checks. While we want to check often to get an accurate connectivity state, we also want to minimize the number of HTTP requests, in case the connectivity is established and suppossedly stable. Also, perform connectivity checks in every state of the device. Even if a device is disconnected, it still might have connectivity, for example if the user externally adds an IP address on an unmanaged device. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-02-20 21:41:14 +01:00
if (nm_device_check_connectivity (device,
connectivity: allow limiting the connectivity check to a specified AF Nothing changes practically, as the NMDevice still starts this with AF_UNSPEC. That is going to change in the following commit. The ugly part: priv->concheck_x[0] in few places. I believe we shouldn't be using union aliasing here, and instead of indexing the v4/v6 arrays by a boolean it should be an enum. I'm not fixing it here, but I eventually plan to if this gets an ACK.
2018-07-03 19:20:45 +02:00
AF_INET,
device_connectivity_done,
data))
data->remaining++;
if (nm_device_check_connectivity (device,
AF_INET6,
connectivity: schedule connectivity timers per-device and probe for short outages It might happen, that connectivitiy is lost only for a moment and returns soon after. Based on that assumption, when we loose connectivity we want to have a probe interval where we check for returning connectivity more frequently. For that, we handle tracking of the timeouts per-device. The intervall shall start with 1 seconds, and double the interval time until the full interval is reached. Actually, due to the implementation, it's unlikely that we already perform the second check 1 second later. That is because commonly the first check returns before the one second timeout is reached and bumps the interval to 2 seconds right away. Also, we go through extra lengths so that manual connectivity check delay the periodic checks. By being more smart about that, we can reduce the number of connectivity checks, but still keeping the promise to check at least within the requested interval. The complexity of book keeping the timeouts is remarkable. But I think it is worth the effort and we should try hard to - have a connectivity state as accurate as possible. Clearly, connectivity checking means that we probing, so being more intelligent about timeout and backoff timers can result in a better connectivity state. The connectivity state is important because we use it for the default-route penaly and the GUI indicates bad connectivity. - be intelligent about avoiding redundant connectivity checks. While we want to check often to get an accurate connectivity state, we also want to minimize the number of HTTP requests, in case the connectivity is established and suppossedly stable. Also, perform connectivity checks in every state of the device. Even if a device is disconnected, it still might have connectivity, for example if the user externally adds an IP address on an unmanaged device. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-02-20 21:41:14 +01:00
device_connectivity_done,
data))
data->remaining++;
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
}
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
if (data->remaining == 0) {
/* call the handler at least once. */
data->remaining = 1;
device_connectivity_done (NULL,
NULL,
NM_CONNECTIVITY_UNKNOWN,
NULL,
data);
/* @data got destroyed. */
}
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
}
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_check_connectivity (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
NMAuthChain *chain;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
chain = nm_auth_chain_new_context (invocation, check_connectivity_auth_done_cb, self);
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
if (!chain) {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_return_error_literal(invocation,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_AUTH_FAILED);
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
return;
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
}
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
nm_auth_chain_add_call (chain, NM_AUTH_PERMISSION_NETWORK_CONTROL, TRUE);
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
}
core: let device plugins advertise supported link and setting types Instead of looping over all plugins and asking each plugin whether it can handle a link or a connection, have them advertise the link and connection types they support, and use that when creating new devices.
2014-09-17 14:17:30 -05:00
static void
start_factory (NMDeviceFactory *factory, gpointer user_data)
{
nm_device_factory_start (factory);
}
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
gboolean
nm_manager_write_device_state (NMManager *self, NMDevice *device)
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
int ifindex;
gboolean managed;
NMConfigDeviceStateManagedType managed_type;
const char *uuid = NULL;
const char *perm_hw_addr_fake = NULL;
gboolean perm_hw_addr_is_fake;
guint32 route_metric_default_aspired;
guint32 route_metric_default_effective;
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
int nm_owned;
dhcp: save root-path in the state file On networked boot we need to somehow communicate this to the early boot machinery. Sadly, no DBus there and we're running in configure-and-quit mode. Abusing the state file for this sounds almost reasonable and is reasonably straightforward thing to do.
2018-08-13 18:37:02 +02:00
NMDhcp4Config *dhcp4_config;
config: also save next-server in the state file The early boot tooling gets the root-path from our state file due to a lack of a better way to do that. However, when booting with NFS root, the root path alone is not sufficient; the server address is communicated via the next-server option. Save that one in the state file as well. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/168
2019-05-27 12:10:45 +02:00
const char *next_server = NULL;
dhcp: save root-path in the state file On networked boot we need to somehow communicate this to the early boot machinery. Sadly, no DBus there and we're running in configure-and-quit mode. Abusing the state file for this sounds almost reasonable and is reasonably straightforward thing to do.
2018-08-13 18:37:02 +02:00
const char *root_path = NULL;
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
ifindex = nm_device_get_ip_ifindex (device);
if (ifindex <= 0)
return FALSE;
if (ifindex == 1) {
/* ignore loopback */
return FALSE;
}
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
if (!nm_platform_link_get (priv->platform, ifindex))
return FALSE;
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
managed = nm_device_get_managed (device, FALSE);
if (managed) {
manager: initialize a potentially uninitialized variable
2018-09-18 18:14:27 +02:00
NMSettingsConnection *sett_conn = NULL;
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
manager: don't save deactivating connections in the state file Especially with configure-and-quit, it's easy to encounter a condition, where the device reached a failed state, policy decides to quit, but the active connection is not yet torn down from the device. Upon the next start NetworkManager would think the connection succeeded activating.
2018-07-04 19:19:38 +02:00
if (nm_device_get_state (device) <= NM_DEVICE_STATE_ACTIVATED)
sett_conn = nm_device_get_settings_connection (device);
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
if (sett_conn)
uuid = nm_settings_connection_get_uuid (sett_conn);
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
managed_type = NM_CONFIG_DEVICE_STATE_MANAGED_TYPE_MANAGED;
} else if (nm_device_get_unmanaged_flags (device, NM_UNMANAGED_USER_EXPLICIT))
managed_type = NM_CONFIG_DEVICE_STATE_MANAGED_TYPE_UNMANAGED;
else
managed_type = NM_CONFIG_DEVICE_STATE_MANAGED_TYPE_UNKNOWN;
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
perm_hw_addr_fake = nm_device_get_permanent_hw_address_full (device, FALSE, &perm_hw_addr_is_fake);
if (perm_hw_addr_fake && !perm_hw_addr_is_fake)
perm_hw_addr_fake = NULL;
nm_owned = nm_device_is_software (device) ? nm_device_is_nm_owned (device) : -1;
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
route_metric_default_effective = _device_route_metric_get (self, ifindex, NM_DEVICE_TYPE_UNKNOWN,
TRUE, &route_metric_default_aspired);
core: persist the fake permanent hardware address to the device's statefile On devices that have no real permanent hardware address (as returned by ethtool), we take the current MAC address of the device. Currently, NM is a bit flaky about whether to accept such fake permanent addresses for settings like keyfile.unmanaged-devices or the per- connection property ethernet.mac-address. Probably, we should allow using fake addresses there in general. However, that leads to problems because NetworkManager itself changes the current MAC address of such devices. For example when configuing keyfile.unmanaged-device=22:33:44:55:66:77 and later activating a connection with ethernet.cloned-mac-address=22:33:44:55:66:77 we have a strange situation after restart and the device becomes unmanaged. We are going to avoid that, by remembering the fake permanent address in the device state file. This only matters: - for devices that don't have a real permanent address (veth) - if the user or NetworkManager itself changed the MAC address of the device - after a restart of NetworkManager, without reboot. A reboot clears the device state for /var/run/NetworkManager.
2016-10-13 15:56:13 +02:00
dhcp: save root-path in the state file On networked boot we need to somehow communicate this to the early boot machinery. Sadly, no DBus there and we're running in configure-and-quit mode. Abusing the state file for this sounds almost reasonable and is reasonably straightforward thing to do.
2018-08-13 18:37:02 +02:00
dhcp4_config = nm_device_get_dhcp4_config (device);
config: also save next-server in the state file The early boot tooling gets the root-path from our state file due to a lack of a better way to do that. However, when booting with NFS root, the root path alone is not sufficient; the server address is communicated via the next-server option. Save that one in the state file as well. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/168
2019-05-27 12:10:45 +02:00
if (dhcp4_config) {
dhcp: save root-path in the state file On networked boot we need to somehow communicate this to the early boot machinery. Sadly, no DBus there and we're running in configure-and-quit mode. Abusing the state file for this sounds almost reasonable and is reasonably straightforward thing to do.
2018-08-13 18:37:02 +02:00
root_path = nm_dhcp4_config_get_option (dhcp4_config, "root_path");
config: also save next-server in the state file The early boot tooling gets the root-path from our state file due to a lack of a better way to do that. However, when booting with NFS root, the root path alone is not sufficient; the server address is communicated via the next-server option. Save that one in the state file as well. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/168
2019-05-27 12:10:45 +02:00
next_server = nm_dhcp4_config_get_option (dhcp4_config, "next_server");
}
dhcp: save root-path in the state file On networked boot we need to somehow communicate this to the early boot machinery. Sadly, no DBus there and we're running in configure-and-quit mode. Abusing the state file for this sounds almost reasonable and is reasonably straightforward thing to do.
2018-08-13 18:37:02 +02:00
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
return nm_config_device_state_write (ifindex,
managed_type,
perm_hw_addr_fake,
uuid,
nm_owned,
route_metric_default_aspired,
dhcp: save root-path in the state file On networked boot we need to somehow communicate this to the early boot machinery. Sadly, no DBus there and we're running in configure-and-quit mode. Abusing the state file for this sounds almost reasonable and is reasonably straightforward thing to do.
2018-08-13 18:37:02 +02:00
route_metric_default_effective,
config: also save next-server in the state file The early boot tooling gets the root-path from our state file due to a lack of a better way to do that. However, when booting with NFS root, the root path alone is not sufficient; the server address is communicated via the next-server option. Save that one in the state file as well. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/168
2019-05-27 12:10:45 +02:00
next_server,
dhcp: save root-path in the state file On networked boot we need to somehow communicate this to the early boot machinery. Sadly, no DBus there and we're running in configure-and-quit mode. Abusing the state file for this sounds almost reasonable and is reasonably straightforward thing to do.
2018-08-13 18:37:02 +02:00
root_path);
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
}
void
nm_manager_write_device_state_all (NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
gs_unref_hashtable GHashTable *seen_ifindexes = NULL;
NMDevice *device;
manager: restore the previous persistent nm-owned state of devices After a daemon restart, any software device is considered !nm-owned, even if it was created by NM. Therefore, a device stays around even if the connection which created it gets deactivated or deleted. Fix this by remembering the previous nm-owned state in the device state file. https://bugzilla.redhat.com/show_bug.cgi?id=1376199
2017-05-31 16:58:21 +02:00
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
seen_ifindexes = g_hash_table_new (nm_direct_hash, NULL);
core: add read/write support for route-metric to NMConfig's device state
2017-12-06 15:51:18 +01:00
manager: rename nm_manager_write_device_state() Rename nm_manager_write_device_state() to nm_manager_write_device_state_all(), and split out the code to write a single device state to a new function.
2018-07-06 21:09:58 +02:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
if (nm_manager_write_device_state (self, device)) {
g_hash_table_add (seen_ifindexes,
GINT_TO_POINTER (nm_device_get_ip_ifindex (device)));
}
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
}
config: remove unused NMConfig self argument from nm_config_device_state_*() API nm_config_device_state_*() always access the file system directly, they don't cache data in NMConfig. Hence, they don't use the @self argument. Maybe those functions don't belong to nm-config.h, anyway. For lack of a better place they are there. (cherry picked from commit 1940be410cc0272de2f690542f43ef7dcb7bc4e1)
2017-04-19 15:45:31 +02:00
nm_config_device_state_prune_unseen (seen_ifindexes);
config: store and load device runtime state to file The data is still unused, the actual fields might change. Note that the actual state we store is subject to change, according to which data we need. The file format is non stable, as the files don't survive reboot. So there is no backward compatibility to maintain and the format can be changed later.
2016-09-23 17:36:21 +02:00
}
manager: delay startup-complete and devices-inited until idle As long as there are events in the mainloop that are ready for dispatch, it's clear that startup-complete is not yet reached. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-14 10:42:36 +01:00
static gboolean
devices_inited_cb (gpointer user_data)
{
NMManager *self = user_data;
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
priv->devices_inited_id = 0;
priv->devices_inited = TRUE;
check_if_startup_complete (self);
return G_SOURCE_REMOVE;
}
core: make NMManager singleton more like others Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
2015-08-03 09:26:31 -04:00
gboolean
nm_manager_start (NMManager *self, GError **error)
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: refactor nm_settings_get_connections_sorted() to return array instead of GSList We call these functions a lot. A GSList is just the wrong tool for the job. Refactor the code to use instead a sorted array everywhere. This means, we malloc() one array for all connections instead slice-allocate a GSList item for each. Also, sorting an array is faster then sorting a GSList. Technically, the GSList implementation had the same big-O runtime complexity, but using an array is still faster. That is, sorting an array and a GSList is both O(n*log(n)). Actually, nm_settings_get_connections_sorted() used g_slist_insert_sorted() instead of g_slist_sort(). That results in O(n^2). That could have been fixed to have O(n*log(n)), but instead refactor the code to use an array.
2017-02-03 14:15:16 +01:00
gs_free NMSettingsConnection **connections = NULL;
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
guint i;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
nm_device_factory_manager_load_factories (_register_device_factory, self);
nm_device_factory_manager_for_each_factory (start_factory, NULL);
core: make NMManager singleton more like others Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
2015-08-03 09:26:31 -04:00
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
/* Set initial radio enabled/disabled state */
for (i = 0; i < RFKILL_TYPE_MAX; i++) {
RadioState *rstate = &priv->radio_states[i];
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
gboolean enabled;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
if (!rstate->desc)
continue;
wifi: remove old ipw rfkill polling functionality Older Intel "ipw" devices (ipw2100, ipw2200, and ipw2915) only gained kernel rfkill subsystem integration with 2.6.33. Before then their custom rfkill functionality had to be polled via sysfs. Since we now require at least a 3.x kernel, remove this old code.
2014-04-15 16:25:39 -05:00
/* recheck kernel rfkill state */
update_rstate_from_rfkill (priv->rfkill_mgr, rstate);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
if (rstate->desc) {
manager: add "rfkill" prefix to related logging messages
2017-06-07 13:13:55 +02:00
_LOGI (LOGD_RFKILL, "rfkill: %s %s by radio killswitch; %s by state file",
manager: use logging helpers
2016-03-02 11:38:26 +01:00
rstate->desc,
(rstate->hw_enabled && rstate->sw_enabled) ? "enabled" : "disabled",
rstate->user_enabled ? "enabled" : "disabled");
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
}
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
enabled = radio_enabled_for_rstate (rstate, TRUE);
manager_update_radio_enabled (self, rstate, enabled);
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
}
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGI (LOGD_CORE, "Networking is %s by state file",
priv->net_enabled ? "enabled" : "disabled");
wifi: fix disabled wifi devices on resume (rh #578141) RFKILL_TYPE_WLAN is 0, and we while we had allocated the structure for WIMAX rfkill in the manager's priv->radio_states, we hadn't filled it in. That meant that priv->radio_states[RFKILL_TYPE_WIMAX].rtype was 0, and thus various operations thought that wifi devices were wimax devices, and since WiMAX rfkill is never updated because it's not yet used, wifi would never be enabled after resume.
2010-04-08 18:23:43 -07:00
settings: remove connection tracking from NMManager NMSysconfigSettings has the authoritative list of connections, no reason to duplicate all that tracking code in NMManager. Add the missing bits that the manager had to NMSysconfigSettings, and point NMPolicy at the settings object instead of NMManager for that.
2010-10-27 15:47:10 -05:00
system_unmanaged_devices_changed_cb (priv->settings, NULL, self);
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
hostname_changed_cb (priv->hostname_manager, NULL, self);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
if (!nm_settings_start (priv->settings, error))
return FALSE;
core: move device factory type function into factory object In preparation for internal device types exposing factories too, it's easier to have the device type that the factory creates be returned by the factory object instead of the plugin, because internal device types don't have plugins. This requires that we create the factory objects earlier, which further requires that any operations that trigger signals must be moved out of each factory's construction path to a separate start() function.
2014-09-05 14:48:21 -05:00
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
nm_platform_process_events (priv->platform);
manager: process events of platform cache during nm_manager_start() Possibly pending messages from the netlink socket were not processed since the platform instance was created earlier. As nm_manager_start() may take a long time to run, make sure that there are no pending messages before querying the devices.
2017-03-14 12:14:21 +01:00
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
g_signal_connect (priv->platform,
manager: process events of platform cache during nm_manager_start() Possibly pending messages from the netlink socket were not processed since the platform instance was created earlier. As nm_manager_start() may take a long time to run, make sure that there are no pending messages before querying the devices.
2017-03-14 12:14:21 +01:00
NM_PLATFORM_SIGNAL_LINK_CHANGED,
G_CALLBACK (platform_link_cb),
self);
platform: move nm_platform_query_devices() to nm-manager nm_platform_query_devices() would raise an 'added' signal for all its links. That is bad style because it could confuse other listeners for platform signals which don't expect such artificial change signals. The public API of NMPlatform already gives NMManager the ability to 'pull' all the links and iterate them itself. Before, nm_platform_query_devices() would also initialize udev devices, so there was a more compelling reason for this function.
2015-05-04 16:54:51 +02:00
platform_query_devices (self);
bonding: kernel bonding device creation Creates virtual kernel devices as needed. Since the manager is initialized after the connections have been loaded no CONNECTIONS_ADDED notification is received for connections parsed at startup. Therefore walks the loaded connections looking for bonding connections. Connections added on the fly are handled via the notifications. Connection renaming and deleting is not supported yet. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-10-18 13:48:44 +02:00
core: better order the code at startup NM was calling nm_bus_manager_start_service() to claim its bus name before it exported any of its objects, but this didn't matter under dbus-glib, because no client connections would be accepted until the main loop was started later on, by which point we would have exported everything. But with gdbus, method calls are initially received in the gdbus worker thread, which means that clients would be able to connect right away and then be told that the expected interfaces don't exist. So move the nm_bus_manager_start_service() call to occur after creating NMSettings and NMManager (and, indirectly, NMAgentManager). This requires splitting out the slow parts of nm_settings_new() into a new nm_settings_start(), so that we can create and export it first, and then read the connections, etc afterward. (Likewise, there were still a few potentially-slow bits in nm_manager_new() which are now moved into nm_manager_start().)
2015-07-31 13:00:22 -04:00
/* Load VPN plugins */
priv->vpn_manager = g_object_ref (nm_vpn_manager_get ());
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGD (LOGD_CORE, "creating virtual devices...");
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
g_signal_connect (priv->settings, NM_SETTINGS_SIGNAL_CONNECTION_ADDED,
G_CALLBACK (connection_added_cb), self);
g_signal_connect (priv->settings, NM_SETTINGS_SIGNAL_CONNECTION_UPDATED,
G_CALLBACK (connection_updated_cb), self);
core: merge nm_settings_get_connections_sorted() with nm_settings_get_connections_clone()
2017-11-22 12:46:58 +01:00
connections = nm_settings_get_connections_clone (priv->settings, NULL,
NULL, NULL,
nm_settings_connection_cmp_autoconnect_priority_p_with_data, NULL);
core: refactor nm_settings_get_connections_sorted() to return array instead of GSList We call these functions a lot. A GSList is just the wrong tool for the job. Refactor the code to use instead a sorted array everywhere. This means, we malloc() one array for all connections instead slice-allocate a GSList item for each. Also, sorting an array is faster then sorting a GSList. Technically, the GSList implementation had the same big-O runtime complexity, but using an array is still faster. That is, sorting an array and a GSList is both O(n*log(n)). Actually, nm_settings_get_connections_sorted() used g_slist_insert_sorted() instead of g_slist_sort(). That results in O(n^2). That could have been fixed to have O(n*log(n)), but instead refactor the code to use an array.
2017-02-03 14:15:16 +01:00
for (i = 0; connections[i]; i++)
settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection NMConnection is an interface, which is implemented by the types NMSimpleConnection (libnm-core), NMSettingsConnection (src) and NMRemoteConnection (libnm). NMSettingsConnection does a lot of things already: 1) it "is-a" NMDBusObject and exports the API of a connection profile on D-Bus 2) it interacts with NMSettings and contains functionality for tracking the profiles. 3) it is the base-class of types like NMSKeyfileConnection and NMIfcfgConnection. These handle how the profile is persisted on disk. 4) it implements NMConnection interface, to itself track the settings of the profile. 3) and 4) would be better implemented via delegation than inheritance. Address 4) and don't let NMSettingsConnection implemente the NMConnection interface. Instead, a settings-connection references now a NMSimpleConnection instance, to which it delegates for keeping the actual profiles. Advantages: - by delegating, there is a clearer separation of what NMSettingsConnection does. For example, in C we often required casts from NMSettingsConnection to NMConnection. NMConnection is a very trivial object with very little logic. When we have a NMConnection instance at hand, it's good to know that it is *only* that simple instead of also being an entire NMSettingsConnection instance. The main purpose of this patch is to simplify the code by separating the NMConnection from the NMSettingsConnection. We should generally be aware whether we handle a NMSettingsConnection or a trivial NMConnection instance. Now, because NMSettingsConnection no longer "is-a" NMConnection, this distinction is apparent. - NMConnection is implemented as an interface and we create NMSimpleConnection instances whenever we need a real instance. In GLib, interfaces have a performance overhead, that we needlessly pay all the time. With this change, we no longer require NMConnection to be an interface. Thus, in the future we could compile a version of libnm-core for the daemon, where NMConnection is not an interface but a GObject implementation akin to NMSimpleConnection. - In the previous implementation, we cannot treat NMConnection immutable and copy-on-write. For example, when NMDevice needs a snapshot of the activated profile as applied-connection, all it can do is clone the entire NMSettingsConnection as a NMSimpleConnection. Likewise, when we get a NMConnection instance and want to keep a reference to it, we cannot do that, because we never know who also references and modifies the instance. By separating NMSettingsConnection we could in the future have NMConnection immutable and copy-on-write, to avoid all unnecessary clones.
2018-08-11 11:08:17 +02:00
connection_changed (self, connections[i]);
core: only manage those bridges created by NetworkManager (rh #905035) 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.
2013-02-01 18:03:11 -06:00
manager: delay startup-complete and devices-inited until idle As long as there are events in the mainloop that are ready for dispatch, it's clear that startup-complete is not yet reached. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-14 10:42:36 +01:00
nm_clear_g_source (&priv->devices_inited_id);
priv->devices_inited_id = g_idle_add_full (G_PRIORITY_LOW + 10, devices_inited_cb, self, NULL);
core: make NMManager singleton more like others Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
2015-08-03 09:26:31 -04:00
return TRUE;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
}
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
void
nm_manager_stop (NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *device;
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
core/trivial: add FIXME comments about clean shutdown at exit
2018-04-18 10:23:22 +02:00
/* FIXME(shutdown): we don't do a proper shutdown yet:
* - need to ensure that all pending async operations are cancelled
* - e.g. operations in priv->async_op_lst_head
* - need to ensure that no more asynchronous requests are started,
* or that they complete quickly, or that they fail quickly.
* - note that cancelling some operations is not possible synchronously.
* Hence, stop() only prepares shutdown and tells everybody to not
* accept new work, and to complete in a timely manner.
* We need to still iterate the mainloop for a bit, to give everybody
* the chance to complete.
* - e.g. see comment at nm_auth_manager_force_shutdown()
*/
core/dbus: stop NMDBusManager and reject future method calls During shutdown, we will need to still iterate the main loop to do a coordinated shutdown. Currently we do not, and we just exit, leaving a lot of objects hanging. If we are going to fix that, we need during shutdown tell NMDBusManager to reject all future operations. Note that property getters and "GetManagerObjects" call is not blocked. It continues to work. Certainly for some operations, we want to allow them to be called even during shutdown. However, these have to opt-in. This also fixes an uglyness, where nm_dbus_manager_start() would get the set-property-handler and the @manager as user-data. However, NMDBusManager will always outlife NMManager, hence, after NMManager is destroyed, the user-data would be a dangling pointer. Currently that is not an issue, because - we always leak NMManager - we don't run the mainloop during shutdown
2018-04-21 13:25:57 +02:00
nm_dbus_manager_stop (nm_dbus_object_get_manager (NM_DBUS_OBJECT (self)));
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
while ((device = c_list_first_entry (&priv->devices_lst_head, NMDevice, devices_lst)))
manager: don't allow femoving a device without traversing proper states There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
2019-05-17 19:22:19 +02:00
remove_device (self, device, TRUE);
manager: cleanup active connections upon exit When connection sharing is enabled, the removal of iptables rules is delegated to the NMActRequest destructor; but for this to work it is required that the object is properly dereferenced upon NM termination. Clean up the active connections which are in DEACTIVATED state when quitting, so that they are unexported and destroyed. https://bugzilla.gnome.org/show_bug.cgi?id=692673
2016-01-22 15:19:06 +01:00
_active_connection_cleanup (self);
manager: delay startup-complete and devices-inited until idle As long as there are events in the mainloop that are ready for dispatch, it's clear that startup-complete is not yet reached. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-14 10:42:36 +01:00
nm_clear_g_source (&priv->devices_inited_id);
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
}
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
static gboolean
handle_firmware_changed (gpointer user_data)
{
NMManager *self = NM_MANAGER (user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
NMDevice *device;
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
priv->fw_changed_id = 0;
/* Try to re-enable devices with missing firmware */
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
NMDeviceState state = nm_device_get_state (device);
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
if ( nm_device_get_firmware_missing (device)
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
&& (state == NM_DEVICE_STATE_UNAVAILABLE)) {
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
_LOG2I (LOGD_CORE, device, "firmware may now be available");
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
/* Re-set unavailable state to try bringing the device up again */
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
nm_device_state_changed (device,
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
NM_DEVICE_STATE_UNAVAILABLE,
NM_DEVICE_STATE_REASON_NONE);
}
}
return FALSE;
}
static void
firmware_dir_changed (GFileMonitor *monitor,
GFile *file,
GFile *other_file,
GFileMonitorEvent event_type,
gpointer user_data)
{
NMManager *self = NM_MANAGER (user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
switch (event_type) {
case G_FILE_MONITOR_EVENT_CREATED:
case G_FILE_MONITOR_EVENT_CHANGED:
case G_FILE_MONITOR_EVENT_MOVED:
case G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED:
case G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT:
if (!priv->fw_changed_id) {
priv->fw_changed_id = g_timeout_add_seconds (4, handle_firmware_changed, self);
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGI (LOGD_CORE, "kernel firmware directory '%s' changed",
KERNEL_FIRMWARE_DIR);
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
}
break;
default:
break;
}
}
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
static void
connection_metered_changed (GObject *object,
NMMetered metered,
gpointer user_data)
{
nm_manager_update_metered (NM_MANAGER (user_data));
}
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
static void
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
policy_default_ac_changed (GObject *object, GParamSpec *pspec, gpointer user_data)
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
{
NMManager *self = NM_MANAGER (user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMActiveConnection *ac;
/* Note: this assumes that it's not possible for the IP4 default
* route to be going over the default-ip6-device. If that changes,
* we need something more complicated here.
*/
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
ac = nm_policy_get_default_ip4_ac (priv->policy);
if (!ac)
ac = nm_policy_get_default_ip6_ac (priv->policy);
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
if (ac != priv->primary_connection) {
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
if (priv->primary_connection) {
g_signal_handlers_disconnect_by_func (priv->primary_connection,
G_CALLBACK (connection_metered_changed),
self);
g_clear_object (&priv->primary_connection);
}
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
priv->primary_connection = ac ? g_object_ref (ac) : NULL;
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
if (priv->primary_connection) {
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
g_signal_connect (priv->primary_connection,
NM_ACTIVE_CONNECTION_DEVICE_METERED_CHANGED,
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
G_CALLBACK (connection_metered_changed), self);
}
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
_LOGD (LOGD_CORE, "PrimaryConnection now %s",
ac ? nm_active_connection_get_settings_connection_id (ac) : "(none)");
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
_notify (self, PROP_PRIMARY_CONNECTION);
_notify (self, PROP_PRIMARY_CONNECTION_TYPE);
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
nm_manager_update_metered (self);
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
}
}
static void
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
policy_activating_ac_changed (GObject *object, GParamSpec *pspec, gpointer user_data)
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
{
NMManager *self = NM_MANAGER (user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
NMActiveConnection *activating, *best;
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
/* We only look at activating-ip6-ac if activating-ip4-ac
* AND default-ip4-ac are NULL; if default-ip4-ac is
* non-NULL, then activating-ip6-ac is irrelevant, since while
* that AC might become the new default-ip6-ac, it can't
* become primary-connection while default-ip4-ac is set to
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
* something else.
*/
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
activating = nm_policy_get_activating_ip4_ac (priv->policy);
best = nm_policy_get_default_ip4_ac (priv->policy);
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
if (!activating && !best)
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
activating = nm_policy_get_activating_ip6_ac (priv->policy);
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
if (nm_g_object_ref_set (&priv->activating_connection, activating)) {
_LOGD (LOGD_CORE, "ActivatingConnection now %s",
activating
? nm_active_connection_get_settings_connection_id (activating)
: "(none)");
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
_notify (self, PROP_ACTIVATING_CONNECTION);
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
}
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
/*****************************************************************************/
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
typedef struct {
NMManager *self;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMDBusObject *obj;
const NMDBusInterfaceInfoExtended *interface_info;
const NMDBusPropertyInfoExtended *property_info;
GVariant *value;
guint64 export_version_id;
} DBusSetPropertyHandle;
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
#define NM_PERM_DENIED_ERROR "org.freedesktop.NetworkManager.PermissionDenied"
core: validate Enable/Disable WiFi and WWAN requests (rh #626337) Since these were properties they are harder to validate the caller as dbus-glib doesn't have any hooks before the property is set. So we install a low-level dbus filter function to catch property Set requests before they get to dbus-glib and handle the property access there.
2010-08-25 15:12:32 -05:00
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
_dbus_set_property_auth_cb (NMAuthChain *chain,
GDBusMethodInvocation *invocation,
gpointer user_data)
core: validate Enable/Disable WiFi and WWAN requests (rh #626337) Since these were properties they are harder to validate the caller as dbus-glib doesn't have any hooks before the property is set. So we install a low-level dbus filter function to catch property Set requests before they get to dbus-glib and handle the property access there.
2010-08-25 15:12:32 -05:00
{
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
DBusSetPropertyHandle *handle_data = user_data;
gs_unref_object NMDBusObject *obj = handle_data->obj;
const NMDBusInterfaceInfoExtended *interface_info = handle_data->interface_info;
const NMDBusPropertyInfoExtended *property_info = handle_data->property_info;
gs_unref_variant GVariant *value = handle_data->value;
guint64 export_version_id = handle_data->export_version_id;
gs_unref_object NMManager *self = handle_data->self;
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: validate Enable/Disable WiFi and WWAN requests (rh #626337) Since these were properties they are harder to validate the caller as dbus-glib doesn't have any hooks before the property is set. So we install a low-level dbus filter function to catch property Set requests before they get to dbus-glib and handle the property access there.
2010-08-25 15:12:32 -05:00
NMAuthCallResult result;
core: use nm_g_object_set_property() for setting properties from D-Bus g_object_set_property() cannot fail nor signal an error reason when invalid arguments are passed. Use our wrapper nm_g_object_set_property() instead. Note that the input argument comes from untrusted (although authenticated) source.
2018-11-22 14:39:22 +01:00
gs_free_error GError *local = NULL;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
const char *error_name = NULL;
const char *error_message = NULL;
GValue gvalue;
g_slice_free (DBusSetPropertyHandle, handle_data);
core: validate Enable/Disable WiFi and WWAN requests (rh #626337) Since these were properties they are harder to validate the caller as dbus-glib doesn't have any hooks before the property is set. So we install a low-level dbus filter function to catch property Set requests before they get to dbus-glib and handle the property access there.
2010-08-25 15:12:32 -05:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_unlink (nm_auth_chain_parent_lst_list (chain));
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
result = nm_auth_chain_get_result (chain, property_info->writable.permission);
core: refactor setting of D-Bus properties via NMManager - 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.
2015-09-15 11:34:00 +02:00
core: remove unused error argument from NMAuthChainResultFunc NMAuthChain usually requests several permissions at once. Hence, an error argument in the overall callback does not make sense, because you wouldn't know which request failed. If at all, it could only mean that the overall request failed (like an D-Bus failure communicating to D-Bus *for all permisssions*), but we don't need to handle that specially. In fact, we don't really care why permission was not granted, whether it's due to an error or legitimate reasons. The error in the callback was always set to %NULL. Remove it.
2019-05-04 09:37:54 +02:00
if (result != NM_AUTH_CALL_RESULT_YES) {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
error_name = NM_PERM_DENIED_ERROR;
core: remove unused error argument from NMAuthChainResultFunc NMAuthChain usually requests several permissions at once. Hence, an error argument in the overall callback does not make sense, because you wouldn't know which request failed. If at all, it could only mean that the overall request failed (like an D-Bus failure communicating to D-Bus *for all permisssions*), but we don't need to handle that specially. In fact, we don't really care why permission was not granted, whether it's due to an error or legitimate reasons. The error in the callback was always set to %NULL. Remove it.
2019-05-04 09:37:54 +02:00
error_message = "Not authorized to perform this operation";
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
goto out;
core: validate Enable/Disable WiFi and WWAN requests (rh #626337) Since these were properties they are harder to validate the caller as dbus-glib doesn't have any hooks before the property is set. So we install a low-level dbus filter function to catch property Set requests before they get to dbus-glib and handle the property access there.
2010-08-25 15:12:32 -05:00
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
if (export_version_id != nm_dbus_object_get_export_version_id (obj)) {
error_name = "org.freedesktop.DBus.Error.UnknownObject";
error_message = "Object was deleted while authenticating";
goto out;
core: refactor setting of D-Bus properties via NMManager - 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.
2015-09-15 11:34:00 +02:00
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
/* Handle some properties specially *sigh* */
if ( interface_info == &interface_info_manager
&& nm_streq (property_info->property_name, NM_MANAGER_GLOBAL_DNS_CONFIGURATION)) {
const NMGlobalDnsConfig *global_dns;
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
global_dns = nm_config_data_get_global_dns_config (nm_config_get_data (priv->config));
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
if ( global_dns
&& !nm_global_dns_config_is_internal (global_dns)) {
error_name = NM_PERM_DENIED_ERROR;
error_message = "Global DNS configuration already set via configuration file";
goto out;
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
}
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_gvariant_to_gvalue (value, &gvalue);
core: use nm_g_object_set_property() for setting properties from D-Bus g_object_set_property() cannot fail nor signal an error reason when invalid arguments are passed. Use our wrapper nm_g_object_set_property() instead. Note that the input argument comes from untrusted (although authenticated) source.
2018-11-22 14:39:22 +01:00
if (!nm_g_object_set_property (G_OBJECT (obj), property_info->property_name, &gvalue, &local)) {
error_name = "org.freedesktop.DBus.Error.InvalidArgs";
error_message = local->message;
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_value_unset (&gvalue);
core: refactor setting of D-Bus properties via NMManager - 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.
2015-09-15 11:34:00 +02:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
out:
nm_audit_log_control_op (property_info->writable.audit_op,
property_info->property_name,
!error_message,
nm_auth_chain_get_subject (chain),
error_message);
if (error_message)
g_dbus_method_invocation_return_dbus_error (invocation, error_name, error_message);
else
g_dbus_method_invocation_return_value (invocation, NULL);
core: validate Enable/Disable WiFi and WWAN requests (rh #626337) Since these were properties they are harder to validate the caller as dbus-glib doesn't have any hooks before the property is set. So we install a low-level dbus filter function to catch property Set requests before they get to dbus-glib and handle the property access there.
2010-08-25 15:12:32 -05:00
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
void
nm_manager_dbus_set_property_handle (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusPropertyInfoExtended *property_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *value,
gpointer user_data)
core: validate Enable/Disable WiFi and WWAN requests (rh #626337) Since these were properties they are harder to validate the caller as dbus-glib doesn't have any hooks before the property is set. So we install a low-level dbus filter function to catch property Set requests before they get to dbus-glib and handle the property access there.
2010-08-25 15:12:32 -05:00
{
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMManager *self = user_data;
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: validate Enable/Disable WiFi and WWAN requests (rh #626337) Since these were properties they are harder to validate the caller as dbus-glib doesn't have any hooks before the property is set. So we install a low-level dbus filter function to catch property Set requests before they get to dbus-glib and handle the property access there.
2010-08-25 15:12:32 -05:00
NMAuthChain *chain;
manager: also audit-log early failure to setting property
2015-08-20 13:42:00 +02:00
const char *error_message = NULL;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
gs_unref_object NMAuthSubject *subject = NULL;
DBusSetPropertyHandle *handle_data;
core: validate Enable/Disable WiFi and WWAN requests (rh #626337) Since these were properties they are harder to validate the caller as dbus-glib doesn't have any hooks before the property is set. So we install a low-level dbus filter function to catch property Set requests before they get to dbus-glib and handle the property access there.
2010-08-25 15:12:32 -05:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
subject = nm_auth_subject_new_unix_process_from_context (invocation);
if (!subject) {
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
error_message = NM_UTILS_ERROR_MSG_REQ_UID_UKNOWN;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
goto err;
core: validate Enable/Disable WiFi and WWAN requests (rh #626337) Since these were properties they are harder to validate the caller as dbus-glib doesn't have any hooks before the property is set. So we install a low-level dbus filter function to catch property Set requests before they get to dbus-glib and handle the property access there.
2010-08-25 15:12:32 -05:00
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
handle_data = g_slice_new0 (DBusSetPropertyHandle);
handle_data->self = g_object_ref (self);
handle_data->obj = g_object_ref (obj);
handle_data->interface_info = interface_info;
handle_data->property_info = property_info;
handle_data->value = g_variant_ref (value);
handle_data->export_version_id = nm_dbus_object_get_export_version_id (obj);
core: use NMAuthSubject in the manager for non-activation paths
2013-07-29 11:53:23 -05:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
chain = nm_auth_chain_new_subject (subject, invocation, _dbus_set_property_auth_cb, handle_data);
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
auth-chain: don't clone the permission string for AuthChain Out of the 33 callers of nm_auth_chain_add_call(), the permission argument is: - 29 times a C string literal like NM_AUTH_PERMISSION_NETWORK_CONTROL. - 3 times assign a string that is in fact a static string (it's just not a string literal) - only NMManager's device_auth_request_cb() passes a permission of (possibly) non static origin. But it already duplicates the string for it's own purposes and attaches it as user-data to the NMAuthChain. There really is no need to duplicate the string. Replace nm_auth_chain_add_call() by a macro that ensures that the permission string is a C literal. Rename nm_auth_chain_add_call() to nm_auth_chain_add_call_unsafe() to indicate that the lifetime of the permission argument is now the responsibility of the caller.
2019-05-04 10:31:18 +02:00
nm_auth_chain_add_call_unsafe (chain, property_info->writable.permission, TRUE);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
return;
manager: fix race subscribing prop_filter() 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.
2015-08-20 14:25:46 +02:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
err:
nm_audit_log_control_op (property_info->writable.audit_op,
property_info->property_name,
FALSE,
invocation,
error_message);
g_dbus_method_invocation_return_error_literal (invocation,
G_DBUS_ERROR,
G_DBUS_ERROR_AUTH_FAILED,
error_message);
manager: fix race subscribing prop_filter() 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.
2015-08-20 14:25:46 +02:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
manager: fix race subscribing prop_filter() 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.
2015-08-20 14:25:46 +02:00
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
static NMCheckpointManager *
_checkpoint_mgr_get (NMManager *self, gboolean create_as_needed)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
if (G_UNLIKELY (!priv->checkpoint_mgr) && create_as_needed)
core: export checkpoint list over D-Bus
2017-10-21 16:05:14 +02:00
priv->checkpoint_mgr = nm_checkpoint_manager_new (self, obj_properties[PROP_CHECKPOINTS]);
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
return priv->checkpoint_mgr;
}
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
static void
checkpoint_auth_done_cb (NMAuthChain *chain,
GDBusMethodInvocation *context,
gpointer user_data)
{
NMManager *self = NM_MANAGER (user_data);
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
char *op;
char *checkpoint_path = NULL;
char **devices;
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
NMCheckpoint *checkpoint;
NMAuthCallResult result;
guint32 timeout, flags;
GVariant *variant = NULL;
GError *error = NULL;
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
const char *arg = NULL;
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
guint32 add_timeout;
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
op = nm_auth_chain_get_data (chain, "audit-op");
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_unlink (nm_auth_chain_parent_lst_list (chain));
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
result = nm_auth_chain_get_result (chain, NM_AUTH_PERMISSION_CHECKPOINT_ROLLBACK);
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
if (NM_IN_STRSET (op, NM_AUDIT_OP_CHECKPOINT_DESTROY,
NM_AUDIT_OP_CHECKPOINT_ROLLBACK,
NM_AUDIT_OP_CHECKPOINT_ADJUST_ROLLBACK_TIMEOUT))
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
arg = checkpoint_path = nm_auth_chain_get_data (chain, "checkpoint_path");
core: remove unused error argument from NMAuthChainResultFunc NMAuthChain usually requests several permissions at once. Hence, an error argument in the overall callback does not make sense, because you wouldn't know which request failed. If at all, it could only mean that the overall request failed (like an D-Bus failure communicating to D-Bus *for all permisssions*), but we don't need to handle that specially. In fact, we don't really care why permission was not granted, whether it's due to an error or legitimate reasons. The error in the callback was always set to %NULL. Remove it.
2019-05-04 09:37:54 +02:00
if (result != NM_AUTH_CALL_RESULT_YES) {
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
error = g_error_new_literal (NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
"Not authorized to checkpoint/rollback");
} else {
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
if (nm_streq0 (op, NM_AUDIT_OP_CHECKPOINT_CREATE)) {
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
timeout = GPOINTER_TO_UINT (nm_auth_chain_get_data (chain, "timeout"));
flags = GPOINTER_TO_UINT (nm_auth_chain_get_data (chain, "flags"));
devices = nm_auth_chain_get_data (chain, "devices");
checkpoint = nm_checkpoint_manager_create (_checkpoint_mgr_get (self, TRUE),
(const char *const *) devices,
timeout,
(NMCheckpointCreateFlags) flags,
&error);
if (checkpoint) {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
arg = nm_dbus_object_get_path (NM_DBUS_OBJECT (checkpoint));
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
variant = g_variant_new ("(o)", arg);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
}
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
} else if (nm_streq0 (op, NM_AUDIT_OP_CHECKPOINT_DESTROY)) {
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
nm_checkpoint_manager_destroy (_checkpoint_mgr_get (self, TRUE),
checkpoint_path, &error);
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
} else if (nm_streq0 (op, NM_AUDIT_OP_CHECKPOINT_ROLLBACK)) {
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
nm_checkpoint_manager_rollback (_checkpoint_mgr_get (self, TRUE),
checkpoint_path, &variant, &error);
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
} else if (nm_streq0 (op, NM_AUDIT_OP_CHECKPOINT_ADJUST_ROLLBACK_TIMEOUT)) {
add_timeout = GPOINTER_TO_UINT (nm_auth_chain_get_data (chain, "add_timeout"));
nm_checkpoint_manager_adjust_rollback_timeout (_checkpoint_mgr_get (self, TRUE),
checkpoint_path, add_timeout, &error);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
} else
g_return_if_reached ();
}
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
nm_audit_log_checkpoint_op (op, arg ?: "", !error, nm_auth_chain_get_subject (chain),
error ? error->message : NULL);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
if (error)
g_dbus_method_invocation_take_error (context, error);
else
g_dbus_method_invocation_return_value (context, variant);
}
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_checkpoint_create (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
NMAuthChain *chain;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
char **devices;
guint32 rollback_timeout;
guint32 flags;
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
G_STATIC_ASSERT_EXPR (sizeof (flags) <= sizeof (NMCheckpointCreateFlags));
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
chain = nm_auth_chain_new_context (invocation, checkpoint_auth_done_cb, self);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
if (!chain) {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_return_error_literal (invocation,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_AUTH_FAILED);
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
return;
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_variant_get (parameters, "(^aouu)", &devices, &rollback_timeout, &flags);
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
nm_auth_chain_set_data (chain, "audit-op", NM_AUDIT_OP_CHECKPOINT_CREATE, NULL);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_auth_chain_set_data (chain, "devices", devices, (GDestroyNotify) g_strfreev);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
nm_auth_chain_set_data (chain, "flags", GUINT_TO_POINTER (flags), NULL);
nm_auth_chain_set_data (chain, "timeout", GUINT_TO_POINTER (rollback_timeout), NULL);
nm_auth_chain_add_call (chain, NM_AUTH_PERMISSION_CHECKPOINT_ROLLBACK, TRUE);
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
}
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_checkpoint_destroy (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
NMAuthChain *chain;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
const char *checkpoint_path;
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
chain = nm_auth_chain_new_context (invocation, checkpoint_auth_done_cb, self);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
if (!chain) {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_return_error_literal (invocation,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_AUTH_FAILED);
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
return;
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_variant_get (parameters, "(&o)", &checkpoint_path);
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
nm_auth_chain_set_data (chain, "audit-op", NM_AUDIT_OP_CHECKPOINT_DESTROY, NULL);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
nm_auth_chain_set_data (chain, "checkpoint_path", g_strdup (checkpoint_path), g_free);
nm_auth_chain_add_call (chain, NM_AUTH_PERMISSION_CHECKPOINT_ROLLBACK, TRUE);
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
}
static void
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
impl_manager_checkpoint_rollback (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
NMAuthChain *chain;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
const char *checkpoint_path;
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
chain = nm_auth_chain_new_context (invocation, checkpoint_auth_done_cb, self);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
if (!chain) {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_dbus_method_invocation_return_error_literal (invocation,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_AUTH_FAILED);
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
return;
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_variant_get (parameters, "(&o)", &checkpoint_path);
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
checkpoint: add audit support
2016-08-01 17:19:14 +02:00
nm_auth_chain_set_data (chain, "audit-op", NM_AUDIT_OP_CHECKPOINT_ROLLBACK, NULL);
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
nm_auth_chain_set_data (chain, "checkpoint_path", g_strdup (checkpoint_path), g_free);
nm_auth_chain_add_call (chain, NM_AUTH_PERMISSION_CHECKPOINT_ROLLBACK, TRUE);
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
}
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
static void
impl_manager_checkpoint_adjust_rollback_timeout (NMDBusObject *obj,
const NMDBusInterfaceInfoExtended *interface_info,
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER (obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
NMAuthChain *chain;
const char *checkpoint_path;
guint32 add_timeout;
chain = nm_auth_chain_new_context (invocation, checkpoint_auth_done_cb, self);
if (!chain) {
g_dbus_method_invocation_return_error_literal (invocation,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
core: add defines for common authentication-related error messages All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
2019-09-04 10:18:56 +02:00
NM_UTILS_ERROR_MSG_REQ_AUTH_FAILED);
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
return;
}
g_variant_get (parameters, "(&ou)", &checkpoint_path, &add_timeout);
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_link_tail (&priv->auth_lst_head, nm_auth_chain_parent_lst_list (chain));
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
nm_auth_chain_set_data (chain, "audit-op", NM_AUDIT_OP_CHECKPOINT_ADJUST_ROLLBACK_TIMEOUT, NULL);
nm_auth_chain_set_data (chain, "checkpoint_path", g_strdup (checkpoint_path), g_free);
nm_auth_chain_set_data (chain, "add_timeout", GUINT_TO_POINTER (add_timeout), NULL);
nm_auth_chain_add_call (chain, NM_AUTH_PERMISSION_CHECKPOINT_ROLLBACK, TRUE);
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
static void
manager: keep reference on NMAuthManager singleton A singleton (NMManager) subscribing to another singleton (NMAuthManager) should take a reference on the latter, to ensure its lifetime is longer.
2016-07-01 14:25:34 +02:00
auth_mgr_changed (NMAuthManager *auth_manager, gpointer user_data)
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
{
/* Let clients know they should re-check their authorization */
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_dbus_object_emit_signal (user_data,
&interface_info_manager,
&signal_info_check_permissions,
"()");
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
}
#define KERN_RFKILL_OP_CHANGE_ALL 3
#define KERN_RFKILL_TYPE_WLAN 1
rfkill: toggle WWAN rfkill state on user enable/disable Poke the kernel's WWAN rfkill state when the user changes our WWANEnabled property, the same as we do for WiFi. Also restore saved WWAN state on startup, as we do for WiFi. No good reason why WWAN should be different here.
2013-05-31 14:11:56 -05:00
#define KERN_RFKILL_TYPE_WWAN 5
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
struct rfkill_event {
__u32 idx;
__u8 type;
__u8 op;
__u8 soft, hard;
core: use _nm_packed attribute instead of __attribute__((packed))
2017-01-16 16:08:20 +01:00
} _nm_packed;
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
static void
manager: use _LOGx() macros in nm-manager They give each logging message a "manager: " prefix.
2016-04-27 18:26:39 +02:00
rfkill_change (NMManager *self, const char *desc, RfKillType rtype, gboolean enabled)
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
{
int fd;
struct rfkill_event event;
ssize_t len;
all: cache errno in local variable before using it
2019-01-31 13:29:21 +01:00
int errsv;
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
rfkill: toggle WWAN rfkill state on user enable/disable Poke the kernel's WWAN rfkill state when the user changes our WWANEnabled property, the same as we do for WiFi. Also restore saved WWAN state on startup, as we do for WiFi. No good reason why WWAN should be different here.
2013-05-31 14:11:56 -05:00
g_return_if_fail (rtype == RFKILL_TYPE_WLAN || rtype == RFKILL_TYPE_WWAN);
all: use O_CLOEXEC for file descriptors
2016-12-10 15:28:15 +01:00
fd = open ("/dev/rfkill", O_RDWR | O_CLOEXEC);
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
if (fd < 0) {
if (errno == EACCES)
manager: add "rfkill" prefix to related logging messages
2017-06-07 13:13:55 +02:00
_LOGW (LOGD_RFKILL, "rfkill: (%s): failed to open killswitch device", desc);
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
return;
}
if (fcntl (fd, F_SETFL, O_NONBLOCK) < 0) {
manager: add "rfkill" prefix to related logging messages
2017-06-07 13:13:55 +02:00
_LOGW (LOGD_RFKILL, "rfkill: (%s): failed to set killswitch device for "
manager: use _LOGx() macros in nm-manager They give each logging message a "manager: " prefix.
2016-04-27 18:26:39 +02:00
"non-blocking operation", desc);
all: use nm_close() instead of close()
2017-11-14 14:22:21 +01:00
nm_close (fd);
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
return;
}
memset (&event, 0, sizeof (event));
event.op = KERN_RFKILL_OP_CHANGE_ALL;
rfkill: toggle WWAN rfkill state on user enable/disable Poke the kernel's WWAN rfkill state when the user changes our WWANEnabled property, the same as we do for WiFi. Also restore saved WWAN state on startup, as we do for WiFi. No good reason why WWAN should be different here.
2013-05-31 14:11:56 -05:00
switch (rtype) {
case RFKILL_TYPE_WLAN:
event.type = KERN_RFKILL_TYPE_WLAN;
break;
case RFKILL_TYPE_WWAN:
event.type = KERN_RFKILL_TYPE_WWAN;
break;
default:
g_assert_not_reached ();
}
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
event.soft = enabled ? 0 : 1;
len = write (fd, &event, sizeof (event));
if (len < 0) {
all: cache errno in local variable before using it
2019-01-31 13:29:21 +01:00
errsv = errno;
all: say Wi-Fi instead of "wifi" or "WiFi" Correct the spelling across the *entire* tree, including translations, comments, etc. It's easier that way. Even the places where it's not exposed to the user, such as tests, so that we learn how is it spelled correctly.
2018-11-21 11:32:38 +01:00
_LOGW (LOGD_RFKILL, "rfkill: (%s): failed to change Wi-Fi killswitch state: (%d) %s",
all: replace g_strerror() calls with nm_strerror_native()
2019-01-31 17:08:03 +01:00
desc, errsv, nm_strerror_native (errsv));
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
} else if (len == sizeof (event)) {
manager: add "rfkill" prefix to related logging messages
2017-06-07 13:13:55 +02:00
_LOGI (LOGD_RFKILL, "rfkill: %s hardware radio set %s",
manager: use _LOGx() macros in nm-manager They give each logging message a "manager: " prefix.
2016-04-27 18:26:39 +02:00
desc, enabled ? "enabled" : "disabled");
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
} else {
/* Failed to write full structure */
all: say Wi-Fi instead of "wifi" or "WiFi" Correct the spelling across the *entire* tree, including translations, comments, etc. It's easier that way. Even the places where it's not exposed to the user, such as tests, so that we learn how is it spelled correctly.
2018-11-21 11:32:38 +01:00
_LOGW (LOGD_RFKILL, "rfkill: (%s): failed to change Wi-Fi killswitch state", desc);
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
}
all: use nm_close() instead of close()
2017-11-14 14:22:21 +01:00
nm_close (fd);
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
}
static void
manager_radio_user_toggled (NMManager *self,
RadioState *rstate,
gboolean enabled)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
gboolean old_enabled, new_enabled;
rfkill: toggle WWAN rfkill state on user enable/disable Poke the kernel's WWAN rfkill state when the user changes our WWANEnabled property, the same as we do for WiFi. Also restore saved WWAN state on startup, as we do for WiFi. No good reason why WWAN should be different here.
2013-05-31 14:11:56 -05:00
/* Don't touch devices if asleep/networking disabled */
if (manager_sleeping (self))
return;
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
if (rstate->desc) {
manager: add "rfkill" prefix to related logging messages
2017-06-07 13:13:55 +02:00
_LOGD (LOGD_RFKILL, "rfkill: (%s): setting radio %s by user",
manager: use logging helpers
2016-03-02 11:38:26 +01:00
rstate->desc,
enabled ? "enabled" : "disabled");
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
}
/* Update enabled key in state file */
core: rename nm_config_run_state* to nm_config_state* After all, this state is stored persistently to /var/lib/NetworkManager, and not to volatile storage in /var/run. Hence the name is better. It's also shorter, so rename it. The commit is mostly trivial, including update of code comments and logging messages. Fixes: 1b43c880ba43260fe551b0ac923826f16737484f
2016-04-07 18:42:24 +02:00
nm_config_state_set (priv->config, TRUE, FALSE,
rstate->key, enabled);
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
/* When the user toggles the radio, their request should override any
* daemon (like ModemManager) enabled state that can be changed. For WWAN
* for example, we want the WwanEnabled property to reflect the daemon state
* too so that users can toggle the modem powered, but we don't want that
* daemon state to affect whether or not the user *can* turn it on, which is
* what the kernel rfkill state does. So we ignore daemon enabled state
* when determining what the new state should be since it shouldn't block
* the user's request.
*/
old_enabled = radio_enabled_for_rstate (rstate, TRUE);
rstate->user_enabled = enabled;
new_enabled = radio_enabled_for_rstate (rstate, FALSE);
if (new_enabled != old_enabled) {
rfkill: toggle WWAN rfkill state on user enable/disable Poke the kernel's WWAN rfkill state when the user changes our WWANEnabled property, the same as we do for WiFi. Also restore saved WWAN state on startup, as we do for WiFi. No good reason why WWAN should be different here.
2013-05-31 14:11:56 -05:00
/* Try to change the kernel rfkill state */
if (rstate->rtype == RFKILL_TYPE_WLAN || rstate->rtype == RFKILL_TYPE_WWAN)
manager: use _LOGx() macros in nm-manager They give each logging message a "manager: " prefix.
2016-04-27 18:26:39 +02:00
rfkill_change (self, rstate->desc, rstate->rtype, new_enabled);
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
rfkill: toggle WWAN rfkill state on user enable/disable Poke the kernel's WWAN rfkill state when the user changes our WWANEnabled property, the same as we do for WiFi. Also restore saved WWAN state on startup, as we do for WiFi. No good reason why WWAN should be different here.
2013-05-31 14:11:56 -05:00
manager_update_radio_enabled (self, rstate, new_enabled);
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
}
}
static gboolean
periodic_update_active_connection_timestamps (gpointer user_data)
{
NMManager *manager = NM_MANAGER (user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (manager);
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
NMActiveConnection *ac;
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
c_list_for_each_entry (ac, &priv->active_connections_lst_head, active_connections_lst) {
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
if (nm_active_connection_get_state (ac) == NM_ACTIVE_CONNECTION_STATE_ACTIVATED) {
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
nm_settings_connection_update_timestamp (nm_active_connection_get_settings_connection (ac),
settings: cache keyfile databases for "timestamps" and "seen-bssids" Only read the keyfile databases once and cache them for the remainder of the program. - this avoids the overhead of opening the file over and over again. - it also avoids the data changing without us expecting it. The state files are internal and we don't support changing it outside of NetworkManager. So in the base case we read the same data over and over. In the worst case, we read different data but are not interested in handling the changes. - only write the file when the content changes or before exiting (normally). - better log what is happening. - our state files tend to grow as we don't garbage collect old entries. Keeping this all in memory might be problematic. However, the right solution for this is that we come up with some form of garbage collection so that the state files are reaonsably small to begin with.
2019-05-03 14:33:23 +02:00
(guint64) time (NULL));
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
}
}
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
return G_SOURCE_CONTINUE;
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
core: use binary-search for nm_manager_set_capability() And drop the unused function nm_manager_check_capability(). I don't think we need such a function server-side, as the server usually has better ways to check whether a capability is supported.
2016-09-23 14:32:50 +02:00
void
nm_manager_set_capability (NMManager *self,
NMCapability cap)
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
{
core: use binary-search for nm_manager_set_capability() And drop the unused function nm_manager_check_capability(). I don't think we need such a function server-side, as the server usually has better ways to check whether a capability is supported.
2016-09-23 14:32:50 +02:00
NMManagerPrivate *priv;
guint32 cap_i;
gssize idx;
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
core: use binary-search for nm_manager_set_capability() And drop the unused function nm_manager_check_capability(). I don't think we need such a function server-side, as the server usually has better ways to check whether a capability is supported.
2016-09-23 14:32:50 +02:00
g_return_if_fail (NM_IS_MANAGER (self));
if (cap < 1 || cap > NM_CAPABILITY_TEAM)
g_return_if_reached ();
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
core: use binary-search for nm_manager_set_capability() And drop the unused function nm_manager_check_capability(). I don't think we need such a function server-side, as the server usually has better ways to check whether a capability is supported.
2016-09-23 14:32:50 +02:00
cap_i = (guint32) cap;
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
core: use binary-search for nm_manager_set_capability() And drop the unused function nm_manager_check_capability(). I don't think we need such a function server-side, as the server usually has better ways to check whether a capability is supported.
2016-09-23 14:32:50 +02:00
priv = NM_MANAGER_GET_PRIVATE (self);
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
shared: move nm_utils_array_find_binary_search() to shared utils
2018-07-28 12:26:37 +02:00
idx = nm_utils_array_find_binary_search (&g_array_index (priv->capabilities, guint32, 0),
sizeof (guint32),
priv->capabilities->len,
&cap_i,
nm_cmp_uint32_p_with_data,
NULL);
core: use binary-search for nm_manager_set_capability() And drop the unused function nm_manager_check_capability(). I don't think we need such a function server-side, as the server usually has better ways to check whether a capability is supported.
2016-09-23 14:32:50 +02:00
if (idx >= 0)
return;
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
core: use binary-search for nm_manager_set_capability() And drop the unused function nm_manager_check_capability(). I don't think we need such a function server-side, as the server usually has better ways to check whether a capability is supported.
2016-09-23 14:32:50 +02:00
nm_assert ((~idx) <= (gssize) priv->capabilities->len);
g_array_insert_val (priv->capabilities, ~idx, cap_i);
_notify (self, PROP_CAPABILITIES);
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
core: nm_singleton_instance_register() of NMManager instance Register the singleton instance of NMManager as we do for other singletons. That way, we get automatic destruction and the singleton instance get's properly cleared (when the instance gets destroyed).
2015-08-10 16:38:26 +02:00
NM_DEFINE_SINGLETON_REGISTER (NMManager);
core: split nm_manager_get() to simplify manager creation OLPC Mesh code now doesn't have to be updated every time we change the manager's creation arguments. We could make all these arguments GObject properties of the manager too, but that's more code and we'd eventually like to figure out a better solution for letting non-NMManager code listen for device addition/removal.
2011-09-26 11:30:24 -05:00
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
NMManager *
core: split nm_manager_get() to simplify manager creation OLPC Mesh code now doesn't have to be updated every time we change the manager's creation arguments. We could make all these arguments GObject properties of the manager too, but that's more code and we'd eventually like to figure out a better solution for letting non-NMManager code listen for device addition/removal.
2011-09-26 11:30:24 -05:00
nm_manager_get (void)
{
manager: downgrade assertions to g_critical() in manager's singleton getters
2016-01-25 16:29:51 +01:00
g_return_val_if_fail (singleton_instance, NULL);
core: make NMManager singleton more like others Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
2015-08-03 09:26:31 -04:00
return singleton_instance;
core: split nm_manager_get() to simplify manager creation OLPC Mesh code now doesn't have to be updated every time we change the manager's creation arguments. We could make all these arguments GObject properties of the manager too, but that's more code and we'd eventually like to figure out a better solution for letting non-NMManager code listen for device addition/removal.
2011-09-26 11:30:24 -05:00
}
core: add nm_settings_get() singleton getter for NMSettings
2016-05-16 18:05:02 +02:00
NMSettings *
nm_settings_get (void)
{
g_return_val_if_fail (singleton_instance, NULL);
return NM_MANAGER_GET_PRIVATE (singleton_instance)->settings;
}
core: split nm_manager_get() to simplify manager creation OLPC Mesh code now doesn't have to be updated every time we change the manager's creation arguments. We could make all these arguments GObject properties of the manager too, but that's more code and we'd eventually like to figure out a better solution for letting non-NMManager code listen for device addition/removal.
2011-09-26 11:30:24 -05:00
NMManager *
config: let NMConfig handle "NetworkManager.state" file (bgo#764474) Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
2015-11-06 16:45:27 +01:00
nm_manager_setup (void)
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
{
core: make NMManager singleton more like others Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
2015-08-03 09:26:31 -04:00
NMManager *self;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
manager: downgrade assertions to g_critical() in manager's singleton getters
2016-01-25 16:29:51 +01:00
g_return_val_if_fail (!singleton_instance, singleton_instance);
manager: initilize NETWORKING_ENABLED as constructor paramter
2016-01-18 14:22:50 +01:00
config: let NMConfig handle "NetworkManager.state" file (bgo#764474) Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
2015-11-06 16:45:27 +01:00
self = g_object_new (NM_TYPE_MANAGER, NULL);
manager: initilize NETWORKING_ENABLED as constructor paramter
2016-01-18 14:22:50 +01:00
nm_assert (NM_IS_MANAGER (self));
singleton_instance = self;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
manager: refactor construction of manager singleton instance nm_manager_setup() should only call g_object_new() and leave most of the initialization to the GObject constructor.
2016-01-18 14:18:50 +01:00
nm_singleton_instance_register ();
core: don't log plain pointer values for singletons Logging pointer values allows to defeat ASLR. Don't do that.
2019-05-05 15:40:04 +02:00
nm_log_dbg (LOGD_CORE, "setup %s singleton ("NM_HASH_OBFUSCATE_PTR_FMT")",
"NMManager", NM_HASH_OBFUSCATE_PTR (singleton_instance));
manager: refactor construction of manager singleton instance nm_manager_setup() should only call g_object_new() and leave most of the initialization to the GObject constructor.
2016-01-18 14:18:50 +01:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_dbus_object_export (NM_DBUS_OBJECT (self));
manager: refactor construction of manager singleton instance nm_manager_setup() should only call g_object_new() and leave most of the initialization to the GObject constructor.
2016-01-18 14:18:50 +01:00
return self;
}
static void
constructed (GObject *object)
{
NMManager *self = NM_MANAGER (object);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
core: rename nm_config_run_state* to nm_config_state* After all, this state is stored persistently to /var/lib/NetworkManager, and not to volatile storage in /var/run. Hence the name is better. It's also shorter, so rename it. The commit is mostly trivial, including update of code comments and logging messages. Fixes: 1b43c880ba43260fe551b0ac923826f16737484f
2016-04-07 18:42:24 +02:00
const NMConfigState *state;
manager: refactor construction of manager singleton instance nm_manager_setup() should only call g_object_new() and leave most of the initialization to the GObject constructor.
2016-01-18 14:18:50 +01:00
G_OBJECT_CLASS (nm_manager_parent_class)->constructed (object);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
core: make NMManager singleton more like others Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
2015-08-03 09:26:31 -04:00
priv->settings = nm_settings_new ();
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_dbus_object_export (NM_DBUS_OBJECT (priv->settings));
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
core: make NMManager singleton more like others Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
2015-08-03 09:26:31 -04:00
g_signal_connect (priv->settings, "notify::" NM_SETTINGS_STARTUP_COMPLETE,
G_CALLBACK (settings_startup_complete_changed), self);
g_signal_connect (priv->settings, "notify::" NM_SETTINGS_UNMANAGED_SPECS,
G_CALLBACK (system_unmanaged_devices_changed_cb), self);
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
g_signal_connect (priv->settings, NM_SETTINGS_SIGNAL_CONNECTION_FLAGS_CHANGED, G_CALLBACK (connection_flags_changed), self);
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
priv->hostname_manager = g_object_ref (nm_hostname_manager_get ());
g_signal_connect (priv->hostname_manager, "notify::" NM_HOSTNAME_MANAGER_HOSTNAME,
G_CALLBACK (hostname_changed_cb), self);
settings: merge "connection-updated" and "connection-updated-by-user" signals This is mostly interesting of NMPolicy, which no longer needs to subscribe to two almost identical signals (where the by-user signal was always invoked together with the plain "updated" signal).
2016-04-13 16:03:06 +02:00
/*
* Do not delete existing virtual devices to keep connectivity up.
* Virtual devices are reused when NetworkManager is restarted.
* Hence, don't react on NM_SETTINGS_SIGNAL_CONNECTION_REMOVED.
*/
core: make NMManager singleton more like others Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
2015-08-03 09:26:31 -04:00
priv->policy = nm_policy_new (self, priv->settings);
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
g_signal_connect (priv->policy, "notify::" NM_POLICY_DEFAULT_IP4_AC,
G_CALLBACK (policy_default_ac_changed), self);
g_signal_connect (priv->policy, "notify::" NM_POLICY_DEFAULT_IP6_AC,
G_CALLBACK (policy_default_ac_changed), self);
g_signal_connect (priv->policy, "notify::" NM_POLICY_ACTIVATING_IP4_AC,
G_CALLBACK (policy_activating_ac_changed), self);
g_signal_connect (priv->policy, "notify::" NM_POLICY_ACTIVATING_IP6_AC,
G_CALLBACK (policy_activating_ac_changed), self);
core: make NMPolicy a GObject And make it owned by NMManager, rather than being a separate top-level object.
2013-08-22 10:10:17 -04:00
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
priv->config = g_object_ref (nm_config_get ());
g_signal_connect (G_OBJECT (priv->config),
NM_CONFIG_SIGNAL_CONFIG_CHANGED,
G_CALLBACK (_config_changed_cb),
core: make NMManager singleton more like others Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
2015-08-03 09:26:31 -04:00
self);
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
core: rename nm_config_run_state* to nm_config_state* After all, this state is stored persistently to /var/lib/NetworkManager, and not to volatile storage in /var/run. Hence the name is better. It's also shorter, so rename it. The commit is mostly trivial, including update of code comments and logging messages. Fixes: 1b43c880ba43260fe551b0ac923826f16737484f
2016-04-07 18:42:24 +02:00
state = nm_config_state_get (priv->config);
config: let NMConfig handle "NetworkManager.state" file (bgo#764474) Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
2015-11-06 16:45:27 +01:00
core: rename nm_config_run_state* to nm_config_state* After all, this state is stored persistently to /var/lib/NetworkManager, and not to volatile storage in /var/run. Hence the name is better. It's also shorter, so rename it. The commit is mostly trivial, including update of code comments and logging messages. Fixes: 1b43c880ba43260fe551b0ac923826f16737484f
2016-04-07 18:42:24 +02:00
priv->net_enabled = state->net_enabled;
config: let NMConfig handle "NetworkManager.state" file (bgo#764474) Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
2015-11-06 16:45:27 +01:00
core: rename nm_config_run_state* to nm_config_state* After all, this state is stored persistently to /var/lib/NetworkManager, and not to volatile storage in /var/run. Hence the name is better. It's also shorter, so rename it. The commit is mostly trivial, including update of code comments and logging messages. Fixes: 1b43c880ba43260fe551b0ac923826f16737484f
2016-04-07 18:42:24 +02:00
priv->radio_states[RFKILL_TYPE_WLAN].user_enabled = state->wifi_enabled;
priv->radio_states[RFKILL_TYPE_WWAN].user_enabled = state->wwan_enabled;
config: let NMConfig handle "NetworkManager.state" file (bgo#764474) Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
2015-11-06 16:45:27 +01:00
core: split NMRfkillManager out of NMUdevManager Split the rfkill-monitoring parts of NMUdevManager into a separate class. Now NMUdevManager only handles device enumeration.
2013-05-09 10:24:08 -04:00
priv->rfkill_mgr = nm_rfkill_manager_new ();
g_signal_connect (priv->rfkill_mgr,
core: use #define for "rfkill-changed" signal name (cherry picked from commit 640fbec855907b19952c8f0411f8500f1008fd7d)
2016-08-23 11:45:51 +02:00
NM_RFKILL_MANAGER_SIGNAL_RFKILL_CHANGED,
core: split NMRfkillManager out of NMUdevManager Split the rfkill-monitoring parts of NMUdevManager into a separate class. Now NMUdevManager only handles device enumeration.
2013-05-09 10:24:08 -04:00
G_CALLBACK (rfkill_manager_rfkill_changed_cb),
core: make NMManager singleton more like others Rename nm_manager_new() to nm_manager_setup(), and change the local @singleton variable to @singleton_instance. (Also, add a local @self variable inside nm_manager_setup().) Also, make NMManager own NMSettings rather than having them both owned by main().
2015-08-03 09:26:31 -04:00
self);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
all: say Wi-Fi instead of "wifi" or "WiFi" Correct the spelling across the *entire* tree, including translations, comments, etc. It's easier that way. Even the places where it's not exposed to the user, such as tests, so that we learn how is it spelled correctly.
2018-11-21 11:32:38 +01:00
/* Force kernel Wi-Fi/WWAN rfkill state to follow NM saved Wi-Fi/WWAN state
rfkill: toggle WWAN rfkill state on user enable/disable Poke the kernel's WWAN rfkill state when the user changes our WWANEnabled property, the same as we do for WiFi. Also restore saved WWAN state on startup, as we do for WiFi. No good reason why WWAN should be different here.
2013-05-31 14:11:56 -05:00
* in case the BIOS doesn't save rfkill state, and to be consistent with user
* changes to the WirelessEnabled/WWANEnabled properties which toggle kernel
* rfkill.
rfkill: set kernel WiFi rfkill state to cached state on startup 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.
2013-02-06 12:59:50 -06:00
*/
manager: use _LOGx() macros in nm-manager They give each logging message a "manager: " prefix.
2016-04-27 18:26:39 +02:00
rfkill_change (self, priv->radio_states[RFKILL_TYPE_WLAN].desc, RFKILL_TYPE_WLAN, priv->radio_states[RFKILL_TYPE_WLAN].user_enabled);
rfkill_change (self, priv->radio_states[RFKILL_TYPE_WWAN].desc, RFKILL_TYPE_WWAN, priv->radio_states[RFKILL_TYPE_WWAN].user_enabled);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
}
core: allow multiple authority changed callbacks We'll need this later; just keep all registered callbacks in a list and track them by func/data.
2011-07-01 14:16:52 -05:00
static void
manager: use logging helpers
2016-03-02 11:38:26 +01:00
nm_manager_init (NMManager *self)
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
{
manager: use logging helpers
2016-03-02 11:38:26 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
guint i;
GFile *file;
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
c_list_init (&priv->auth_lst_head);
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
c_list_init (&priv->link_cb_lst);
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
c_list_init (&priv->devices_lst_head);
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
c_list_init (&priv->active_connections_lst_head);
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
c_list_init (&priv->async_op_lst_head);
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
c_list_init (&priv->delete_volatile_connection_lst_head);
core: create virtual device on settings changes in idle handler The callback from NMSettings about adding/updating a settings comes from a deep call-stack already. We don't know the context of it, and we shouldn't just right away create the profile. Instead, schedule an action to create it in an idle handler.
2019-06-30 10:33:28 +02:00
c_list_init (&priv->connection_changed_on_idle_lst);
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
priv->platform = g_object_ref (NM_PLATFORM_GET);
capabilities: fix destroying capabilities in dispose() dispose() must be re-entrant. Thus, at the very least it must clear the priv->capabilities after freeing the array. While at it, move it to finalize (which is only called once) and move initialization of the array from "constructed" to nm_manager_init() which is called first.
2016-09-23 13:24:10 +02:00
priv->capabilities = g_array_new (FALSE, FALSE, sizeof (guint32));
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
/* Initialize rfkill structures and states */
memset (priv->radio_states, 0, sizeof (priv->radio_states));
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
priv->radio_states[RFKILL_TYPE_WLAN].user_enabled = TRUE;
core: rename nm_config_run_state* to nm_config_state* After all, this state is stored persistently to /var/lib/NetworkManager, and not to volatile storage in /var/run. Hence the name is better. It's also shorter, so rename it. The commit is mostly trivial, including update of code comments and logging messages. Fixes: 1b43c880ba43260fe551b0ac923826f16737484f
2016-04-07 18:42:24 +02:00
priv->radio_states[RFKILL_TYPE_WLAN].key = NM_CONFIG_STATE_PROPERTY_WIFI_ENABLED;
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
priv->radio_states[RFKILL_TYPE_WLAN].prop = NM_MANAGER_WIRELESS_ENABLED;
priv->radio_states[RFKILL_TYPE_WLAN].hw_prop = NM_MANAGER_WIRELESS_HARDWARE_ENABLED;
all: say Wi-Fi instead of "wifi" or "WiFi" Correct the spelling across the *entire* tree, including translations, comments, etc. It's easier that way. Even the places where it's not exposed to the user, such as tests, so that we learn how is it spelled correctly.
2018-11-21 11:32:38 +01:00
priv->radio_states[RFKILL_TYPE_WLAN].desc = "Wi-Fi";
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
priv->radio_states[RFKILL_TYPE_WLAN].rtype = RFKILL_TYPE_WLAN;
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
priv->radio_states[RFKILL_TYPE_WWAN].user_enabled = TRUE;
core: rename nm_config_run_state* to nm_config_state* After all, this state is stored persistently to /var/lib/NetworkManager, and not to volatile storage in /var/run. Hence the name is better. It's also shorter, so rename it. The commit is mostly trivial, including update of code comments and logging messages. Fixes: 1b43c880ba43260fe551b0ac923826f16737484f
2016-04-07 18:42:24 +02:00
priv->radio_states[RFKILL_TYPE_WWAN].key = NM_CONFIG_STATE_PROPERTY_WWAN_ENABLED;
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
priv->radio_states[RFKILL_TYPE_WWAN].prop = NM_MANAGER_WWAN_ENABLED;
priv->radio_states[RFKILL_TYPE_WWAN].hw_prop = NM_MANAGER_WWAN_HARDWARE_ENABLED;
priv->radio_states[RFKILL_TYPE_WWAN].desc = "WWAN";
priv->radio_states[RFKILL_TYPE_WWAN].rtype = RFKILL_TYPE_WWAN;
core: track active connections directly in the manager 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.
2012-08-22 17:11:31 -05:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
for (i = 0; i < RFKILL_TYPE_MAX; i++)
priv->radio_states[i].hw_enabled = TRUE;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
priv->sleeping = FALSE;
priv->state = NM_STATE_DISCONNECTED;
priv->startup = TRUE;
core: make NMPolicy a GObject And make it owned by NMManager, rather than being a separate top-level object.
2013-08-22 10:10:17 -04:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
/* sleep/wake handling */
sleep-monitor: make sleep-monitor not a singleton The only user of the sleep-monitor singleton was NMManager anyway. Also, even if we ever get more users that are interested in the SLEEPING signal, we would hook them onto NMManager -- because NMManager should collect, coordinate and possibly forward the SLEEPING signal. In no case, another object should react on the SLEEPING signal and thus bypassing the NMManager.
2016-04-28 13:45:49 +02:00
priv->sleep_monitor = nm_sleep_monitor_new ();
core: declare nm_sleep_monitor_get() using NM_DEFINE_SINGLETON_GETTER() Also no longer increment the reference count in the getter and properly disconnect the signals in NMManager:dispose(). Also use the defines for the signal names instead of plain strings.
2015-01-05 16:37:45 +01:00
g_signal_connect (priv->sleep_monitor, NM_SLEEP_MONITOR_SLEEPING,
manager: use logging helpers
2016-03-02 11:38:26 +01:00
G_CALLBACK (sleeping_cb), self);
core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002) This commit changes rfkill state handling slightly in the following ways: - when checking whether a user toggle request can change radio state, ignore states we can change in radio_enabled_for_rstate() as a result of the toggle; this fixes WiMAX enable/disable because a softblock can be changed by telling wimaxd to enable the radio. As a side-effect this also fixes handling of WiFi when altering the rfkill state as well. - make WiFi user toggle requests change wifi killswitch state; this has been long requested and on the TODO list for a while and it turns out to be a lot easier to do these days. This provides the expected behavior when disabling wireless from user agent menus since there's not an easy way to do this other than dropping to shell and running rfkill.
2011-04-22 14:56:31 -05:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
/* Listen for authorization changes */
manager: keep reference on NMAuthManager singleton A singleton (NMManager) subscribing to another singleton (NMAuthManager) should take a reference on the latter, to ensure its lifetime is longer.
2016-07-01 14:25:34 +02:00
priv->auth_mgr = g_object_ref (nm_auth_manager_get ());
g_signal_connect (priv->auth_mgr,
auth: rework polkit autorization to use DBUS interface directly This makes NetworkManager independent of <polkit/polkit.h> development headers and libpolkit-gobject-1.so library. Instead communicate directly with polkit using its DBUS interface. PolicyKit support is now always compiled in. You can control polkit authorization with the configuration option [main] auth-polkit=yes|no If the configure option is omitted, a build time default value is used. This default value can be set with the configure option --enable-polkit. This commit adds a new class NMAuthManager that reimplements the relevant DBUS client parts. It takes source code from the polkit library. https://bugzilla.gnome.org/show_bug.cgi?id=734146 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-14 13:34:57 +02:00
NM_AUTH_MANAGER_SIGNAL_CHANGED,
manager: keep reference on NMAuthManager singleton A singleton (NMManager) subscribing to another singleton (NMAuthManager) should take a reference on the latter, to ensure its lifetime is longer.
2016-07-01 14:25:34 +02:00
G_CALLBACK (auth_mgr_changed),
manager: use logging helpers
2016-03-02 11:38:26 +01:00
self);
auth: rework polkit autorization to use DBUS interface directly This makes NetworkManager independent of <polkit/polkit.h> development headers and libpolkit-gobject-1.so library. Instead communicate directly with polkit using its DBUS interface. PolicyKit support is now always compiled in. You can control polkit authorization with the configuration option [main] auth-polkit=yes|no If the configure option is omitted, a build time default value is used. This default value can be set with the configure option --enable-polkit. This commit adds a new class NMAuthManager that reimplements the relevant DBUS client parts. It takes source code from the polkit library. https://bugzilla.gnome.org/show_bug.cgi?id=734146 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-14 13:34:57 +02:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
/* Monitor the firmware directory */
if (strlen (KERNEL_FIRMWARE_DIR)) {
file = g_file_new_for_path (KERNEL_FIRMWARE_DIR "/");
priv->fw_monitor = g_file_monitor_directory (file, G_FILE_MONITOR_NONE, NULL, NULL);
g_object_unref (file);
core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002) This commit changes rfkill state handling slightly in the following ways: - when checking whether a user toggle request can change radio state, ignore states we can change in radio_enabled_for_rstate() as a result of the toggle; this fixes WiMAX enable/disable because a softblock can be changed by telling wimaxd to enable the radio. As a side-effect this also fixes handling of WiFi when altering the rfkill state as well. - make WiFi user toggle requests change wifi killswitch state; this has been long requested and on the TODO list for a while and it turns out to be a lot easier to do these days. This provides the expected behavior when disabling wireless from user agent menus since there's not an easy way to do this other than dropping to shell and running rfkill.
2011-04-22 14:56:31 -05:00
}
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
if (priv->fw_monitor) {
g_signal_connect (priv->fw_monitor, "changed",
G_CALLBACK (firmware_dir_changed),
manager: use logging helpers
2016-03-02 11:38:26 +01:00
self);
_LOGI (LOGD_CORE, "monitoring kernel firmware directory '%s'.",
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
KERNEL_FIRMWARE_DIR);
core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002) This commit changes rfkill state handling slightly in the following ways: - when checking whether a user toggle request can change radio state, ignore states we can change in radio_enabled_for_rstate() as a result of the toggle; this fixes WiMAX enable/disable because a softblock can be changed by telling wimaxd to enable the radio. As a side-effect this also fixes handling of WiFi when altering the rfkill state as well. - make WiFi user toggle requests change wifi killswitch state; this has been long requested and on the TODO list for a while and it turns out to be a lot easier to do these days. This provides the expected behavior when disabling wireless from user agent menus since there's not an easy way to do this other than dropping to shell and running rfkill.
2011-04-22 14:56:31 -05:00
} else {
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGW (LOGD_CORE, "failed to monitor kernel firmware directory '%s'.",
KERNEL_FIRMWARE_DIR);
core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002) This commit changes rfkill state handling slightly in the following ways: - when checking whether a user toggle request can change radio state, ignore states we can change in radio_enabled_for_rstate() as a result of the toggle; this fixes WiMAX enable/disable because a softblock can be changed by telling wimaxd to enable the radio. As a side-effect this also fixes handling of WiFi when altering the rfkill state as well. - make WiFi user toggle requests change wifi killswitch state; this has been long requested and on the TODO list for a while and it turns out to be a lot easier to do these days. This provides the expected behavior when disabling wireless from user agent menus since there's not an easy way to do this other than dropping to shell and running rfkill.
2011-04-22 14:56:31 -05:00
}
wifi: ensure Enabled state is preserved regardless of rfkill (bgo #624479) Previously the "Enable Wireless" state was somewhat tied to rfkill state, in that when NM started up, rfkill state would take precedence over what was listed in the state file, and if you rmmodded your wifi driver and then modprobed it again after disabling wifi from the menu, wifi would magically become re-enabled becuase rfkill state changed. Fix that by creating a third wifi/wwan enable state that tracks the actual user preference instead of just the rfkill state so that when the user disables wifi it stays disabled, regardless of what happens with rfkill.
2010-09-01 17:08:10 -05:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
/* Update timestamps in active connections */
manager: use logging helpers
2016-03-02 11:38:26 +01:00
priv->timestamp_update_id = g_timeout_add_seconds (300, (GSourceFunc) periodic_update_active_connection_timestamps, self);
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
priv->metered = NM_METERED_UNKNOWN;
all: use nm_direct_hash() instead of g_direct_hash() We also do this for libnm, where it causes visible changes in behavior. But if somebody would rely on the hashing implementation for hash tables, it would be seriously flawed.
2017-11-15 16:06:43 +01:00
priv->sleep_devices = g_hash_table_new (nm_direct_hash, NULL);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
}
static void
get_property (GObject *object, guint prop_id,
core: refactor setting of D-Bus properties via NMManager - 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.
2015-09-15 11:34:00 +02:00
GValue *value, GParamSpec *pspec)
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
{
NMManager *self = NM_MANAGER (object);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
NMConfigData *config_data;
const NMGlobalDnsConfig *dns_config;
core: add PrimaryConnectionType property to NMManager (bgo #739080) This will provide an extremely easy way for applications to find out what type of connection the system is currently using. They might want to do this to avoid using data if a phone is on a 3G connection, for example. Having this as a separate property provides at least two advantages: 1) it reduces code complexity for those wanting only this one simple piece of information 2) we could allow access to this property (but nothing else) to privilege-separated applications in the future This patch adds the missing nm_active_connection_get_connection_type() which was in the header file but never actually implemented. https://bugzilla.gnome.org/show_bug.cgi?id=739080
2014-10-23 13:56:52 -04:00
const char *type;
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
const char *path;
NMActiveConnection *ac;
GPtrArray *ptrarr;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
switch (prop_id) {
core: add Version property to org.freedesktop.NetworkManager interface
2010-09-27 10:34:56 +02:00
case PROP_VERSION:
g_value_set_string (value, VERSION);
break;
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
case PROP_CAPABILITIES:
capabilities: fix data type to "u" / uint32 The property NM_MANAGER_CAPABILITIES was already "au". The types must be used consistently.
2016-09-23 13:16:20 +02:00
g_value_set_variant (value, g_variant_new_fixed_array (G_VARIANT_TYPE ("u"),
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
priv->capabilities->data,
priv->capabilities->len,
capabilities: fix data type to "u" / uint32 The property NM_MANAGER_CAPABILITIES was already "au". The types must be used consistently.
2016-09-23 13:16:20 +02:00
sizeof (guint32)));
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
break;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
case PROP_STATE:
g_value_set_uint (value, priv->state);
break;
core: add NMManager:startup property Add a property on NMManager indicating that it is currently starting up and activating startup-time/boot-time network connections. "startup" is initially TRUE, and becomes FALSE once all NMDevices report that they have no pending activity (eg, trying to activate, waiting for a wifi scan to complete, etc). This is tracked via a new NMDevice:has-pending-activity property, which is maintained partially by the device itself, and partially by other parts of the code.
2013-08-13 17:45:34 -04:00
case PROP_STARTUP:
g_value_set_boolean (value, priv->startup);
break;
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
case PROP_NETWORKING_ENABLED:
g_value_set_boolean (value, priv->net_enabled);
break;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
case PROP_WIRELESS_ENABLED:
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
g_value_set_boolean (value, radio_enabled_for_type (self, RFKILL_TYPE_WLAN, TRUE));
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
break;
case PROP_WIRELESS_HARDWARE_ENABLED:
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
g_value_set_boolean (value, priv->radio_states[RFKILL_TYPE_WLAN].hw_enabled);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
break;
manager: add WWAN enable/disable support
2009-12-23 00:18:18 -08:00
case PROP_WWAN_ENABLED:
wwan: fix enabled state detection (bgo #647216) Since the user state stuff got committed in 0.8.2, WWAN enable state has been somewhat broken. The problem is that we want two things: (1) that the current modem enabled state is reflected in the WwanEnabled property, and (2) that enabled state should not affect the user's ability to enable the modem via the UI. The code did not properly separate these two. For all automatic decisions and properties (ie the WwanEnabled property, setting the initial enabled state on startup or hotplug, etc) the ModemManager enabled state should be respected. But the user should be able to override that state by turn WWAN on. This calls for a fourth enabled check that modems have, the 'daemon' state, distinct from the hardware and software kernel rfkill states and from the user's chosen enabled/disabled state. Add that new check. The actual problem was in manager_radio_user_toggled() where after updating the user enabled state, new_enabled still equaled old_enabled, because the kernel rfkill state was a combination of both the kernel rfkill state *and* the ModemManager enabled state, so the manager_update_radio_enabled() call would never happen and the modem would never become enabled as a result of a user request.
2011-04-13 21:58:25 -05:00
g_value_set_boolean (value, radio_enabled_for_type (self, RFKILL_TYPE_WWAN, TRUE));
manager: add WWAN enable/disable support
2009-12-23 00:18:18 -08:00
break;
case PROP_WWAN_HARDWARE_ENABLED:
g_value_set_boolean (value, priv->radio_states[RFKILL_TYPE_WWAN].hw_enabled);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
break;
wimax: Implement RFKILL handling Implement and export over DBus WiMAX enable/disable and hardware state query.
2009-12-29 11:27:10 +02:00
case PROP_WIMAX_ENABLED:
manager: remove WiMAX rfkill flag from NMManger WiMAX support was dropped in commit 721e917cb6c3f6bea7e856aaed0cd49626887db1. Also, remove support for the WiMAX rfkill flag and only preserve the D-Bus property for backward compatibility.
2015-08-10 16:56:21 +02:00
g_value_set_boolean (value, FALSE);
wimax: Implement RFKILL handling Implement and export over DBus WiMAX enable/disable and hardware state query.
2009-12-29 11:27:10 +02:00
break;
case PROP_WIMAX_HARDWARE_ENABLED:
manager: remove WiMAX rfkill flag from NMManger WiMAX support was dropped in commit 721e917cb6c3f6bea7e856aaed0cd49626887db1. Also, remove support for the WiMAX rfkill flag and only preserve the D-Bus property for backward compatibility.
2015-08-10 16:56:21 +02:00
g_value_set_boolean (value, FALSE);
wimax: Implement RFKILL handling Implement and export over DBus WiMAX enable/disable and hardware state query.
2009-12-29 11:27:10 +02:00
break;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
case PROP_ACTIVE_CONNECTIONS:
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
ptrarr = g_ptr_array_new ();
c_list_for_each_entry (ac, &priv->active_connections_lst_head, active_connections_lst) {
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
path = nm_dbus_object_get_path (NM_DBUS_OBJECT (ac));
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
if (path)
g_ptr_array_add (ptrarr, g_strdup (path));
}
g_ptr_array_add (ptrarr, NULL);
g_value_take_boxed (value, g_ptr_array_free (ptrarr, FALSE));
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
break;
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
case PROP_CONNECTIVITY:
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
g_value_set_uint (value, priv->connectivity_state);
core: provide additional network connectivity information NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive portal" and "limited network connectivity" (ie, connected to a router that has lost its upstream connection). Add a new NMManager :connectivity property to provide this information. Also add a CheckConnectivity method, which can be used to force NM to re-check the connectivity state, which could be called by a client after it completed a portal login, or fixed a network problem.
2013-07-30 16:31:31 -04:00
break;
manager: add connectivity-check-{available,enabled} properties. https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:20:04 +08:00
case PROP_CONNECTIVITY_CHECK_AVAILABLE:
config_data = nm_config_get_data (priv->config);
g_value_set_boolean (value, nm_config_data_get_connectivity_uri (config_data) != NULL);
break;
case PROP_CONNECTIVITY_CHECK_ENABLED:
connectivity: emit properties-changed about connectivity settings
2018-04-10 15:55:16 +02:00
g_value_set_boolean (value, concheck_enabled (self, NULL));
manager: add connectivity-check-{available,enabled} properties. https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:20:04 +08:00
break;
libnm,core: Add ConnectivityCheckUri property and accessors So that applications like GNOME Shell can hit the same URI to show the captive portal login page. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/209
2019-07-22 15:55:15 +01:00
case PROP_CONNECTIVITY_CHECK_URI:
config_data = nm_config_get_data (priv->config);
g_value_set_string (value, nm_config_data_get_connectivity_uri (config_data));
break;
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
case PROP_PRIMARY_CONNECTION:
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_dbus_utils_g_value_set_object_path (value, priv->primary_connection);
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
break;
core: add PrimaryConnectionType property to NMManager (bgo #739080) This will provide an extremely easy way for applications to find out what type of connection the system is currently using. They might want to do this to avoid using data if a phone is on a 3G connection, for example. Having this as a separate property provides at least two advantages: 1) it reduces code complexity for those wanting only this one simple piece of information 2) we could allow access to this property (but nothing else) to privilege-separated applications in the future This patch adds the missing nm_active_connection_get_connection_type() which was in the header file but never actually implemented. https://bugzilla.gnome.org/show_bug.cgi?id=739080
2014-10-23 13:56:52 -04:00
case PROP_PRIMARY_CONNECTION_TYPE:
core: separate active and applied connection 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
2015-07-14 16:53:24 +02:00
type = NULL;
if (priv->primary_connection) {
NMConnection *con;
con = nm_active_connection_get_applied_connection (priv->primary_connection);
if (con)
type = nm_connection_get_connection_type (con);
}
all: use the elvis operator wherever possible Coccinelle: @@ expression a, b; @@ -a ? a : b +a ?: b Applied with: spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir . With some manual adjustments on spots that Cocci didn't catch for reasons unknown. Thanks to the marvelous effort of the GNU compiler developer we can now spare a couple of bits that could be used for more important things, like this commit message. Standards commitees yet have to catch up.
2018-04-24 11:20:03 +02:00
g_value_set_string (value, type ?: "");
core: add PrimaryConnectionType property to NMManager (bgo #739080) This will provide an extremely easy way for applications to find out what type of connection the system is currently using. They might want to do this to avoid using data if a phone is on a 3G connection, for example. Having this as a separate property provides at least two advantages: 1) it reduces code complexity for those wanting only this one simple piece of information 2) we could allow access to this property (but nothing else) to privilege-separated applications in the future This patch adds the missing nm_active_connection_get_connection_type() which was in the header file but never actually implemented. https://bugzilla.gnome.org/show_bug.cgi?id=739080
2014-10-23 13:56:52 -04:00
break;
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
case PROP_ACTIVATING_CONNECTION:
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
nm_dbus_utils_g_value_set_object_path (value, priv->activating_connection);
core: add NMManager:primary-connection and :activating-connection Add properties to track the "primary" connection (ie, the active connection with either the default route, or the route to the VPN with the default route), and the active connection that is currently activating, and likely to become the :primary-connection when it completes. https://bugzilla.gnome.org/show_bug.cgi?id=704841
2013-08-22 13:06:51 -04:00
break;
core: clear invalid tag on failed connections when sleeping So they'll get tried again on wakeup/resume.
2009-10-20 15:25:04 -07:00
case PROP_SLEEPING:
g_value_set_boolean (value, priv->sleeping);
break;
api/core: add Devices property to the Manager
2014-01-08 12:18:33 -06:00
case PROP_DEVICES:
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
g_value_take_boxed (value,
nm_utils_strv_make_deep_copied (_get_devices_paths (self,
FALSE)));
api/core: add Devices property to the Manager
2014-01-08 12:18:33 -06:00
break;
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
case PROP_METERED:
g_value_set_uint (value, priv->metered);
break;
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
case PROP_GLOBAL_DNS_CONFIGURATION:
config_data = nm_config_get_data (priv->config);
dns_config = nm_config_data_get_global_dns_config (config_data);
nm_global_dns_config_to_dbus (dns_config, value);
break;
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
case PROP_ALL_DEVICES:
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
g_value_take_boxed (value,
nm_utils_strv_make_deep_copied (_get_devices_paths (self,
TRUE)));
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
break;
core: export checkpoint list over D-Bus
2017-10-21 16:05:14 +02:00
case PROP_CHECKPOINTS:
checkpoint: don't explicitly track checkpoints in a GHashTable We already have a GHashTable for exported objects. We can use that if we want to look up by path efficiently.
2018-03-27 16:19:20 +02:00
g_value_take_boxed (value,
priv->checkpoint_mgr
? nm_utils_strv_make_deep_copied (nm_checkpoint_manager_get_checkpoint_paths (priv->checkpoint_mgr,
NULL))
: NULL);
core: export checkpoint list over D-Bus
2017-10-21 16:05:14 +02:00
break;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
dbus: reinstall property filter on dbus connection changes (rh #918273) 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.
2013-03-20 08:51:08 -05:00
static void
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
set_property (GObject *object, guint prop_id,
manager: refactor construction of manager singleton instance nm_manager_setup() should only call g_object_new() and leave most of the initialization to the GObject constructor.
2016-01-18 14:18:50 +01:00
const GValue *value, GParamSpec *pspec)
dbus: reinstall property filter on dbus connection changes (rh #918273) 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.
2013-03-20 08:51:08 -05:00
{
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
NMManager *self = NM_MANAGER (object);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
NMGlobalDnsConfig *dns_config;
GError *error = NULL;
dbus: reinstall property filter on dbus connection changes (rh #918273) 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.
2013-03-20 08:51:08 -05:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
switch (prop_id) {
case PROP_WIRELESS_ENABLED:
config: let NMConfig handle "NetworkManager.state" file (bgo#764474) Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
2015-11-06 16:45:27 +01:00
manager_radio_user_toggled (NM_MANAGER (object),
&priv->radio_states[RFKILL_TYPE_WLAN],
g_value_get_boolean (value));
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
break;
case PROP_WWAN_ENABLED:
config: let NMConfig handle "NetworkManager.state" file (bgo#764474) Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
2015-11-06 16:45:27 +01:00
manager_radio_user_toggled (NM_MANAGER (object),
&priv->radio_states[RFKILL_TYPE_WWAN],
g_value_get_boolean (value));
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
break;
case PROP_WIMAX_ENABLED:
docs: misc. typos pt2 Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
2018-09-15 07:20:54 -04:00
/* WIMAX is deprecated. This does nothing. */
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
break;
manager: add connectivity-check-{available,enabled} properties. https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:20:04 +08:00
case PROP_CONNECTIVITY_CHECK_ENABLED:
nm_config_set_connectivity_check_enabled (priv->config,
g_value_get_boolean (value));
break;
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
case PROP_GLOBAL_DNS_CONFIGURATION:
dns_config = nm_global_dns_config_from_dbus (value, &error);
if (!error)
nm_config_set_global_dns (priv->config, dns_config, &error);
nm_global_dns_config_free (dns_config);
if (error) {
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGD (LOGD_CORE, "set global DNS failed with error: %s", error->message);
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
g_error_free (error);
}
break;
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
dbus: reinstall property filter on dbus connection changes (rh #918273) 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.
2013-03-20 08:51:08 -05:00
}
}
core: let device plugins advertise supported link and setting types Instead of looping over all plugins and asking each plugin whether it can handle a link or a connection, have them advertise the link and connection types they support, and use that when creating new devices.
2014-09-17 14:17:30 -05:00
static void
_deinit_device_factory (NMDeviceFactory *factory, gpointer user_data)
{
g_signal_handlers_disconnect_matched (factory, G_SIGNAL_MATCH_DATA, 0, 0, NULL, NULL, NM_MANAGER (user_data));
}
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
static void
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
dispose (GObject *object)
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
{
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
NMManager *self = NM_MANAGER (object);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
manager: cleanup freeing CList in NMManager's dispose() To unlink all elements, I find a while() loop easier to read than c_list_for_each_*safe().
2019-05-26 18:58:12 +02:00
CList *iter;
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
manager: track pending authorizations for activating connections We cannot just fire off asynchronous actions without keeping a handle to them. Otherwise, it's impossible for NMManager to know which asynchronous operations are pending, and more importantly: it cannot cancel them. One day, I want that we do a clean shutdown, where NetworkManager stops all pending operations, and cleans up everything. That implies, that every operation is cancellable in a timely manner. Rework pending nm_active_connection_authorize() calls to be tracked in a list, so that they are still reachable to NMManager. Note that currently NMManager does not yet try to cancel these operations ever. However, it would now be possible to do so.
2018-04-18 09:06:54 +02:00
nm_assert (c_list_is_empty (&priv->async_op_lst_head));
manager: disconnect platform_link_cb() from NMManager in dispose()
2017-09-29 15:19:19 +02:00
g_signal_handlers_disconnect_by_func (priv->platform,
G_CALLBACK (platform_link_cb),
self);
manager: cleanup freeing CList in NMManager's dispose() To unlink all elements, I find a while() loop easier to read than c_list_for_each_*safe().
2019-05-26 18:58:12 +02:00
while ((iter = c_list_first (&priv->link_cb_lst))) {
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
PlatformLinkCbData *data = c_list_entry (iter, PlatformLinkCbData, lst);
g_source_remove (data->idle_id);
manager: cleanup freeing CList in NMManager's dispose() To unlink all elements, I find a while() loop easier to read than c_list_for_each_*safe().
2019-05-26 18:58:12 +02:00
c_list_unlink_stale (&data->lst);
manager: refactor lifetime handling for idle callback _platform_link_cb_idle() We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
2017-09-29 15:04:53 +02:00
g_slice_free (PlatformLinkCbData, data);
}
manager: disconnect platform_link_cb() from NMManager in dispose()
2017-09-29 15:19:19 +02:00
auth-chain: track auth-chains in embedded CList NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
2019-05-26 18:49:55 +02:00
while ((iter = c_list_first (&priv->auth_lst_head)))
nm_auth_chain_destroy (nm_auth_chain_parent_lst_entry (iter));
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
manager: delay startup-complete and devices-inited until idle As long as there are events in the mainloop that are ready for dispatch, it's clear that startup-complete is not yet reached. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-14 10:42:36 +01:00
nm_clear_g_source (&priv->devices_inited_id);
checkpoint: don't explicitly track checkpoints in a GHashTable We already have a GHashTable for exported objects. We can use that if we want to look up by path efficiently.
2018-03-27 16:19:20 +02:00
g_clear_pointer (&priv->checkpoint_mgr, nm_checkpoint_manager_free);
checkpoint: add create, rollback and destroy D-Bus API Co-authored-by: Thomas Haller <thaller@redhat.com>
2016-07-01 12:11:01 +02:00
connectivity: schedule connectivity timers per-device and probe for short outages It might happen, that connectivitiy is lost only for a moment and returns soon after. Based on that assumption, when we loose connectivity we want to have a probe interval where we check for returning connectivity more frequently. For that, we handle tracking of the timeouts per-device. The intervall shall start with 1 seconds, and double the interval time until the full interval is reached. Actually, due to the implementation, it's unlikely that we already perform the second check 1 second later. That is because commonly the first check returns before the one second timeout is reached and bumps the interval to 2 seconds right away. Also, we go through extra lengths so that manual connectivity check delay the periodic checks. By being more smart about that, we can reduce the number of connectivity checks, but still keeping the promise to check at least within the requested interval. The complexity of book keeping the timeouts is remarkable. But I think it is worth the effort and we should try hard to - have a connectivity state as accurate as possible. Clearly, connectivity checking means that we probing, so being more intelligent about timeout and backoff timers can result in a better connectivity state. The connectivity state is important because we use it for the default-route penaly and the GUI indicates bad connectivity. - be intelligent about avoiding redundant connectivity checks. While we want to check often to get an accurate connectivity state, we also want to minimize the number of HTTP requests, in case the connectivity is established and suppossedly stable. Also, perform connectivity checks in every state of the device. Even if a device is disconnected, it still might have connectivity, for example if the user externally adds an IP address on an unmanaged device. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-02-20 21:41:14 +01:00
if (priv->concheck_mgr) {
g_signal_handlers_disconnect_by_func (priv->concheck_mgr,
G_CALLBACK (concheck_config_changed_cb),
self);
g_clear_object (&priv->concheck_mgr);
}
manager: keep reference on NMAuthManager singleton A singleton (NMManager) subscribing to another singleton (NMAuthManager) should take a reference on the latter, to ensure its lifetime is longer.
2016-07-01 14:25:34 +02:00
if (priv->auth_mgr) {
g_signal_handlers_disconnect_by_func (priv->auth_mgr,
G_CALLBACK (auth_mgr_changed),
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
self);
manager: keep reference on NMAuthManager singleton A singleton (NMManager) subscribing to another singleton (NMAuthManager) should take a reference on the latter, to ensure its lifetime is longer.
2016-07-01 14:25:34 +02:00
g_clear_object (&priv->auth_mgr);
}
manager: add WWAN enable/disable support
2009-12-23 00:18:18 -08:00
core: track devices in manager via embedded CList Instead of using a GSList for tracking the devices, use a CList. I think a CList is in most cases the more suitable data structure then GSList: - you can find out in O(1) whether the object is linked. That is nice, for example to assert in NMDevice's destructor that the object was unlinked, and we will use that later in nm_manager_get_device_by_path(). - you can unlink the element in O(1) and you can unlink the element without having access to the link's head - Contrary to GSList, this does not require an extra slice allocation for the link node. It quite possibliy consumes slightly less memory because the CList structure is embedded in a struct that we already allocate. Even if slice allocation would be perfect to only consume 2*sizeof(gpointer) for the link note, it would at most be as-good as CList. Quite possibly, there is an overhead though. - CList possibly has better memory locality, because the link structure and the data are close to each other. Something which could be seen as disavantage, is that with CList one device can only be tracked in one NMManager instance at a time. But that is fine. There exists only one NMManager instance for now, and even if we would ever introduce multiple managers, we probably would not associate one NMDevice instance with multiple managers. The advantages are arguably not huge, but CList is IMHO clearly the more suited data structure. No need to stick to a suboptimal data structure for the job. Refactor it.
2018-03-23 21:51:07 +01:00
nm_assert (c_list_is_empty (&priv->devices_lst_head));
wifi: fix disabled wifi devices on resume (rh #578141) RFKILL_TYPE_WLAN is 0, and we while we had allocated the structure for WIMAX rfkill in the manager's priv->radio_states, we hadn't filled it in. That meant that priv->radio_states[RFKILL_TYPE_WIMAX].rtype was 0, and thus various operations thought that wifi devices were wimax devices, and since WiMAX rfkill is never updated because it's not yet used, wifi would never be enabled after resume.
2010-04-08 18:23:43 -07:00
core,libnm: use nm_clear_g_source() where possible Replacement was done with commands: spatch --sp-file nm_clear_g_source.cocci --in-place --smpl-spacing --dir src spatch --sp-file nm_clear_g_source.cocci --in-place --smpl-spacing --dir libnm where nm_clear_g_source.cocci contains: @@ expression e; @@ - if (e) { - g_source_remove (e); - e = 0; - } + nm_clear_g_source (&e);
2016-01-04 09:46:22 +01:00
nm_clear_g_source (&priv->ac_cleanup_id);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
manager: cleanup freeing CList in NMManager's dispose() To unlink all elements, I find a while() loop easier to read than c_list_for_each_*safe().
2019-05-26 18:58:12 +02:00
while ((iter = c_list_first (&priv->active_connections_lst_head)))
active_connection_remove (self, c_list_entry (iter, NMActiveConnection, active_connections_lst));
core: track NMActiveConnection in manager with CList Using CList, we embed the list element in NMActiveConnection struct itself. That means for example, that you couldn't track a NMActiveConnection more then once. But we anyway never want that. The advantage is, that removing an active connection from the list is O(1), and we safe additional GSlice allocations for each node element.
2017-11-23 21:30:09 +01:00
nm_assert (c_list_is_empty (&priv->active_connections_lst_head));
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
g_clear_object (&priv->primary_connection);
g_clear_object (&priv->activating_connection);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
if (priv->config) {
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
g_signal_handlers_disconnect_by_func (priv->config, _config_changed_cb, self);
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
g_clear_object (&priv->config);
}
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
if (priv->policy) {
policy: track best active connections rather than best devices If a VPN with default route is activated, the Manager's PrimaryConnection property is not updated to indicate the VPN as primary connection. This happens because the PrimaryConnection property gets updated when the default_ipX_device property of NMPolicy changes, and the primary connection is set to the activation request currently pending on the default device. We select the base (for example, ethernet) device as best device and therefore the NMActRequest active on it is selected as primary connection. This patch fixes the problem by properly selecting the VPN as primary. It seems a better choice to track best active connections directly from NMPolicy instead of going through two steps.
2018-06-28 18:05:05 +02:00
g_signal_handlers_disconnect_by_func (priv->policy, policy_default_ac_changed, self);
g_signal_handlers_disconnect_by_func (priv->policy, policy_activating_ac_changed, self);
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
g_clear_object (&priv->policy);
}
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
core: create virtual device on settings changes in idle handler The callback from NMSettings about adding/updating a settings comes from a deep call-stack already. We don't know the context of it, and we shouldn't just right away create the profile. Instead, schedule an action to create it in an idle handler.
2019-06-30 10:33:28 +02:00
nm_clear_g_source (&priv->connection_changed_on_idle_id);
nm_c_list_elem_free_all (&priv->connection_changed_on_idle_lst, g_object_unref);
manager: disconnect signal handlers on 'settings' in dispose() (rh #1264676) Otherwise a crash can occur when shutting down. https://bugzilla.redhat.com/show_bug.cgi?id=1264676
2015-09-21 14:30:02 +02:00
if (priv->settings) {
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
g_signal_handlers_disconnect_by_func (priv->settings, settings_startup_complete_changed, self);
g_signal_handlers_disconnect_by_func (priv->settings, system_unmanaged_devices_changed_cb, self);
g_signal_handlers_disconnect_by_func (priv->settings, connection_added_cb, self);
g_signal_handlers_disconnect_by_func (priv->settings, connection_updated_cb, self);
settings: delete volatile connection and support setting the volatile flag Previously, we would only set a connection as volatile before adding it to manager. As we never would set it volatile last on, there was no need to handle deletion. Now support that. Watch the volatile flag, and if the connection has currently not active connection that keeps it alive, delete it in an idle handler.
2017-12-05 13:55:25 +01:00
g_signal_handlers_disconnect_by_func (priv->settings, connection_flags_changed, self);
manager: disconnect signal handlers on 'settings' in dispose() (rh #1264676) Otherwise a crash can occur when shutting down. https://bugzilla.redhat.com/show_bug.cgi?id=1264676
2015-09-21 14:30:02 +02:00
g_clear_object (&priv->settings);
}
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
if (priv->hostname_manager) {
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
g_signal_handlers_disconnect_by_func (priv->hostname_manager, hostname_changed_cb, self);
hostname: cache hostname-manager's hostname property A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
2017-04-23 14:20:37 +02:00
g_clear_object (&priv->hostname_manager);
}
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
g_clear_object (&priv->vpn_manager);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
sleep_devices_clear (self);
manager: disconnect devices before unmanaging them on suspend/sleep So that dispatcher scripts are run and other applications notified of the change in connectivity. https://bugzilla.redhat.com/show_bug.cgi?id=1330694 https://bugzilla.gnome.org/show_bug.cgi?id=748531
2016-05-05 14:14:40 +02:00
g_clear_pointer (&priv->sleep_devices, g_hash_table_unref);
core: declare nm_sleep_monitor_get() using NM_DEFINE_SINGLETON_GETTER() Also no longer increment the reference count in the getter and properly disconnect the signals in NMManager:dispose(). Also use the defines for the signal names instead of plain strings.
2015-01-05 16:37:45 +01:00
if (priv->sleep_monitor) {
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
g_signal_handlers_disconnect_by_func (priv->sleep_monitor, sleeping_cb, self);
core: declare nm_sleep_monitor_get() using NM_DEFINE_SINGLETON_GETTER() Also no longer increment the reference count in the getter and properly disconnect the signals in NMManager:dispose(). Also use the defines for the signal names instead of plain strings.
2015-01-05 16:37:45 +01:00
g_clear_object (&priv->sleep_monitor);
}
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
if (priv->fw_monitor) {
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
g_signal_handlers_disconnect_by_func (priv->fw_monitor, firmware_dir_changed, self);
core: listen to UPower for suspend/resume signals This means you don't need pm-utils anymore, and that gnome-power-manager doesn't need to poke NM explicitly for suspend/resume operations. The old explicit sleep/wake request is still around for pm-utils or gpm to use, but NM will listen for UPower events and act on them regardless of what pm-utils or gpm do.
2010-08-31 15:45:55 -05:00
core,libnm: use nm_clear_g_source() where possible Replacement was done with commands: spatch --sp-file nm_clear_g_source.cocci --in-place --smpl-spacing --dir src spatch --sp-file nm_clear_g_source.cocci --in-place --smpl-spacing --dir libnm where nm_clear_g_source.cocci contains: @@ expression e; @@ - if (e) { - g_source_remove (e); - e = 0; - } + nm_clear_g_source (&e);
2016-01-04 09:46:22 +01:00
nm_clear_g_source (&priv->fw_changed_id);
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
trivial: reorgranize some NMManager functions No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
2014-01-24 13:24:01 -06:00
g_file_monitor_cancel (priv->fw_monitor);
g_clear_object (&priv->fw_monitor);
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
}
manager: cleanup NMRfkillManager in dispose() Fixes: b15fb8641e26eb63c2d83d9dcc9510705086e2f2
2015-09-21 14:38:25 +02:00
if (priv->rfkill_mgr) {
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
g_signal_handlers_disconnect_by_func (priv->rfkill_mgr, rfkill_manager_rfkill_changed_cb, self);
manager: cleanup NMRfkillManager in dispose() Fixes: b15fb8641e26eb63c2d83d9dcc9510705086e2f2
2015-09-21 14:38:25 +02:00
g_clear_object (&priv->rfkill_mgr);
}
manager: fix leaking volatile-connection-list on exit On exit during NMManager's dispose(), we must fist remove active connections via active_connection_remove(), before clearing the volatile-connection-list. Otheriwise, while deleting the active connection, we schedule a idle action to delete the volatile connection on idle, but at that point the dispose() already cleaned up the idle list. ==3150== 72 (24 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 3,411 of 6,079 ==3150== at 0x4C2FB6B: malloc (vg_replace_malloc.c:299) ==3150== by 0x6AB7358: g_malloc (gmem.c:94) ==3150== by 0x6ACEF35: g_slice_alloc (gslice.c:1025) ==3150== by 0x1686B1: connection_flags_changed (nm-manager.c:1823) ==3150== by 0x661F73C: g_closure_invoke (gclosure.c:804) ==3150== by 0x66324DD: signal_emit_unlocked_R (gsignal.c:3635) ==3150== by 0x663AD04: g_signal_emit_valist (gsignal.c:3391) ==3150== by 0x663B66E: g_signal_emit (gsignal.c:3447) ==3150== by 0x2EC753: connection_flags_changed (nm-settings.c:824) ==3150== by 0x661F73C: g_closure_invoke (gclosure.c:804) ==3150== by 0x66324DD: signal_emit_unlocked_R (gsignal.c:3635) ==3150== by 0x663AD04: g_signal_emit_valist (gsignal.c:3391) ==3150== by 0x663B66E: g_signal_emit (gsignal.c:3447) ==3150== by 0x6623C03: g_object_dispatch_properties_changed (gobject.c:1080) ==3150== by 0x1DFD47: dispatch_properties_changed (nm-dbus-object.c:237) ==3150== by 0x6626178: g_object_notify_by_spec_internal (gobject.c:1173) ==3150== by 0x6626178: g_object_notify_by_pspec (gobject.c:1283) ==3150== by 0x2E7377: _notify (nm-settings-connection.c:53) ==3150== by 0x2E7377: nm_settings_connection_set_flags_full (nm-settings-connection.c:2346) ==3150== by 0x2E744D: nm_settings_connection_set_flags (nm-settings-connection.c:2316) ==3150== by 0x2E7466: set_visible (nm-settings-connection.c:316) ==3150== by 0x2E7774: nm_settings_connection_delete (nm-settings-connection.c:795) ==3150== by 0x1665A8: _delete_volatile_connection_do (nm-manager.c:598) ==3150== by 0x1668F4: active_connection_remove (nm-manager.c:625) ==3150== by 0x16ABA7: dispose (nm-manager.c:6726) ==3150== by 0x6624607: g_object_unref (gobject.c:3293) ==3150== by 0x1D779B: _nm_singleton_instance_destroy (nm-core-utils.c:138) ==3150== by 0x4011332: _dl_fini (in /usr/lib64/ld-2.26.so) ==3150== by 0x815FB57: __run_exit_handlers (in /usr/lib64/libc-2.26.so) ==3150== by 0x815FBA9: exit (in /usr/lib64/libc-2.26.so) ==3150== by 0x1383C7: main (main.c:467)
2018-03-10 16:18:16 +01:00
nm_clear_g_source (&priv->delete_volatile_connection_idle_id);
_delete_volatile_connection_all (self, FALSE);
nm_assert (!priv->delete_volatile_connection_idle_id);
nm_assert (c_list_is_empty (&priv->delete_volatile_connection_lst_head));
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
nm_device_factory_manager_for_each_factory (_deinit_device_factory, self);
manager: refactor construction of manager singleton instance nm_manager_setup() should only call g_object_new() and leave most of the initialization to the GObject constructor.
2016-01-18 14:18:50 +01:00
core,libnm: use nm_clear_g_source() where possible Replacement was done with commands: spatch --sp-file nm_clear_g_source.cocci --in-place --smpl-spacing --dir src spatch --sp-file nm_clear_g_source.cocci --in-place --smpl-spacing --dir libnm where nm_clear_g_source.cocci contains: @@ expression e; @@ - if (e) { - g_source_remove (e); - e = 0; - } + nm_clear_g_source (&e);
2016-01-04 09:46:22 +01:00
nm_clear_g_source (&priv->timestamp_update_id);
core: move device creation into the manager Consolidate device creation in the manager object; bluetooth and modem devices were already handled by it, so it makes sense to do it all from one place. Furthermore we'll be creating virtual devices in the manager too. It also reduces indirection (no need to send device_creator() in the DEVICE_ADDED signal) and makes the code flow clearer.
2012-02-05 23:18:32 -06:00
device: generate unique default route-metrics per interface In the past we had NMDefaultRouteManager which would coordinate adding the default-route with identical metrics. That especially happened, when activating two devices of the same type, without explicitly specifying ipv4.route-metric. For example, with ethernet devices, the routes on both interfaces would get a metric of 100. Coordinating routes was especially necessary, because we added routes with NLM_F_EXCL flag, akin to `ip route replace`. We not only had to avoid that activating two devices in NetworkManager would result in a fight over the default-route, but more importently to preserve externally added default-routes on unmanaged interfaces. NMDefaultRouteManager would ensure that in case of duplicate metrics, that the device that activated first would keep the best default-route. It would do so by bumping the metric of the second device to find a unused metric. The bumping itself was not very important -- MDefaultRouteManager could also just not configure any default-routes that show up as second, the result would be quite similar. More important was to keep the best default-route on the first activating device until the device deactivates or a device activates that really has a better default-route.. Likewise, NMRouteManager would globally manage non-default-routes. It would not do any bumping of metrics, but it would also ensure that the routes of the device that activates first are not overwritten by a device activating later. However, the `ip route replace` approach has downsides, especially that it messes with routes on other interfaces, interfaces that are possibly not managed by NetworkManager. Another downside is, that binding a socket to an interface might not result in correct routes, because the route might just not be there (in case of NMRouteManager, which wouldn't configure duplicate routes by bumping their metric). Since commit 77ec302714795f905301d500b9aab6c88001f32e we would no longer use NLM_F_EXCL, but add routes akin to `ip route append`. When activating for example two ethernet devices with no explict route metric configuration, there are two routes like default via 10.16.122.254 dev eth0 proto dhcp metric 100 default via 192.168.100.1 dev eth1 proto dhcp metric 100 This does not only affect default routes. In case of a multi-homing setup you'd get 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100 but it's visible the most for default-routes. Note that we would append the routes that are activated later, as the order of `ip route show` confirms. One might hence expect, that kernel selects a route based on the order in the routing tables. However, that isn't the case, and activating the second interface will non-deterministically re-route traffic via the new interface. That will interfere badly with with NAT, stateful firewalls, and existing connections (like TCP). The solution is to have NMManager keep a global index of the default route-metrics currently in use. So, instead of determining the default-route metric based solely on the device-type, we now in addition generate default metrics that do not overlap. For example, if you activate eth0 first, it gets route-metric 100, and if you then activate eth1, it gets 101. Note that if you deactivate and re-activate eth0, then it will get route-metric 102, because the best route should stick on eth1 (which reserves the range 100 to 101). Note that when a connection explititly selects a particular metric, then that choice is honored (contrary to NMDefaultRouteManager which was more concerned with avoiding conflicts, then keeping the exact metric). https://bugzilla.redhat.com/show_bug.cgi?id=1505893
2017-12-05 16:32:04 +01:00
g_clear_pointer (&priv->device_route_metrics, g_hash_table_destroy);
capabilities: fix destroying capabilities in dispose() dispose() must be re-entrant. Thus, at the very least it must clear the priv->capabilities after freeing the array. While at it, move it to finalize (which is only called once) and move initialization of the array from "constructed" to nm_manager_init() which is called first.
2016-09-23 13:24:10 +02:00
G_OBJECT_CLASS (nm_manager_parent_class)->dispose (object);
}
static void
finalize (GObject *object)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE ((NMManager *) object);
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
g_array_free (priv->capabilities, TRUE);
capabilities: fix destroying capabilities in dispose() dispose() must be re-entrant. Thus, at the very least it must clear the priv->capabilities after freeing the array. While at it, move it to finalize (which is only called once) and move initialization of the array from "constructed" to nm_manager_init() which is called first.
2016-09-23 13:24:10 +02:00
G_OBJECT_CLASS (nm_manager_parent_class)->finalize (object);
manager: don't use platform singleton but keep a private pointer We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
2017-09-29 15:11:33 +02:00
g_object_unref (priv->platform);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
static const GDBusSignalInfo signal_info_check_permissions = NM_DEFINE_GDBUS_SIGNAL_INFO_INIT (
"CheckPermissions",
);
static const GDBusSignalInfo signal_info_state_changed = NM_DEFINE_GDBUS_SIGNAL_INFO_INIT (
"StateChanged",
.args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("state", "u"),
),
);
static const GDBusSignalInfo signal_info_device_added = NM_DEFINE_GDBUS_SIGNAL_INFO_INIT (
"DeviceAdded",
.args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("device_path", "o"),
),
);
static const GDBusSignalInfo signal_info_device_removed = NM_DEFINE_GDBUS_SIGNAL_INFO_INIT (
"DeviceRemoved",
.args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("device_path", "o"),
),
);
static const NMDBusInterfaceInfoExtended interface_info_manager = {
.parent = NM_DEFINE_GDBUS_INTERFACE_INFO_INIT (
NM_DBUS_INTERFACE,
.methods = NM_DEFINE_GDBUS_METHOD_INFOS (
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"Reload",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("flags", "u"),
),
),
.handle = impl_manager_reload,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"GetDevices",
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("devices", "ao"),
),
),
.handle = impl_manager_get_devices,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"GetAllDevices",
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("devices", "ao"),
),
),
.handle = impl_manager_get_all_devices,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"GetDeviceByIpIface",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("iface", "s"),
),
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("device", "o"),
),
),
.handle = impl_manager_get_device_by_ip_iface,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"ActivateConnection",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("connection", "o"),
NM_DEFINE_GDBUS_ARG_INFO ("device", "o"),
NM_DEFINE_GDBUS_ARG_INFO ("specific_object", "o"),
),
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("active_connection", "o"),
),
),
.handle = impl_manager_activate_connection,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"AddAndActivateConnection",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("connection", "a{sa{sv}}"),
NM_DEFINE_GDBUS_ARG_INFO ("device", "o"),
NM_DEFINE_GDBUS_ARG_INFO ("specific_object", "o"),
),
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("path", "o"),
NM_DEFINE_GDBUS_ARG_INFO ("active_connection", "o"),
),
),
.handle = impl_manager_add_and_activate_connection,
core: Add an AddAndActivateConnection2 routine with options parameter This adds a new routine to be able to handle an arbitrary set of further options for AddAndActivateConnection. Note that no options are accepted for now.
2018-10-30 16:40:40 +01:00
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"AddAndActivateConnection2",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("connection", "a{sa{sv}}"),
NM_DEFINE_GDBUS_ARG_INFO ("device", "o"),
NM_DEFINE_GDBUS_ARG_INFO ("specific_object", "o"),
NM_DEFINE_GDBUS_ARG_INFO ("options", "a{sv}"),
),
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("path", "o"),
NM_DEFINE_GDBUS_ARG_INFO ("active_connection", "o"),
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
NM_DEFINE_GDBUS_ARG_INFO ("result", "a{sv}"),
core: Add an AddAndActivateConnection2 routine with options parameter This adds a new routine to be able to handle an arbitrary set of further options for AddAndActivateConnection. Note that no options are accepted for now.
2018-10-30 16:40:40 +01:00
),
),
.handle = impl_manager_add_and_activate_connection,
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"DeactivateConnection",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("active_connection", "o"),
),
),
.handle = impl_manager_deactivate_connection,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"Sleep",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("sleep", "b"),
),
),
.handle = impl_manager_sleep,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"Enable",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("enable", "b"),
),
),
.handle = impl_manager_enable,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"GetPermissions",
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("permissions", "a{ss}"),
),
),
.handle = impl_manager_get_permissions,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"SetLogging",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("level", "s"),
NM_DEFINE_GDBUS_ARG_INFO ("domains", "s"),
),
),
.handle = impl_manager_set_logging,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"GetLogging",
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("level", "s"),
NM_DEFINE_GDBUS_ARG_INFO ("domains", "s"),
),
),
.handle = impl_manager_get_logging,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"CheckConnectivity",
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("connectivity", "u"),
),
),
.handle = impl_manager_check_connectivity,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"state",
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("state", "u"),
),
),
.handle = impl_manager_state,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"CheckpointCreate",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("devices", "ao"),
NM_DEFINE_GDBUS_ARG_INFO ("rollback_timeout", "u"),
NM_DEFINE_GDBUS_ARG_INFO ("flags", "u"),
),
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("checkpoint", "o"),
),
),
.handle = impl_manager_checkpoint_create,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"CheckpointDestroy",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("checkpoint", "o"),
),
),
.handle = impl_manager_checkpoint_destroy,
),
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"CheckpointRollback",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("checkpoint", "o"),
),
.out_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("result", "a{su}"),
),
),
.handle = impl_manager_checkpoint_rollback,
),
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
NM_DEFINE_DBUS_METHOD_INFO_EXTENDED (
NM_DEFINE_GDBUS_METHOD_INFO_INIT (
"CheckpointAdjustRollbackTimeout",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS (
NM_DEFINE_GDBUS_ARG_INFO ("checkpoint", "o"),
NM_DEFINE_GDBUS_ARG_INFO ("add_timeout", "u"),
),
),
.handle = impl_manager_checkpoint_adjust_rollback_timeout,
),
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
),
.signals = NM_DEFINE_GDBUS_SIGNAL_INFOS (
&nm_signal_info_property_changed_legacy,
&signal_info_check_permissions,
&signal_info_state_changed,
&signal_info_device_added,
&signal_info_device_removed,
),
.properties = NM_DEFINE_GDBUS_PROPERTY_INFOS (
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("Devices", "ao", NM_MANAGER_DEVICES),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("AllDevices", "ao", NM_MANAGER_ALL_DEVICES),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("Checkpoints", "ao", NM_MANAGER_CHECKPOINTS),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("NetworkingEnabled", "b", NM_MANAGER_NETWORKING_ENABLED),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READWRITABLE_L ("WirelessEnabled", "b", NM_MANAGER_WIRELESS_ENABLED, NM_AUTH_PERMISSION_ENABLE_DISABLE_WIFI, NM_AUDIT_OP_RADIO_CONTROL),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("WirelessHardwareEnabled", "b", NM_MANAGER_WIRELESS_HARDWARE_ENABLED),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READWRITABLE_L ("WwanEnabled", "b", NM_MANAGER_WWAN_ENABLED, NM_AUTH_PERMISSION_ENABLE_DISABLE_WWAN, NM_AUDIT_OP_RADIO_CONTROL),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("WwanHardwareEnabled", "b", NM_MANAGER_WWAN_HARDWARE_ENABLED),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READWRITABLE_L ("WimaxEnabled", "b", NM_MANAGER_WIMAX_ENABLED, NM_AUTH_PERMISSION_ENABLE_DISABLE_WIMAX, NM_AUDIT_OP_RADIO_CONTROL),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("WimaxHardwareEnabled", "b", NM_MANAGER_WIMAX_HARDWARE_ENABLED),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("ActiveConnections", "ao", NM_MANAGER_ACTIVE_CONNECTIONS),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("PrimaryConnection", "o", NM_MANAGER_PRIMARY_CONNECTION),
manager: fix typo in 'PrimaryConnectionType' D-Bus property name Fixes: 297d4985abcc7b571b8c090ee90622357fc60e16
2018-06-22 15:53:46 +02:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("PrimaryConnectionType", "s", NM_MANAGER_PRIMARY_CONNECTION_TYPE),
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("Metered", "u", NM_MANAGER_METERED),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("ActivatingConnection", "o", NM_MANAGER_ACTIVATING_CONNECTION),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("Startup", "b", NM_MANAGER_STARTUP),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("Version", "s", NM_MANAGER_VERSION),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("Capabilities", "u", NM_MANAGER_CAPABILITIES),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("State", "u", NM_MANAGER_STATE),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("Connectivity", "u", NM_MANAGER_CONNECTIVITY),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("ConnectivityCheckAvailable", "b", NM_MANAGER_CONNECTIVITY_CHECK_AVAILABLE),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READWRITABLE_L ("ConnectivityCheckEnabled", "b", NM_MANAGER_CONNECTIVITY_CHECK_ENABLED, NM_AUTH_PERMISSION_ENABLE_DISABLE_CONNECTIVITY_CHECK, NM_AUDIT_OP_NET_CONTROL),
libnm,core: Add ConnectivityCheckUri property and accessors So that applications like GNOME Shell can hit the same URI to show the captive portal login page. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/209
2019-07-22 15:55:15 +01:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE ("ConnectivityCheckUri", "s", NM_MANAGER_CONNECTIVITY_CHECK_URI),
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READWRITABLE_L ("GlobalDnsConfiguration", "a{sv}", NM_MANAGER_GLOBAL_DNS_CONFIGURATION, NM_AUTH_PERMISSION_SETTINGS_MODIFY_GLOBAL_DNS, NM_AUDIT_OP_NET_CONTROL),
),
),
.legacy_property_changed = TRUE,
};
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
static void
nm_manager_class_init (NMManagerClass *manager_class)
{
GObjectClass *object_class = G_OBJECT_CLASS (manager_class);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMDBusObjectClass *dbus_object_class = NM_DBUS_OBJECT_CLASS (manager_class);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
core/dbus: rework creating numbered D-Bus export path by putting counter into class I dislike the static hash table to cache the integer counter for numbered paths. Let's instead cache the counter at the class instance itself -- since the class contains the information how the export path should be exported. However, we cannot use a plain integer field inside the class structure, because the class is copied between derived classes. For example, NMDeviceEthernet and NMDeviceBridge both get a copy of the NMDeviceClass instance. Hence, the class doesn't contain the counter directly, but a pointer to one counter that can be shared between sibling classes.
2018-03-13 10:14:06 +01:00
dbus_object_class->export_path = NM_DBUS_EXPORT_PATH_STATIC (NM_DBUS_PATH);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
dbus_object_class->interface_infos = NM_DBUS_INTERFACE_INFOS (&interface_info_manager);
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
manager: refactor construction of manager singleton instance nm_manager_setup() should only call g_object_new() and leave most of the initialization to the GObject constructor.
2016-01-18 14:18:50 +01:00
object_class->constructed = constructed;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
object_class->set_property = set_property;
object_class->get_property = get_property;
object_class->dispose = dispose;
capabilities: fix destroying capabilities in dispose() dispose() must be re-entrant. Thus, at the very least it must clear the priv->capabilities after freeing the array. While at it, move it to finalize (which is only called once) and move initialization of the array from "constructed" to nm_manager_init() which is called first.
2016-09-23 13:24:10 +02:00
object_class->finalize = finalize;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
obj_properties[PROP_VERSION] =
g_param_spec_string (NM_MANAGER_VERSION, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
obj_properties[PROP_CAPABILITIES] =
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
g_param_spec_variant (NM_MANAGER_CAPABILITIES, "", "",
G_VARIANT_TYPE ("au"),
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
obj_properties[PROP_STATE] =
g_param_spec_uint (NM_MANAGER_STATE, "", "",
0, NM_STATE_DISCONNECTED, 0,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_STARTUP] =
g_param_spec_boolean (NM_MANAGER_STARTUP, "", "",
TRUE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_NETWORKING_ENABLED] =
g_param_spec_boolean (NM_MANAGER_NETWORKING_ENABLED, "", "",
TRUE,
config: let NMConfig handle "NetworkManager.state" file (bgo#764474) Move reading and writing of the state file to NMConfig ("/var/lib/NetworkManager/NetworkManager.state" file). Originally, I intended to persist more state, thus it made sense to cleanup handling of the state file and move it all at one place. Now, it's not clear that will happen anytime soon. Still, the change is a worthy cleanup, so do it anyway. https://bugzilla.gnome.org/show_bug.cgi?id=764474
2015-11-06 16:45:27 +01:00
G_PARAM_READABLE |
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_WIRELESS_ENABLED] =
g_param_spec_boolean (NM_MANAGER_WIRELESS_ENABLED, "", "",
TRUE,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_WIRELESS_HARDWARE_ENABLED] =
g_param_spec_boolean (NM_MANAGER_WIRELESS_HARDWARE_ENABLED, "", "",
TRUE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_WWAN_ENABLED] =
g_param_spec_boolean (NM_MANAGER_WWAN_ENABLED, "", "",
TRUE,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_WWAN_HARDWARE_ENABLED] =
g_param_spec_boolean (NM_MANAGER_WWAN_HARDWARE_ENABLED, "", "",
TRUE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_WIMAX_ENABLED] =
g_param_spec_boolean (NM_MANAGER_WIMAX_ENABLED, "", "",
TRUE,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_WIMAX_HARDWARE_ENABLED] =
g_param_spec_boolean (NM_MANAGER_WIMAX_HARDWARE_ENABLED, "", "",
TRUE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_ACTIVE_CONNECTIONS] =
g_param_spec_boxed (NM_MANAGER_ACTIVE_CONNECTIONS, "", "",
G_TYPE_STRV,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_CONNECTIVITY] =
g_param_spec_uint (NM_MANAGER_CONNECTIVITY, "", "",
NM_CONNECTIVITY_UNKNOWN, NM_CONNECTIVITY_FULL, NM_CONNECTIVITY_UNKNOWN,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
manager: add connectivity-check-{available,enabled} properties. https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:20:04 +08:00
obj_properties[PROP_CONNECTIVITY_CHECK_AVAILABLE] =
g_param_spec_boolean (NM_MANAGER_CONNECTIVITY_CHECK_AVAILABLE, "", "",
TRUE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_CONNECTIVITY_CHECK_ENABLED] =
g_param_spec_boolean (NM_MANAGER_CONNECTIVITY_CHECK_ENABLED, "", "",
TRUE,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
libnm,core: Add ConnectivityCheckUri property and accessors So that applications like GNOME Shell can hit the same URI to show the captive portal login page. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/209
2019-07-22 15:55:15 +01:00
obj_properties[PROP_CONNECTIVITY_CHECK_URI] =
g_param_spec_string (NM_MANAGER_CONNECTIVITY_CHECK_URI, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
obj_properties[PROP_PRIMARY_CONNECTION] =
g_param_spec_string (NM_MANAGER_PRIMARY_CONNECTION, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_PRIMARY_CONNECTION_TYPE] =
g_param_spec_string (NM_MANAGER_PRIMARY_CONNECTION_TYPE, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_ACTIVATING_CONNECTION] =
g_param_spec_string (NM_MANAGER_ACTIVATING_CONNECTION, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
core: add networking enable/disable knob distinct from sleep/wake (rh #589108) (bgo #346615) Since forever we've used sleep/wake as the way to implement Networking Enabled. When the state file was introduced to make the networking and wifi states persistent, we ran into a bug where a failed suspend (like if the machine ran out of power while suspended) would result in networking being disabled on reboot since suspend/resume used the same knob as enable/disable. This patch adds a distinct call for enable/disable networking which changes the state file, while sleep/wake no longer change the state file.
2010-05-22 08:55:30 -07:00
/* Sleeping is not exported over D-Bus */
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
obj_properties[PROP_SLEEPING] =
g_param_spec_boolean (NM_MANAGER_SLEEPING, "", "",
FALSE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_DEVICES] =
g_param_spec_boxed (NM_MANAGER_DEVICES, "", "",
G_TYPE_STRV,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
api/core: add Devices property to the Manager
2014-01-08 12:18:33 -06:00
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
/**
* NMManager:metered:
*
* Whether the connectivity is metered.
*
* Since: 1.2
**/
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
obj_properties[PROP_METERED] =
g_param_spec_uint (NM_MANAGER_METERED, "", "",
0, G_MAXUINT32, NM_METERED_UNKNOWN,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
/**
* NMManager:global-dns-configuration:
*
* The global DNS configuration.
*
* Since: 1.2
**/
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
obj_properties[PROP_GLOBAL_DNS_CONFIGURATION] =
g_param_spec_variant (NM_MANAGER_GLOBAL_DNS_CONFIGURATION, "", "",
G_VARIANT_TYPE ("a{sv}"),
NULL,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
/**
* NMManager:all-devices:
*
* All devices, including those that are not realized.
*
* Since: 1.2
**/
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
obj_properties[PROP_ALL_DEVICES] =
g_param_spec_boxed (NM_MANAGER_ALL_DEVICES, "", "",
G_TYPE_STRV,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
core: export checkpoint list over D-Bus
2017-10-21 16:05:14 +02:00
obj_properties[PROP_CHECKPOINTS] =
g_param_spec_boxed (NM_MANAGER_CHECKPOINTS, "", "",
G_TYPE_STRV,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
g_object_class_install_properties (object_class, _PROPERTY_ENUMS_LAST, obj_properties);
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
/* signals */
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
/* emitted only for realized devices */
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
signals[DEVICE_ADDED] =
manager: use defines for signal names
2016-04-04 14:17:09 +02:00
g_signal_new (NM_MANAGER_DEVICE_ADDED,
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
manager: remove unused signal slots from NMManagerClass
2016-04-28 14:05:11 +02:00
0, NULL, NULL, NULL,
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
G_TYPE_NONE, 1, NM_TYPE_DEVICE);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
/* Emitted for both realized devices and placeholder devices */
signals[INTERNAL_DEVICE_ADDED] =
manager: use defines for signal names
2016-04-04 14:17:09 +02:00
g_signal_new (NM_MANAGER_INTERNAL_DEVICE_ADDED,
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
G_OBJECT_CLASS_TYPE (object_class),
trivial: fix grouping of empty GClosure arg in g_signal_new()
2019-03-06 10:57:21 +01:00
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
G_TYPE_NONE, 1, G_TYPE_OBJECT);
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
/* emitted only for realized devices when a device
manager: emit device-removed signal when a device unrealizes The 'device-added' and 'device-removed' signals indicate when the value of the 'Devices' property changes. The property only returns realized devices and so if a device unrealizes we should emit the removed signal for it. Fixes: 5da37a129c25350e6f5041726a23d4d9f8318762 https://bugzilla.gnome.org/show_bug.cgi?id=771324
2016-09-14 14:15:24 +02:00
* becomes unrealized or removed */
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
signals[DEVICE_REMOVED] =
manager: use defines for signal names
2016-04-04 14:17:09 +02:00
g_signal_new (NM_MANAGER_DEVICE_REMOVED,
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
manager: remove unused signal slots from NMManagerClass
2016-04-28 14:05:11 +02:00
0, NULL, NULL, NULL,
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
G_TYPE_NONE, 1, NM_TYPE_DEVICE);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
/* Emitted for both realized devices and placeholder devices */
signals[INTERNAL_DEVICE_REMOVED] =
manager: use defines for signal names
2016-04-04 14:17:09 +02:00
g_signal_new (NM_MANAGER_INTERNAL_DEVICE_REMOVED,
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
G_OBJECT_CLASS_TYPE (object_class),
trivial: fix grouping of empty GClosure arg in g_signal_new()
2019-03-06 10:57:21 +01:00
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
G_TYPE_NONE, 1, G_TYPE_OBJECT);
api/manager: add GetAllDevices() method and AllDevices property Returns both realized and un-realized devices.
2014-10-06 11:21:54 -05:00
core: add manager active connection added/removed signals 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.
2012-08-22 18:33:17 -05:00
signals[ACTIVE_CONNECTION_ADDED] =
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
g_signal_new (NM_MANAGER_ACTIVE_CONNECTION_ADDED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 1, NM_TYPE_ACTIVE_CONNECTION);
core: add manager active connection added/removed signals 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.
2012-08-22 18:33:17 -05:00
signals[ACTIVE_CONNECTION_REMOVED] =
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
g_signal_new (NM_MANAGER_ACTIVE_CONNECTION_REMOVED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 1, NM_TYPE_ACTIVE_CONNECTION);
core: add manager active connection added/removed signals 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.
2012-08-22 18:33:17 -05:00
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
signals[CONFIGURE_QUIT] =
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
g_signal_new (NM_MANAGER_CONFIGURE_QUIT,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 0);
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
}
Reference in a new issue Copy permalink