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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

9001 lines
361 KiB
C
Raw Normal View History

all: update deprecated SPDX license identifiers These SPDX license identifiers are deprecated ([1]). Update them. [1] https://spdx.org/licenses/ sed \ -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \ -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \ -i \ $(git grep -l SPDX-License-Identifier -- \ ':(exclude)shared/c-*/' \ ':(exclude)shared/n-*/' \ ':(exclude)shared/systemd/src' \ ':(exclude)src/systemd/src')
2020-12-23 22:21:36 +01:00
/* SPDX-License-Identifier: GPL-2.0-or-later */
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: add "src/core/nm-default-daemon.h" as replacement for "nm-default.h"
2021-02-04 18:04:13 +01:00
#include "src/core/nm-default-daemon.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"
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>
nm-manager: fix selinux label for dhclient lease file from initramfs When moving a lease file from initramfs directory to NetworkManager run directory, SELinux label for that file retains tmpfs_t type. Fix it by using sendfile() instead of rename(). That way, the lease file will have the default type: NetworkManager_var_run_t. Since we take ownership of the lease file, also drop it from the old location. * Before the patch: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease * After: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
2019-12-03 19:00:42 +03:00
#include <limits.h>
core: sort includes in "src/core/nm-manager.c" This will be linked by CONTRIBUTING.md file as an example how to do it. Sorting includes by name is a sensible default-choice, so do it.
2021-08-26 14:43:26 +02:00
#include <stdlib.h>
#include <sys/sendfile.h>
#include <sys/stat.h>
#include <sys/types.h>
#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
core: sort includes in "src/core/nm-manager.c" This will be linked by CONTRIBUTING.md file as an example how to do it. Sorting includes by name is a sensible default-choice, so do it.
2021-08-26 14:43:26 +02:00
#include "NetworkManagerUtils.h"
#include "devices/nm-device-factory.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-generic.h"
core: sort includes in "src/core/nm-manager.c" This will be linked by CONTRIBUTING.md file as an example how to do it. Sorting includes by name is a sensible default-choice, so do it.
2021-08-26 14:43:26 +02:00
#include "devices/nm-device.h"
core: add nm_manager_get_dns_manager() getter nm_dns_manager_get() is already a singleton. So users usually can just get it whenever they need -- except during shutdown after the singleton was destroyed. This is usually fine, because users really should not try to get it late during shutdown. However, if you subscribe a signal handler on the singleton, then you will also eventually want to unsubscribe it. While the moment when you subscribe it is clearly not during late-shutdown, it's not clear how to ensure that the signal listener gets destroyed before the DNS manager singleton. So usually, whenever you are going to subscribe a signal, you need to make sure that the target object stays alive long enough. Which may mean to keep a reference to it. Next, we will have NMDevice subscribe to the singleton. With above said, that would mean that potentially every NMDevice needs to keep a reference to the NMDnsManager. That is not best. Also, later NMManager will face the same problem, because it will also subscribe to NMDnsManager. So, instead let NMManager own a reference to the NMDnsManager. This ensures the lifetimes are properly guarded (NMDevice also references NMManager already). Also, access nm_dns_manager_get() lazy on first use, to only initialize it when needed the first time (which might be quite late).
2022-04-08 11:40:42 +02:00
#include "dns/nm-dns-manager.h"
core: sort includes in "src/core/nm-manager.c" This will be linked by CONTRIBUTING.md file as an example how to do it. Sorting includes by name is a sensible default-choice, so do it.
2021-08-26 14:43:26 +02:00
#include "dhcp/nm-dhcp-manager.h"
#include "libnm-core-aux-intern/nm-common-macros.h"
#include "libnm-core-intern/nm-core-internal.h"
#include "libnm-glib-aux/nm-c-list.h"
platform: move more platform code to src/libnm-platform/
2021-03-04 11:29:39 +01:00
#include "libnm-platform/nm-platform.h"
#include "libnm-platform/nmp-object.h"
core: sort includes in "src/core/nm-manager.c" This will be linked by CONTRIBUTING.md file as an example how to do it. Sorting includes by name is a sensible default-choice, so do it.
2021-08-26 14:43:26 +02:00
#include "libnm-std-aux/nm-dbus-compat.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"
manager: add audit support
2015-07-14 10:26:54 +02:00
#include "nm-audit-manager.h"
core: sort includes in "src/core/nm-manager.c" This will be linked by CONTRIBUTING.md file as an example how to do it. Sorting includes by name is a sensible default-choice, so do it.
2021-08-26 14:43:26 +02:00
#include "nm-auth-manager.h"
#include "nm-auth-utils.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-manager.h"
core: sort includes in "src/core/nm-manager.c" This will be linked by CONTRIBUTING.md file as an example how to do it. Sorting includes by name is a sensible default-choice, so do it.
2021-08-26 14:43:26 +02:00
#include "nm-checkpoint.h"
#include "nm-config.h"
#include "nm-connectivity.h"
#include "nm-dbus-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: sort includes in "src/core/nm-manager.c" This will be linked by CONTRIBUTING.md file as an example how to do it. Sorting includes by name is a sensible default-choice, so do it.
2021-08-26 14:43:26 +02:00
#include "nm-hostname-manager.h"
#include "nm-keep-alive.h"
#include "nm-policy.h"
nm-sudo: rename to nm-priv-helper The name "nm-sudo" reminds of the "sudo" tool, and this is a bit confusing because it's not related. Rename the service to "nm-priv-helper", which stands for "NM privileged helper". https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/938
2021-12-13 16:06:16 +01:00
#include "nm-priv-helper-call.h"
core: sort includes in "src/core/nm-manager.c" This will be linked by CONTRIBUTING.md file as an example how to do it. Sorting includes by name is a sensible default-choice, so do it.
2021-08-26 14:43:26 +02:00
#include "nm-rfkill-manager.h"
#include "nm-session-monitor.h"
#include "nm-sleep-monitor.h"
#include "settings/nm-settings-connection.h"
#include "settings/nm-settings.h"
#include "vpn/nm-vpn-manager.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
core: periodically cleanup unused device state files from /run Otherwise, we only prune unused files when the service terminates. Usually, NetworkManager service doesn't get restarted before shutdown of the system (nor should it be). That means, if you create (and destroy) a large number of software devices, the state files pile up. From time to time, go through the files on disk and delete those that are no longer relevant. In this case, "from time to time" means after we write/update state files 100 times.
2020-03-04 15:44:53 +01:00
#define DEVICE_STATE_PRUNE_RATELIMIT_MAX 100u
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 {
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
guint prop_id;
guint hw_prop_id;
core/rfkill: cleanup rfkill handling in NMManager - use "const RadioState" where possible - use "bool" bitfields in RadioState (boolean flags in structs should be `bool` types for consistency) and order fields by alignment. - break lines for variable declaration in manager_rfkill_update_one_type(). - return (and nm_assert()) from update_rstate_from_rfkill(). By not adding a default case, compiler would warn if we forget to handle an enum value. We can easily do that, by just returning, and let the "default" case be handled by nm_assert_not_reached() -- which unlike g_warn_if_reached() compiles to nothing in release build. - add nm_assert() that `priv->radio_states[rtype]` is not out of range. - use designated initializers for priv->radio_states[].
2022-02-01 20:07:18 +01:00
NMConfigRunStatePropertyType key;
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
} RfkillTypeDesc;
typedef struct {
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
bool available : 1;
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
bool user_enabled : 1;
bool sw_enabled : 1;
bool hw_enabled : 1;
core: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
bool os_owner : 1;
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
} RfkillRadioState;
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
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
AsyncOpType async_op_type;
union {
struct {
NMActiveConnection *active;
union {
struct {
GDBusMethodInvocation *invocation;
} activate_user;
struct {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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,
core: add 'device-ifindex-changed' signal NMManager now emits a 'device-ifindex-changed' whenever a device ifindex gets changed. https://bugzilla.redhat.com/show_bug.cgi?id=1870691 Signed-off-by: Antonio Cardace <acardace@redhat.com>
2021-01-19 18:57:58 +01:00
DEVICE_IFINDEX_CHANGED,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
LAST_SIGNAL
};
static guint signals[LAST_SIGNAL] = {0};
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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,
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
PROP_RADIO_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
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,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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;
core: add nm_manager_get_dns_manager() getter nm_dns_manager_get() is already a singleton. So users usually can just get it whenever they need -- except during shutdown after the singleton was destroyed. This is usually fine, because users really should not try to get it late during shutdown. However, if you subscribe a signal handler on the singleton, then you will also eventually want to unsubscribe it. While the moment when you subscribe it is clearly not during late-shutdown, it's not clear how to ensure that the signal listener gets destroyed before the DNS manager singleton. So usually, whenever you are going to subscribe a signal, you need to make sure that the target object stays alive long enough. Which may mean to keep a reference to it. Next, we will have NMDevice subscribe to the singleton. With above said, that would mean that potentially every NMDevice needs to keep a reference to the NMDnsManager. That is not best. Also, later NMManager will face the same problem, because it will also subscribe to NMDnsManager. So, instead let NMManager own a reference to the NMDnsManager. This ensures the lifetimes are properly guarded (NMDevice also references NMManager already). Also, access nm_dns_manager_get() lazy on first use, to only initialize it when needed the first time (which might be quite late).
2022-04-08 11:40:42 +02:00
NMDnsManager *dns_mgr;
core: delay startup complete while we have pending DNS updates While we have DNS updates pending, we cannot reach startup complete.
2022-04-08 12:01:51 +02:00
gulong dns_mgr_update_pending_signal_id;
core: add nm_manager_get_dns_manager() getter nm_dns_manager_get() is already a singleton. So users usually can just get it whenever they need -- except during shutdown after the singleton was destroyed. This is usually fine, because users really should not try to get it late during shutdown. However, if you subscribe a signal handler on the singleton, then you will also eventually want to unsubscribe it. While the moment when you subscribe it is clearly not during late-shutdown, it's not clear how to ensure that the signal listener gets destroyed before the DNS manager singleton. So usually, whenever you are going to subscribe a signal, you need to make sure that the target object stays alive long enough. Which may mean to keep a reference to it. Next, we will have NMDevice subscribe to the singleton. With above said, that would mean that potentially every NMDevice needs to keep a reference to the NMDnsManager. That is not best. Also, later NMManager will face the same problem, because it will also subscribe to NMDnsManager. So, instead let NMManager own a reference to the NMDnsManager. This ensures the lifetimes are properly guarded (NMDevice also references NMManager already). Also, access nm_dns_manager_get() lazy on first use, to only initialize it when needed the first time (which might be quite late).
2022-04-08 11:40:42 +02:00
manager: Add "Capabilities" property
2016-09-15 23:34:24 +03:00
GArray *capabilities;
core: reverse the order of active connections in the manager When a new active connection is created, it gets added at the beginning of manager's list. This means that the list contains most recently activated connections first. Since the list is doubly-linked, it is possible to efficiently iterate in both directions, so the order of the list is mostly a matter of convention. I think it is preferable to have oldest active connections at the beginning of the list; let's reverse the order. In most places where the list is iterated, the order doesn't matter. Where it does, use the *_prev() variant to maintain the old iteration order.
2020-11-04 13:53:57 +01:00
CList active_connections_lst_head; /* Oldest ACs at the beginning */
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMConfig *config;
NMConnectivity *concheck_mgr;
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/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
RfkillRadioState radio_states[NM_RFKILL_TYPE_MAX];
core/rfkill: cleanup rfkill handling in NMManager - use "const RadioState" where possible - use "bool" bitfields in RadioState (boolean flags in structs should be `bool` types for consistency) and order fields by alignment. - break lines for variable declaration in manager_rfkill_update_one_type(). - return (and nm_assert()) from update_rstate_from_rfkill(). By not adding a default case, compiler would warn if we forget to handle an enum value. We can easily do that, by just returning, and let the "default" case be handled by nm_assert_not_reached() -- which unlike g_warn_if_reached() compiles to nothing in release build. - add nm_assert() that `priv->radio_states[rtype]` is not out of range. - use designated initializers for priv->radio_states[].
2022-02-01 20:07:18 +01:00
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;
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
guint radio_flags;
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;
core: periodically cleanup unused device state files from /run Otherwise, we only prune unused files when the service terminates. Usually, NetworkManager service doesn't get restarted before shutdown of the system (nor should it be). That means, if you create (and destroy) a large number of software devices, the state files pile up. From time to time, go through the files on disk and delete those that are no longer relevant. In this case, "from time to time" means after we write/update state files 100 times.
2020-03-04 15:44:53 +01:00
guint8 device_state_prune_ratelimit_count;
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;
Revert "manager: drop devices_inited field in NManagerPrivate for devices_inited_id" After this change the startup-complete event is reached too early, even before priv->devices_inited_id is initialized. This reverts commit d50856b5c66e6d7a8ab1af7826297787e72e06e7.
2020-02-17 13:24:28 +01:00
bool devices_inited : 1;
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 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;
manager: make "nmcli net off" wait for deactivations The current behavior of "nmcli networking off" is that it starts disconnecting the devices, but doesn't wait for them to actually come down. That is not too helpful: the user never knows when the network is actually disconnected. Some users, notably the NetworkManager-CI test suite, seem to expect the devices are all disconnected after the command finishes. Even worse, it immediately proceeds activating the connections: @ovs_cloned_mac_set_on_iface ... * Execute "nmcli networking off && nmcli networking on" This results in pure utter chaos. In particular, the slave connections sometimes refuse to activate after "nmcli networking on", because the master connections are still getting disconnected in response to preceding "nmcli networking off". Let's make Enable(FALSE) and Sleep(TRUE) block until none of the devices are expected to go down. Note that this makes those call also return when Enable(TRUE) and Sleep(FALSE) is issued in meanwhile. Therefore a return from Enable(FALSE) doesn't necessarily imply the networking is disabled. This is a feature, not a bug -- the actual manager state is available in the "state" property. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:06:14 +02:00
/* List of GDBusMethodInvocation of in progress Sleep() and Enable()
* calls. They return only if all in-flight deactivations finished. */
GSList *sleep_invocations;
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;
core: use nm-sudo symbols in NetworkManager binary for plugin The two nm-sudo helper functions are only used by the OVS device plugin, but they are part of NetworkManager core binary. This is done commonly, where the NetworkManager binary has symbols that are used by the plugins. But in this case, NetworkManager itself doesn't use the symbols. That will case the linker to drop them. A previous solution for that was commit 684f2acffea3 ('build: add way to keep unused symbols when linking NetworkManager'), but that doesn't seem to work with clang 3.4 (rhel-7). Instead, actually use the symbol so that it cannot be dropped.
2021-08-31 13:20:59 +02:00
#if WITH_OPENVSWITCH
/* these fields only serve the purpose to use the symbols.*/
nm-sudo: rename to nm-priv-helper The name "nm-sudo" reminds of the "sudo" tool, and this is a bit confusing because it's not related. Rename the service to "nm-priv-helper", which stands for "NM privileged helper". https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/938
2021-12-13 16:06:16 +01:00
void (*_use_symbol_nm_priv_helper_call_get_fd)(void);
void (*_use_symbol_nm_priv_helper_utils_open_fd)(void);
core: use nm-sudo symbols in NetworkManager binary for plugin The two nm-sudo helper functions are only used by the OVS device plugin, but they are part of NetworkManager core binary. This is done commonly, where the NetworkManager binary has symbols that are used by the plugins. But in this case, NetworkManager itself doesn't use the symbols. That will case the linker to drop them. A previous solution for that was commit 684f2acffea3 ('build: add way to keep unused symbols when linking NetworkManager'), but that doesn't seem to work with clang 3.4 (rhel-7). Instead, actually use the symbol so that it cannot be dropped.
2021-08-31 13:20:59 +02:00
#endif
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
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
#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
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
#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__)); \
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
} \
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
static void update_connectivity_value(NMManager *self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
static gboolean add_device(NMManager *self, NMDevice *device, GError **error);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
static void _emit_device_added_removed(NMManager *self, NMDevice *device, gboolean is_added);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSettingsConnection *sett_conn,
NMConnection *incompl_conn,
NMConnection *applied,
const char *specific_object,
NMDevice *device,
NMAuthSubject *subject,
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
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError **error);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
static void policy_activating_ac_changed(GObject *object, GParamSpec *pspec, gpointer user_data);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: delay startup complete while we have pending DNS updates While we have DNS updates pending, we cannot reach startup complete.
2022-04-08 12:01:51 +02:00
static void device_has_pending_action_changed(NMDevice *device, GParamSpec *pspec, NMManager *self);
static void check_if_startup_complete(NMManager *self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
static gboolean find_master(NMManager *self,
NMConnection *connection,
NMDevice *device,
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
NMSettingsConnection **out_master_connection,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice **out_master_device,
NMActiveConnection **out_master_ac,
GError **error);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
static void nm_manager_update_state(NMManager *manager);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
static void
settings_startup_complete_changed(NMSettings *settings, GParamSpec *pspec, NMManager *self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
static void retry_connections_for_parent_device(NMManager *self, NMDevice *device);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
static NMActiveConnection *active_connection_find(NMManager *self,
NMSettingsConnection *sett_conn,
const char *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
NMActiveConnectionState max_state,
manager: fix active_connection_find() Commit 33b9fa3a3caf ("manager: Keep volatile/external connections while referenced by async_op_lst") changed active_connection_find() to also return active connections that are not yet activating but are waiting authorization. This has side effect for other callers of the function. In particular, _get_activatable_connections_filter() should exclude only ACs that are really active, not those waiting for authorization. Otherwise, in ensure_master_active_connection() all the ACs waiting authorization are missed and we might fail to find the right master AC. Add an argument to active_connection_find to select whether include ACs waiting authorization. Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1955101
2021-05-13 10:49:39 +02:00
gboolean also_waiting_auth,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GPtrArray **out_all_matching);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
connectivity: emit properties-changed about connectivity settings
2018-04-10 15:55:16 +02:00
static NMConnectivity *concheck_get_mgr(NMManager *self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
static void _internal_activation_auth_done(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
NMActiveConnection *active,
gboolean success,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *error_desc);
static void _activation_auth_done(NMManager *self,
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
GDBusMethodInvocation *invocation,
gboolean success,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *error_desc);
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
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
static void _rfkill_update(NMManager *self, NMRfkillType rtype);
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
/*****************************************************************************/
all: require a semicolon after NM_CACHED_QUARK_FCN()
2020-09-23 10:53:06 +02:00
static NM_CACHED_QUARK_FCN("autoconnect-root", autoconnect_root_quark);
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
/*****************************************************************************/
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_async_op_data_new_ac_auth_activate_user(NMManager *self,
NMActiveConnection *active_take,
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
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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMActiveConnection *active_take,
GDBusMethodInvocation *invocation_take,
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: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
nm_assert(NM_IN_SET(async_op_type,
ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE,
ASYNC_OP_TYPE_AC_AUTH_ADD_AND_ACTIVATE2));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *error_desc,
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
gpointer user_data)
{
AsyncOpData *async_op_data = user_data;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
c_list_unlink(&async_op_data->async_op_lst);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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;
all: use nm_hash_vals()/nm_hash_val() where it's shorter
2022-09-23 12:56:54 +02:00
return nm_hash_val(1030338191, data->ifindex);
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
}
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_device_route_metric_get(NMManager *self,
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
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv;
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
const DeviceRouteMetricData *d2;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
DeviceRouteMetricData *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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_return_val_if_fail(NM_IS_MANAGER(self), 0);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
priv = NM_MANAGER_GET_PRIVATE(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
if (lookup_only && !priv->device_route_metrics)
return 0;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
if (G_UNLIKELY(!priv->device_route_metrics)) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const GHashTable *h;
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
const NMConfigDeviceStateData *device_state;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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.
*
all: fix minor typos https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
2020-07-04 11:37:01 +03:00
* Do do this cleanup, whenever we have more entries then 2 times the number of links. */
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 (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;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv;
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_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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: add "external" flag for connections of external devices When a device is not marked as unmanaged, but also not actively managed by NetworkManager, then NetworkManager will generate an in-memory profile to represent the active state, if the device is up and configured (with an IP address). Such profiles are commonly named like "eth0", and they are utterly confusing to users, because they look as if NetworkManager actually manages the device, when it really just shows that somebody else configures the device. We should express this better in the UI, hence add flags to indicate that. In practice, such profiles are UNSAVED, NM_GENERATED, and VOLATILE. But add an explicit flag to represent that. https://bugzilla.redhat.com/show_bug.cgi?id=1816202
2020-06-08 19:34:50 +02:00
if (!NM_FLAGS_ANY(nm_settings_connection_get_flags(connection),
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE
| NM_SETTINGS_CONNECTION_INT_FLAGS_EXTERNAL))
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,
manager: fix active_connection_find() Commit 33b9fa3a3caf ("manager: Keep volatile/external connections while referenced by async_op_lst") changed active_connection_find() to also return active connections that are not yet activating but are waiting authorization. This has side effect for other callers of the function. In particular, _get_activatable_connections_filter() should exclude only ACs that are really active, not those waiting for authorization. Otherwise, in ensure_master_active_connection() all the ACs waiting authorization are missed and we might fail to find the right master AC. Add an argument to active_connection_find to select whether include ACs waiting authorization. Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1955101
2021-05-13 10:49:39 +02:00
TRUE,
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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
_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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(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
NMActiveConnectionState state;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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: reverse the order of active connections in the manager When a new active connection is created, it gets added at the beginning of manager's list. This means that the list contains most recently activated connections first. Since the list is doubly-linked, it is possible to efficiently iterate in both directions, so the order of the list is mostly a matter of convention. I think it is preferable to have oldest active connections at the beginning of the list; let's reverse the order. In most places where the list is iterated, the order doesn't matter. Where it does, use the *_prev() variant to maintain the old iteration order.
2020-11-04 13:53:57 +01:00
c_list_link_tail(&priv->active_connections_lst_head, &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_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(
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self,
NMSettingsConnection *sett_conn,
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: fix active_connection_find() Commit 33b9fa3a3caf ("manager: Keep volatile/external connections while referenced by async_op_lst") changed active_connection_find() to also return active connections that are not yet activating but are waiting authorization. This has side effect for other callers of the function. In particular, _get_activatable_connections_filter() should exclude only ACs that are really active, not those waiting for authorization. Otherwise, in ensure_master_active_connection() all the ACs waiting authorization are missed and we might fail to find the right master AC. Add an argument to active_connection_find to select whether include ACs waiting authorization. Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1955101
2021-05-13 10:49:39 +02:00
gboolean also_waiting_auth /* return also ACs waiting authorization */,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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;
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GPtrArray *all = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: return most recent connection in active_connection_find() When a connection is reactivated, there could be two active connections tracked by the manager: the deactivating one and the new one. Ensure that we first return the most recent one so that slaves will pick the right master. Fixes-test: @iptunnel_gretap_doc_procedure Fixes: dc6ec6ce7b8d ('core: reverse the order of active connections in the manager') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/697
2020-11-27 19:31:22 +01:00
c_list_for_each_entry_prev (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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (!out_all_matching)
return ac;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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) {
best_ac = ac;
continue;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (!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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: Keep volatile/external connections while referenced by async_op_lst If an NMSettingsConnection with the VOLATILE or EXTENRAL flags is created and passed to nm_manager_activate_connection, it's immediately scheduled for deletion in an idle callback and will likely be deleted before the authorization step in nm_manager_activate_connection finishes and the connection will be aborted. This is because there's no NMActiveConnection in priv->active_connection_lst_head referencing it until _internal_activate_device(). Change active_connection_find_by_connection to also look for connections in priv->async_op_lst_head. New _delete_volatile_connection_do() calls are added. Previously it would be called when an active connection may have been removed from priv->active_connection_lst_head, now also call it when an active connection may have been removed from priv->async_op_lst_head without being added to priv->active_connection_lst_head. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/671
2020-11-04 09:46:41 +01:00
if (!best_ac) {
core/trivial: fix clang-format code formatting
2020-11-12 15:34:59 +01:00
AsyncOpData *async_op_data;
manager: Keep volatile/external connections while referenced by async_op_lst If an NMSettingsConnection with the VOLATILE or EXTENRAL flags is created and passed to nm_manager_activate_connection, it's immediately scheduled for deletion in an idle callback and will likely be deleted before the authorization step in nm_manager_activate_connection finishes and the connection will be aborted. This is because there's no NMActiveConnection in priv->active_connection_lst_head referencing it until _internal_activate_device(). Change active_connection_find_by_connection to also look for connections in priv->async_op_lst_head. New _delete_volatile_connection_do() calls are added. Previously it would be called when an active connection may have been removed from priv->active_connection_lst_head, now also call it when an active connection may have been removed from priv->async_op_lst_head without being added to priv->active_connection_lst_head. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/671
2020-11-04 09:46:41 +01:00
manager: fix active_connection_find() Commit 33b9fa3a3caf ("manager: Keep volatile/external connections while referenced by async_op_lst") changed active_connection_find() to also return active connections that are not yet activating but are waiting authorization. This has side effect for other callers of the function. In particular, _get_activatable_connections_filter() should exclude only ACs that are really active, not those waiting for authorization. Otherwise, in ensure_master_active_connection() all the ACs waiting authorization are missed and we might fail to find the right master AC. Add an argument to active_connection_find to select whether include ACs waiting authorization. Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1955101
2021-05-13 10:49:39 +02:00
if (!also_waiting_auth)
return NULL;
manager: Keep volatile/external connections while referenced by async_op_lst If an NMSettingsConnection with the VOLATILE or EXTENRAL flags is created and passed to nm_manager_activate_connection, it's immediately scheduled for deletion in an idle callback and will likely be deleted before the authorization step in nm_manager_activate_connection finishes and the connection will be aborted. This is because there's no NMActiveConnection in priv->active_connection_lst_head referencing it until _internal_activate_device(). Change active_connection_find_by_connection to also look for connections in priv->async_op_lst_head. New _delete_volatile_connection_do() calls are added. Previously it would be called when an active connection may have been removed from priv->active_connection_lst_head, now also call it when an active connection may have been removed from priv->async_op_lst_head without being added to priv->active_connection_lst_head. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/671
2020-11-04 09:46:41 +01:00
c_list_for_each_entry (async_op_data, &priv->async_op_lst_head, async_op_lst) {
NMSettingsConnection *ac_conn;
core/trivial: fix clang-format code formatting
2020-11-12 15:34:59 +01:00
ac = async_op_data->ac_auth.active;
manager: fix assertion failure in active_connection_find() Active-connections in the async_op_lst are not guaranteed to have a settings-connection. In particular, the settings-connection for an AddAndActivate() AC is set only after the authorization succeeds. Use the non-asserting variant of the function to fix the following failure: nm_active_connection_get_settings_connection: assertion 'sett_conn' failed 1 _g_log_abort() 2 g_logv() 3 g_log() 4 _nm_g_return_if_fail_warning.constprop.14() 5 nm_active_connection_get_settings_connection() 6 active_connection_find() 7 _get_activatable_connections_filter() 8 nm_settings_get_connections_clone() 9 nm_manager_get_activatable_connections() 10 auto_activate_device_cb() 11 g_idle_dispatch() 12 g_main_context_dispatch() 13 g_main_context_iterate.isra.21() 14 g_main_loop_run() 15 main() Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1933719 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/834
2021-04-30 22:35:20 +02:00
ac_conn = _nm_active_connection_get_settings_connection(ac);
manager: Keep volatile/external connections while referenced by async_op_lst If an NMSettingsConnection with the VOLATILE or EXTENRAL flags is created and passed to nm_manager_activate_connection, it's immediately scheduled for deletion in an idle callback and will likely be deleted before the authorization step in nm_manager_activate_connection finishes and the connection will be aborted. This is because there's no NMActiveConnection in priv->active_connection_lst_head referencing it until _internal_activate_device(). Change active_connection_find_by_connection to also look for connections in priv->async_op_lst_head. New _delete_volatile_connection_do() calls are added. Previously it would be called when an active connection may have been removed from priv->active_connection_lst_head, now also call it when an active connection may have been removed from priv->async_op_lst_head without being added to priv->active_connection_lst_head. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/671
2020-11-04 09:46:41 +01:00
if (sett_conn && sett_conn != ac_conn)
continue;
if (uuid && !nm_streq0(uuid, nm_settings_connection_get_uuid(ac_conn)))
continue;
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));
}
if (!best_ac)
return NULL;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
active_connection_find_by_connection(NMManager *self,
NMSettingsConnection *sett_conn,
NMConnection *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
NMActiveConnectionState max_state,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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,
manager: fix active_connection_find() Commit 33b9fa3a3caf ("manager: Keep volatile/external connections while referenced by async_op_lst") changed active_connection_find() to also return active connections that are not yet activating but are waiting authorization. This has side effect for other callers of the function. In particular, _get_activatable_connections_filter() should exclude only ACs that are really active, not those waiting for authorization. Otherwise, in ensure_master_active_connection() all the ACs waiting authorization are missed and we might fail to find the right master AC. Add an argument to active_connection_find to select whether include ACs waiting authorization. Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1955101
2021-05-13 10:49:39 +02:00
FALSE,
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
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: add "external" flag for connections of external devices When a device is not marked as unmanaged, but also not actively managed by NetworkManager, then NetworkManager will generate an in-memory profile to represent the active state, if the device is up and configured (with an IP address). Such profiles are commonly named like "eth0", and they are utterly confusing to users, because they look as if NetworkManager actually manages the device, when it really just shows that somebody else configures the device. We should express this better in the UI, hence add flags to indicate that. In practice, such profiles are UNSAVED, NM_GENERATED, and VOLATILE. But add an explicit flag to represent that. https://bugzilla.redhat.com/show_bug.cgi?id=1816202
2020-06-08 19:34:50 +02:00
if (NM_FLAGS_ANY(nm_settings_connection_get_flags(sett_conn),
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE
| NM_SETTINGS_CONNECTION_INT_FLAGS_EXTERNAL))
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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,
manager: fix active_connection_find() Commit 33b9fa3a3caf ("manager: Keep volatile/external connections while referenced by async_op_lst") changed active_connection_find() to also return active connections that are not yet activating but are waiting authorization. This has side effect for other callers of the function. In particular, _get_activatable_connections_filter() should exclude only ACs that are really active, not those waiting for authorization. Otherwise, in ensure_master_active_connection() all the ACs waiting authorization are missed and we might fail to find the right master AC. Add an argument to active_connection_find to select whether include ACs waiting authorization. Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1955101
2021-05-13 10:49:39 +02:00
FALSE,
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);
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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 = {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
.self = manager,
.for_auto_activation = for_auto_activation,
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
};
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
core: use nm_dbus_manager_lookup_object_with_type() I think this makes it clearer that we should always look for a certain type, because NMDBusManager tracks all D-Bus objects.
2022-02-22 21:19:18 +01:00
ac = nm_dbus_manager_lookup_object_with_type(nm_dbus_object_get_manager(NM_DBUS_OBJECT(self)),
NM_TYPE_ACTIVE_CONNECTION,
path);
if (!ac || c_list_is_empty(&ac->active_connections_lst))
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
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_config_changed_cb(NMConfig *config,
NMConfigData *config_data,
config: use flags argument in config-changed signal instead of a hash table
2015-01-21 12:58:32 +01:00
NMConfigChangeFlags changes,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
GError *ret_error = NULL;
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
NMAuthCallResult result;
guint32 flags;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMAuthSubject *subject;
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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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"));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
subject = nm_auth_chain_get_subject(chain);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
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");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_reload(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(obj);
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
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
g_variant_get(parameters, "(u)", &flags);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
core: use nm_dbus_manager_lookup_object_with_type() I think this makes it clearer that we should always look for a certain type, because NMDBusManager tracks all D-Bus objects.
2022-02-22 21:19:18 +01:00
device =
nm_dbus_manager_lookup_object_with_type(nm_dbus_object_get_manager(NM_DBUS_OBJECT(self)),
NM_TYPE_DEVICE,
path);
if (!device || c_list_is_empty(&device->devices_lst))
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
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *device;
const char *device_addr;
core: use _NM_UTILS_HWADDR_LEN_MAX instead of NM_UTILS_HWADDR_LEN_MAX
2021-03-03 20:57:01 +01:00
guint8 hwaddr_bin[_NM_UTILS_HWADDR_LEN_MAX];
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
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);
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 (device_addr && 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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
find_device_by_iface(NMManager *self,
const char *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
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *fallback = NULL;
NMDevice *candidate;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
g_return_val_if_fail(iface != NULL, NULL);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
c_list_for_each_entry (candidate, &priv->devices_lst_head, devices_lst) {
core: use nm_streq*() instead of strcmp() in "nm-device.c" and "nm-manager.c"
2020-07-20 09:31:03 +02:00
if (!nm_streq(nm_device_get_iface(candidate), 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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *device;
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 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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
manager_device_state_changed(NMDevice *device,
bluetooth: resync bluetooth devices on connection events
2009-05-20 12:02:18 -04:00
NMDeviceState new_state,
NMDeviceState old_state,
NMDeviceStateReason reason,
gpointer user_data)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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,
core: periodically cleanup unused device state files from /run Otherwise, we only prune unused files when the service terminates. Usually, NetworkManager service doesn't get restarted before shutdown of the system (nor should it be). That means, if you create (and destroy) a large number of software devices, the state files pile up. From time to time, go through the files on disk and delete those that are no longer relevant. In this case, "from time to time" means after we write/update state files 100 times.
2020-03-04 15:44:53 +01:00
NM_DEVICE_STATE_ACTIVATED)) {
core: return ifindex from nm_manager_write_device_state() nm_manager_write_device_state() writes the device state to a file. The ifindex is here important, because that is the identifier for the device and is also used as file name. Return the ifindex that was used, instead of letting the caller reimplement the knowledge which ifindex was used.
2020-03-04 13:38:49 +01:00
nm_manager_write_device_state(self, device, NULL);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: periodically cleanup unused device state files from /run Otherwise, we only prune unused files when the service terminates. Usually, NetworkManager service doesn't get restarted before shutdown of the system (nor should it be). That means, if you create (and destroy) a large number of software devices, the state files pile up. From time to time, go through the files on disk and delete those that are no longer relevant. In this case, "from time to time" means after we write/update state files 100 times.
2020-03-04 15:44:53 +01:00
G_STATIC_ASSERT_EXPR(DEVICE_STATE_PRUNE_RATELIMIT_MAX < G_MAXUINT8);
if (priv->device_state_prune_ratelimit_count++ > DEVICE_STATE_PRUNE_RATELIMIT_MAX) {
/* We write the device state to /run. The state files are named after the
* ifindex (which is assumed to be unique and not repeat -- in practice
* it may repeat). So from time to time, we prune device state files
* for interfaces that no longer exist.
*
* Otherwise, the files might pile up if you create (and destroy) a large
* number of software devices. */
priv->device_state_prune_ratelimit_count = 0;
nm_config_device_state_prune_stale(NULL, priv->platform);
}
}
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: delay startup complete while we have pending DNS updates While we have DNS updates pending, we cannot reach startup complete.
2022-04-08 12:01:51 +02:00
static void
_dns_mgr_update_pending_cb(NMDevice *device, GParamSpec *pspec, NMManager *self)
{
check_if_startup_complete(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
static void
check_if_startup_complete(NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *device;
const char *reason;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
if (!priv->startup)
return;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
Revert "manager: drop devices_inited field in NManagerPrivate for devices_inited_id" After this change the startup-complete event is reached too early, even before priv->devices_inited_id is initialized. This reverts commit d50856b5c66e6d7a8ab1af7826297787e72e06e7.
2020-02-17 13:24:28 +01:00
if (!priv->devices_inited)
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
return;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: delay startup complete while we have pending DNS updates While we have DNS updates pending, we cannot reach startup complete.
2022-04-08 12:01:51 +02:00
if (nm_dns_manager_get_update_pending(nm_manager_get_dns_manager(self))) {
if (priv->dns_mgr_update_pending_signal_id == 0) {
priv->dns_mgr_update_pending_signal_id =
g_signal_connect(nm_manager_get_dns_manager(self),
"notify::" NM_DNS_MANAGER_UPDATE_PENDING,
G_CALLBACK(_dns_mgr_update_pending_cb),
self);
}
return;
}
nm_clear_g_signal_handler(nm_manager_get_dns_manager(self),
&priv->dns_mgr_update_pending_signal_id);
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;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
settings: rework wait-device-timeout handling and consider device compatibility A profile can configure "connection.wait-device-timeout" to indicate that startup complete is blocked until a suitable device around. This is useful for NetworkManager-wait-online and initrd mode. Previously, we looked at NMPlatform whether a link with matching interface-name was present. That is wrong because it cannot handle profiles that rely on "ethernet.mac-address" setting or other "match" settings. Also, the mere presence of the link does not yet mean that the NMDevice was created and ready. In fact, there is a race here: NMPlatform indicates that the device is ready (unblocking NMSettings), but there is no corresponding NMDevice yet which keeps NetworkManager busy to block startup complete. Rework this. Now, only check whether there is a compatible device for the profile. Since we wait for compatible devices, it works now not only for the interface name. Note that we do some optimizations so that we don't have to re-evaluate all profiles (w.r.t. all devices) whenever something on the device changes: we only care about this when all devices finally become ready. Also, we no longer start the timeout for "connection.wait-device-timeout" when the profile appears. Instead, there is one system-wide start time (NMSettingsPrivate.startup_complete_start_timestamp_msec). That simplifies code and makes sense: we start waiting when NetworkManager is starting, not when the profile gets added. Also, we wait for all profiles to become ready together.
2020-08-11 15:34:59 +02:00
/* All NMDevice must be ready. But also NMSettings tracks profiles that wait for
* ready devices via "connection.wait-device-timeout".
*
* Note that we only re-check nm_settings_get_startup_complete_blocked_reason() when
* all of the devices become ready (again).
*
* For example, assume we have device "eth1" and "profile-eth2" which waits for "eth2".
* If "eth1" is ready (no pending action), we only need to re-evaluate "profile-eth2"
* if we have another device ("eth2"), that becomes non-ready (had pending actions)
* and again become ready. We don't need to check "profile-eth2" until "eth2" becomes
* non-ready.
* That is why nm_settings_get_startup_complete_blocked_reason() only has any significance
* if all devices are ready too. It allows us to cut down the number of checks whether
* NMSettings is ready. That's because we don't need to re-evaluate on minor changes of
* a device, only when all devices become managed and ready. */
g_signal_handlers_block_by_func(priv->settings, settings_startup_complete_changed, self);
reason = nm_settings_get_startup_complete_blocked_reason(priv->settings, TRUE);
g_signal_handlers_unblock_by_func(priv->settings, settings_startup_complete_changed, self);
if (reason) {
_LOGD(LOGD_CORE, "startup complete is waiting for connection (%s)", reason);
return;
}
core/trivial: add comment about "startup complate" log message
2022-03-02 11:13:52 +01:00
/* Most of our logging is not API/stable, but this line is kinda important and
* what people will look for when debugging NetworkManager-wait-online.service.
* Take care before rewording this message. */
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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, NMDevice *device, 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;
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
NMRfkillType rtype;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
}
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
c_list_unlink(&device->devices_lst);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
rtype = nm_device_get_rfkill_type(device);
if (rtype != NM_RFKILL_TYPE_UNKNOWN)
_rfkill_update(self, rtype);
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
/* 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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
find_parent_device_for_connection(NMManager *self,
NMConnection *connection,
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
NMDeviceFactory *cached_factory,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char **out_parent_spec)
core: automatically create VLAN interfaces when needed
2012-02-12 14:48:44 -06:00
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *parent, *first_compatible = NULL;
NMDevice *candidate;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
parent_name = nm_device_factory_get_connection_parent(factory, connection);
if (!parent_name)
return NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
NM_SET_OUT(out_parent_spec, parent_name);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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) {
core: accept unmanaged parent if it's unrealized find_parent_device_for_connection() must return a parent device even if it's unrealized. In fact, callers already handle the unrealized case; in specific: - _internal_activate_device() will try to autoactivate a connection on the unrealized parent to realize it; - system_create_virtual_device()'s goal is to create a NMDevice object, so it doesn't matter whether the parent is realized or not. Relax the condition about managed-ness, since any unrealized device is also unmanaged. This change fixes the following scenario, where all profiles have autoconnect=no and autoconnect-slaves=yes: vrf0 -------------^---------------- | | | | bridge0 bond0.4000 | . bond0 <...................... ---^--- | | veth0 veth1 ----> = controller ....> = VLAN parent When profiles are added, unrealized devices are created for bond0 and bridge0, but not for bond0.4000 becase its parent is unrealized. Then the autoconnect-slaves machinery for vrf0 tries to activate all ports but fails for bond0.4000 because it can't find a device for it. https://bugzilla.redhat.com/show_bug.cgi?id=2101317
2022-09-09 17:34:15 +02:00
/* For a realized device, check that it's managed; otherwise it's not
* compatible with any connection. If the device is unrealized then
* the managed state is meaningless.
*/
if (nm_device_is_real(candidate) && !nm_device_get_managed(candidate, FALSE))
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
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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
nm_manager_get_connection_iface(NMManager *self,
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
NMConnection *connection,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice **out_parent,
const char **out_parent_spec,
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
char *iface = NULL;
NMDevice *parent = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
NM_SET_OUT(out_parent, NULL);
NM_SET_OUT(out_parent_spec, NULL);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_set_error(error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_FAILED,
"NetworkManager plugin for '%s' unavailable",
nm_connection_get_connection_type(connection));
return NULL;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
if (!out_parent && !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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
NMDeviceFactory *factory;
core: add nm_settings_get_connection_sorted_by_autoconnect_priority() Turns out, we call nm_settings_get_connection_clone() *a lot* with sort order nm_settings_connection_cmp_autoconnect_priority_p_with_data(). As we cache the (differently sorted) list of connections, also cache the presorted list. The only complication is that every time we still need to check whether the list is still sorted, because it would be more complicated to invalidate the list when an entry changes which affects the sort order. Still, such a check is usually successful and requires "only" N-1 comparisons.
2021-06-15 00:41:45 +02:00
NMSettingsConnection *const *connections;
guint i;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_free char *iface = NULL;
const char *parent_spec;
NMDevice *device = NULL, *parent = NULL;
NMDevice *dev_candidate;
GError *error = NULL;
core: add nm_settings_get_connection_sorted_by_autoconnect_priority() Turns out, we call nm_settings_get_connection_clone() *a lot* with sort order nm_settings_connection_cmp_autoconnect_priority_p_with_data(). As we cache the (differently sorted) list of connections, also cache the presorted list. The only complication is that every time we still need to check whether the list is still sorted, because it would be more complicated to invalidate the list when an entry changes which affects the sort order. Still, such a check is usually successful and requires "only" N-1 comparisons.
2021-06-15 00:41:45 +02:00
NMLogLevel log_level;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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. */
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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", nm_device_get_iface(device));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: skip activation of a virtual device if master is missing Don't realize a virtual device if the master is missing because in such case the autoactivation can't start and a stale link will be created.
2020-01-27 18:38:00 +01:00
if (!find_master(self, connection, device, NULL, NULL, NULL, &error)) {
_LOG3D(LOGD_DEVICE, connection, "skip activation: %s", error->message);
g_error_free(error);
return device;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* Create backing resources if the device has any autoconnect connections */
core: add nm_settings_get_connection_sorted_by_autoconnect_priority() Turns out, we call nm_settings_get_connection_clone() *a lot* with sort order nm_settings_connection_cmp_autoconnect_priority_p_with_data(). As we cache the (differently sorted) list of connections, also cache the presorted list. The only complication is that every time we still need to check whether the list is still sorted, because it would be more complicated to invalidate the list when an entry changes which affects the sort order. Still, such a check is usually successful and requires "only" N-1 comparisons.
2021-06-15 00:41:45 +02:00
connections = nm_settings_get_connections_sorted_by_autoconnect_priority(priv->settings, 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++) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
s_con = nm_connection_get_setting_connection(candidate);
g_assert(s_con);
manager: create a virtual device only if the connection can autoconnect The autoconnection for virtual devices currently works in two phases. First we detect that there is suitable profile that can autoconnect and we realize the device. Then, when the device becomes 'disconnected', autoconnect kicks in and starts the activation. However, if autoconnect is blocked for a device, currently we do step 1 without step 2, leaving a stale interface around. Fix this by also checking that autoconnect is not blocked during step 1. https://bugzilla.redhat.com/show_bug.cgi?id=1765047 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/360
2019-12-13 18:05:38 +01:00
if (!nm_setting_connection_get_autoconnect(s_con)
|| nm_settings_connection_autoconnect_is_blocked(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
continue;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
core: add nm_settings_get_connection_sorted_by_autoconnect_priority() Turns out, we call nm_settings_get_connection_clone() *a lot* with sort order nm_settings_connection_cmp_autoconnect_priority_p_with_data(). As we cache the (differently sorted) list of connections, also cache the presorted list. The only complication is that every time we still need to check whether the list is still sorted, because it would be more complicated to invalidate the list when an entry changes which affects the sort order. Still, such a check is usually successful and requires "only" N-1 comparisons.
2021-06-15 00:41:45 +02:00
NMSettingsConnection *const *connections;
guint i;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
g_return_if_fail(device);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: add nm_settings_get_connection_sorted_by_autoconnect_priority() Turns out, we call nm_settings_get_connection_clone() *a lot* with sort order nm_settings_connection_cmp_autoconnect_priority_p_with_data(). As we cache the (differently sorted) list of connections, also cache the presorted list. The only complication is that every time we still need to check whether the list is still sorted, because it would be more complicated to invalidate the list when an entry changes which affects the sort order. Still, such a check is usually successful and requires "only" N-1 comparisons.
2021-06-15 00:41:45 +02:00
connections = nm_settings_get_connections_sorted_by_autoconnect_priority(priv->settings, 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];
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_free char *ifname = NULL;
NMDevice *parent;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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, 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
{
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
core: add "external" flag for connections of external devices When a device is not marked as unmanaged, but also not actively managed by NetworkManager, then NetworkManager will generate an in-memory profile to represent the active state, if the device is up and configured (with an IP address). Such profiles are commonly named like "eth0", and they are utterly confusing to users, because they look as if NetworkManager actually manages the device, when it really just shows that somebody else configures the device. We should express this better in the UI, hence add flags to indicate that. In practice, such profiles are UNSAVED, NM_GENERATED, and VOLATILE. But add an explicit flag to represent that. https://bugzilla.redhat.com/show_bug.cgi?id=1816202
2020-06-08 19:34:50 +02:00
if (NM_FLAGS_ANY(nm_settings_connection_get_flags(sett_conn),
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE
| NM_SETTINGS_CONNECTION_INT_FLAGS_EXTERNAL))
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
return;
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
}
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, NMSettingsConnection *sett_conn, 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
{
Revert "core: create virtual device on settings changes in idle handler" When AddConnection() or Update() terminate, the (unrealized) virtual device should be already be available, otherwise an activation attempt of that connection can fail. https://bugzilla.redhat.com/show_bug.cgi?id=1804350 This reverts commit c163207b077a0e66e344b2352ccbe392c76e63ed.
2020-02-18 19:09:18 +01:00
connection_changed(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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *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
{
Revert "core: create virtual device on settings changes in idle handler" When AddConnection() or Update() terminate, the (unrealized) virtual device should be already be available, otherwise an activation attempt of that connection can fail. https://bugzilla.redhat.com/show_bug.cgi?id=1804350 This reverts commit c163207b077a0e66e344b2352ccbe392c76e63ed.
2020-02-18 19:09:18 +01:00
connection_changed(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
}
manager: recreate virtual devices on "nmcli net on" "nmcli networking off" brings down all connections, resulting in virtual devices disappearing: # nmcli c add type dummy ifname dummy0 # nmcli networking off # nmcli networking on # nmcli d show dummy0 Error: Device 'dummy0' not found. Attempt to recreate them all upon bringing the networking back up. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:07:09 +02:00
static void
connections_changed(NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
NMSettingsConnection *const *connections;
guint i;
connections = nm_settings_get_connections_sorted_by_autoconnect_priority(priv->settings, NULL);
for (i = 0; connections[i]; i++)
connection_changed(self, connections[i]);
}
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = user_data;
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
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = user_data;
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
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: add "external" flag for connections of external devices When a device is not marked as unmanaged, but also not actively managed by NetworkManager, then NetworkManager will generate an in-memory profile to represent the active state, if the device is up and configured (with an IP address). Such profiles are commonly named like "eth0", and they are utterly confusing to users, because they look as if NetworkManager actually manages the device, when it really just shows that somebody else configures the device. We should express this better in the UI, hence add flags to indicate that. In practice, such profiles are UNSAVED, NM_GENERATED, and VOLATILE. But add an explicit flag to represent that. https://bugzilla.redhat.com/show_bug.cgi?id=1816202
2020-06-08 19:34:50 +02:00
if (!NM_FLAGS_ANY(nm_settings_connection_get_flags(connection),
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE
| NM_SETTINGS_CONNECTION_INT_FLAGS_EXTERNAL))
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (active_connection_find(self,
connection,
NULL,
NM_ACTIVE_CONNECTION_STATE_DEACTIVATED,
manager: fix active_connection_find() Commit 33b9fa3a3caf ("manager: Keep volatile/external connections while referenced by async_op_lst") changed active_connection_find() to also return active connections that are not yet activating but are waiting authorization. This has side effect for other callers of the function. In particular, _get_activatable_connections_filter() should exclude only ACs that are really active, not those waiting for authorization. Otherwise, in ensure_master_active_connection() all the ACs waiting authorization are missed and we might fail to find the right master AC. Add an argument to active_connection_find to select whether include ACs waiting authorization. Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1955101
2021-05-13 10:49:39 +02:00
FALSE,
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
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, 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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(user_data);
settings: rename NMSysconfigSettings to NMSettings
2010-10-27 20:05:23 -05:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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)
device: fix assuming connections when platform-init arrives late When the NM_UNMANAGED_PLATFORM_INIT flag is cleared last in device_link_changed(), a recheck-assume is scheduled and then the device goes immediately to UNAVAILABLE. During the state transition, addresses and routes are removed from the interface. Then, recheck-assume finds that the device can be assumed but it's too late since the device was already deconfigured. This is a problem as the whole point of assuming a device is to activate a connection while leaving the device untouched. In the NMCI "dracut_NM_vlan_over_bridge and dracut_NM_vlan_over_bond" test, NM in real root tries to assume a vlan device that was activated in initrd. When the interface gets deconfigured in UNAVAILABLE, the connection to the NFS server breaks and the rootfs becomes inaccessible. The fix to this problem is to delay state transitions in device_link_changed() to a idle handler, so that recheck-assume can run before. Fixes-test: @dracut_NM_vlan_over_bridge Fixes-test: @dracut_NM_vlan_over_bond https://bugzilla.redhat.com/show_bug.cgi?id=2047302
2022-02-02 09:39:23 +01:00
nm_device_set_unmanaged_by_user_settings(device, TRUE);
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
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
_static_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
{
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);
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
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
static const RfkillTypeDesc _rfkill_type_desc[NM_RFKILL_TYPE_MAX] = {
[NM_RFKILL_TYPE_WLAN] =
{
.prop_id = PROP_WIRELESS_ENABLED,
.hw_prop_id = PROP_WIRELESS_HARDWARE_ENABLED,
.key = NM_CONFIG_STATE_PROPERTY_WIFI_ENABLED,
},
[NM_RFKILL_TYPE_WWAN] =
{
.prop_id = PROP_WWAN_ENABLED,
.hw_prop_id = PROP_WWAN_HARDWARE_ENABLED,
.key = NM_CONFIG_STATE_PROPERTY_WWAN_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/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_radio_state_get_enabled(const RfkillRadioState *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: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
/* If the device is not owned by the os, hw_enabled will be FALSE, hence
* we don't need to consider os_owner here.
*/
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
}
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
static void
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
_rfkill_radio_state_set_from_manager(NMManager *self, NMRfkillType rtype, RfkillRadioState *rstate)
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
{
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
NMDevice *device;
switch (nm_rfkill_manager_get_rfkill_state(priv->rfkill_mgr, rtype)) {
core: introduce "unavailable" rfkill state Introduce a new "unavailable" rfkill state to indicate that no rfkill hardware was found. Currently it is still handled as "unblocked".
2022-03-28 11:15:24 +02:00
case NM_RFKILL_STATE_UNAVAILABLE:
rstate->sw_enabled = TRUE;
rstate->hw_enabled = TRUE;
rstate->os_owner = TRUE;
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
/* A rfkill-type is available when there is a compatible
* killswitch or a compatible device. */
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
if (nm_device_get_rfkill_type(device) == rtype) {
rstate->available = TRUE;
return;
}
}
rstate->available = FALSE;
core: introduce "unavailable" rfkill state Introduce a new "unavailable" rfkill state to indicate that no rfkill hardware was found. Currently it is still handled as "unblocked".
2022-03-28 11:15:24 +02:00
return;
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
case NM_RFKILL_STATE_UNBLOCKED:
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
rstate->available = TRUE;
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
rstate->sw_enabled = TRUE;
rstate->hw_enabled = TRUE;
core: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
rstate->os_owner = TRUE;
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
return;
case NM_RFKILL_STATE_SOFT_BLOCKED:
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
rstate->available = TRUE;
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
rstate->sw_enabled = FALSE;
rstate->hw_enabled = TRUE;
core: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
rstate->os_owner = TRUE;
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
return;
case NM_RFKILL_STATE_HARD_BLOCKED:
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
rstate->available = TRUE;
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
rstate->sw_enabled = FALSE;
rstate->hw_enabled = FALSE;
core: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
/* In case the OS doesn't own the NIC, we would be in NM_RFKILL_STATE_HARD_BLOCKED */
rstate->os_owner = TRUE;
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
return;
rfkill: query the hardware rfkill reason from udev The kernel may add a reason for hardware rfkill. Make the NetworkManager able eto fetch it and parse it. For now, no action will be taken upon the new reasons. The different reasons that the kernel can expose are either the radio was switched off by a hardware rfkill switch. This reason is adveritsed by bit 0 in the bitmap returned by RFKILL_STATE_REASON udev property. This is the rfkill that existed until now. The new reason is mapped to bit 1 and teaches the user space that the wifi device is currently used by the CSME firmware on the platform. In that case, the NetworkManager can ask CSME (through the iwlmei kernel module) what BSSID the CSME firmware is associated to. Once the NetworkManager gets to the conclusion is has the credentials to connect to that very same AP, it can request the wifi device and the CSME firmware will allow the host to take the ownership on the device. CSME will give 3 seconds to the host to get an IP or it'll take the device back. In order to complete all the process until we get the DHCP ACK within 3 seconds, the NetworkManager will need to optimize the scan and limit the scan to that specific BSSID on that specific channel. All this flow is not implemented yet, but the first step is to identify that the device is not owned by the host.
2022-02-16 15:42:33 +02:00
case NM_RFKILL_STATE_HARD_BLOCKED_OS_NOT_OWNER:
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
rstate->available = TRUE;
rfkill: query the hardware rfkill reason from udev The kernel may add a reason for hardware rfkill. Make the NetworkManager able eto fetch it and parse it. For now, no action will be taken upon the new reasons. The different reasons that the kernel can expose are either the radio was switched off by a hardware rfkill switch. This reason is adveritsed by bit 0 in the bitmap returned by RFKILL_STATE_REASON udev property. This is the rfkill that existed until now. The new reason is mapped to bit 1 and teaches the user space that the wifi device is currently used by the CSME firmware on the platform. In that case, the NetworkManager can ask CSME (through the iwlmei kernel module) what BSSID the CSME firmware is associated to. Once the NetworkManager gets to the conclusion is has the credentials to connect to that very same AP, it can request the wifi device and the CSME firmware will allow the host to take the ownership on the device. CSME will give 3 seconds to the host to get an IP or it'll take the device back. In order to complete all the process until we get the DHCP ACK within 3 seconds, the NetworkManager will need to optimize the scan and limit the scan to that specific BSSID on that specific channel. All this flow is not implemented yet, but the first step is to identify that the device is not owned by the host.
2022-02-16 15:42:33 +02:00
rstate->sw_enabled = FALSE;
rstate->hw_enabled = FALSE;
core: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
rstate->os_owner = FALSE;
rfkill: query the hardware rfkill reason from udev The kernel may add a reason for hardware rfkill. Make the NetworkManager able eto fetch it and parse it. For now, no action will be taken upon the new reasons. The different reasons that the kernel can expose are either the radio was switched off by a hardware rfkill switch. This reason is adveritsed by bit 0 in the bitmap returned by RFKILL_STATE_REASON udev property. This is the rfkill that existed until now. The new reason is mapped to bit 1 and teaches the user space that the wifi device is currently used by the CSME firmware on the platform. In that case, the NetworkManager can ask CSME (through the iwlmei kernel module) what BSSID the CSME firmware is associated to. Once the NetworkManager gets to the conclusion is has the credentials to connect to that very same AP, it can request the wifi device and the CSME firmware will allow the host to take the ownership on the device. CSME will give 3 seconds to the host to get an IP or it'll take the device back. In order to complete all the process until we get the DHCP ACK within 3 seconds, the NetworkManager will need to optimize the scan and limit the scan to that specific BSSID on that specific channel. All this flow is not implemented yet, but the first step is to identify that the device is not owned by the host.
2022-02-16 15:42:33 +02:00
return;
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
}
nm_assert_not_reached();
}
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/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_radio_state_get(NMManager *self, NMRfkillType rtype)
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/rfkill: cleanup rfkill handling in NMManager - use "const RadioState" where possible - use "bool" bitfields in RadioState (boolean flags in structs should be `bool` types for consistency) and order fields by alignment. - break lines for variable declaration in manager_rfkill_update_one_type(). - return (and nm_assert()) from update_rstate_from_rfkill(). By not adding a default case, compiler would warn if we forget to handle an enum value. We can easily do that, by just returning, and let the "default" case be handled by nm_assert_not_reached() -- which unlike g_warn_if_reached() compiles to nothing in release build. - add nm_assert() that `priv->radio_states[rtype]` is not out of range. - use designated initializers for priv->radio_states[].
2022-02-01 20:07:18 +01:00
nm_assert(_NM_INT_NOT_NEGATIVE(rtype) && rtype < G_N_ELEMENTS(priv->radio_states));
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
return _rfkill_radio_state_get_enabled(&priv->radio_states[rtype], 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
}
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
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update_devices(NMManager *self, NMRfkillType rtype, 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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
_notify(self, _rfkill_type_desc[rtype].prop_id);
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/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
if (nm_device_get_rfkill_type(device) == 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
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update_one_type(NMManager *self, NMRfkillType 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
{
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
RfkillRadioState *rstate = &priv->radio_states[rtype];
core/rfkill: cleanup rfkill handling in NMManager - use "const RadioState" where possible - use "bool" bitfields in RadioState (boolean flags in structs should be `bool` types for consistency) and order fields by alignment. - break lines for variable declaration in manager_rfkill_update_one_type(). - return (and nm_assert()) from update_rstate_from_rfkill(). By not adding a default case, compiler would warn if we forget to handle an enum value. We can easily do that, by just returning, and let the "default" case be handled by nm_assert_not_reached() -- which unlike g_warn_if_reached() compiles to nothing in release build. - add nm_assert() that `priv->radio_states[rtype]` is not out of range. - use designated initializers for priv->radio_states[].
2022-02-01 20:07:18 +01:00
gboolean old_enabled;
gboolean new_enabled;
gboolean old_rfkilled;
gboolean new_rfkilled;
gboolean old_hwe;
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
guint old_radio_flags;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
nm_assert(_NM_INT_NOT_NEGATIVE(rtype) && rtype < G_N_ELEMENTS(priv->radio_states));
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
old_enabled = _rfkill_radio_state_get_enabled(rstate, TRUE);
old_rfkilled = rstate->hw_enabled && rstate->sw_enabled;
old_hwe = rstate->hw_enabled;
old_radio_flags = priv->radio_flags;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 */
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
_rfkill_radio_state_set_from_manager(self, rtype, rstate);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 */
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
_LOGD(LOGD_RFKILL,
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
"rfkill: %s available %d hw-enabled %d sw-enabled %d os-owner %d",
core/rfkill: add nm_rfkill_type_to_string() helper
2022-02-01 22:32:46 +01:00
nm_rfkill_type_to_string(rtype),
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
rstate->available,
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
rstate->hw_enabled,
core: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
rstate->sw_enabled,
rstate->os_owner);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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",
core/rfkill: add nm_rfkill_type_to_string() helper
2022-02-01 22:32:46 +01:00
nm_rfkill_type_to_string(rtype),
manager: use logging helpers
2016-03-02 11:38:26 +01:00
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
priv->radio_flags = NM_FLAGS_ASSIGN(priv->radio_flags,
(guint) nm_rfkill_type_to_radio_available_flag(rtype),
rstate->available);
/* Send out property changed signal for HW available and enabled */
nm_gobject_notify_together(self,
rstate->hw_enabled != old_hwe ? _rfkill_type_desc[rtype].hw_prop_id
: PROP_0,
priv->radio_flags != old_radio_flags ? PROP_RADIO_FLAGS : PROP_0);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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.
*/
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
new_enabled = _rfkill_radio_state_get_enabled(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)
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update_devices(self, rtype, 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
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update(NMManager *self, NMRfkillType rtype)
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
{
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
guint i;
manager: generalize rfkill operations So it's easier to support other killswitches like WWAN and WiMAX.
2009-12-23 00:03:45 -08:00
core/rfkill: add "nm" prefix to RfKillState and RfKillType enums Names in header files should have an "nm" prefix. We do that pretty consistently. Fix the offenders RfKillState and RfKillType. Also, rename the RfKillState enums to follow the type name. For example, NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED. Also, when we camel-case a typedef (NMRfKillState) we would want that the lower-case names use underscore between the words. So it should be `nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution here is to also rename "RfKill" to "Rfkill". That make is consistent with the spelling of the existing `NMRfkillManager` type and the `nm-rfkill-manager.h` file.
2022-02-01 20:21:34 +01:00
if (rtype != NM_RFKILL_TYPE_UNKNOWN)
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update_one_type(self, 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 {
all: fix typo in man pages There should be a comma after 'Otherwise' and 'Currently'. https://bugzilla.redhat.com/show_bug.cgi?id=1852452 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/560
2020-07-01 17:20:40 -04:00
/* Otherwise, sync all radio types */
core/rfkill: add "nm" prefix to RfKillState and RfKillType enums Names in header files should have an "nm" prefix. We do that pretty consistently. Fix the offenders RfKillState and RfKillType. Also, rename the RfKillState enums to follow the type name. For example, NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED. Also, when we camel-case a typedef (NMRfKillState) we would want that the lower-case names use underscore between the words. So it should be `nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution here is to also rename "RfKill" to "Rfkill". That make is consistent with the spelling of the existing `NMRfkillManager` type and the `nm-rfkill-manager.h` file.
2022-02-01 20:21:34 +01:00
for (i = 0; i < NM_RFKILL_TYPE_MAX; i++)
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update_one_type(self, 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/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
/*****************************************************************************/
#define KERN_RFKILL_OP_CHANGE_ALL 3
#define KERN_RFKILL_TYPE_WLAN 1
#define KERN_RFKILL_TYPE_WWAN 5
struct rfkill_event {
uint32_t idx;
uint8_t type;
uint8_t op;
uint8_t soft;
uint8_t hard;
} _nm_packed;
static void
_rfkill_update_system(NMManager *self, NMRfkillType rtype, gboolean enabled)
{
core/rfkill: use "nm_auto_close" in _rfkill_update_system() to close FD
2022-02-01 22:24:45 +01:00
nm_auto_close int fd = -1;
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
struct rfkill_event event;
ssize_t len;
int errsv;
nm_assert(NM_IN_SET(rtype, NM_RFKILL_TYPE_WLAN, NM_RFKILL_TYPE_WWAN));
fd = open("/dev/rfkill", O_RDWR | O_CLOEXEC);
if (fd < 0) {
if (errno == EACCES)
_LOGW(LOGD_RFKILL,
"rfkill: (%s): failed to open killswitch device",
core/rfkill: add nm_rfkill_type_to_string() helper
2022-02-01 22:32:46 +01:00
nm_rfkill_type_to_string(rtype));
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
return;
}
if (fcntl(fd, F_SETFL, O_NONBLOCK) < 0) {
_LOGW(LOGD_RFKILL,
"rfkill: (%s): failed to set killswitch device for "
"non-blocking operation",
core/rfkill: add nm_rfkill_type_to_string() helper
2022-02-01 22:32:46 +01:00
nm_rfkill_type_to_string(rtype));
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
return;
}
memset(&event, 0, sizeof(event));
event.op = KERN_RFKILL_OP_CHANGE_ALL;
switch (rtype) {
case NM_RFKILL_TYPE_WLAN:
event.type = KERN_RFKILL_TYPE_WLAN;
break;
case NM_RFKILL_TYPE_WWAN:
event.type = KERN_RFKILL_TYPE_WWAN;
break;
default:
nm_assert_not_reached();
}
event.soft = enabled ? 0 : 1;
len = write(fd, &event, sizeof(event));
if (len < 0) {
errsv = errno;
_LOGW(LOGD_RFKILL,
"rfkill: (%s): failed to change Wi-Fi killswitch state: (%d) %s",
core/rfkill: add nm_rfkill_type_to_string() helper
2022-02-01 22:32:46 +01:00
nm_rfkill_type_to_string(rtype),
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
errsv,
nm_strerror_native(errsv));
} else if (len == sizeof(event)) {
_LOGI(LOGD_RFKILL,
"rfkill: %s hardware radio set %s",
core/rfkill: add nm_rfkill_type_to_string() helper
2022-02-01 22:32:46 +01:00
nm_rfkill_type_to_string(rtype),
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
enabled ? "enabled" : "disabled");
} else {
/* Failed to write full structure */
_LOGW(LOGD_RFKILL,
"rfkill: (%s): failed to change Wi-Fi killswitch state",
core/rfkill: add nm_rfkill_type_to_string() helper
2022-02-01 22:32:46 +01:00
nm_rfkill_type_to_string(rtype));
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
}
}
static void
_rfkill_update_from_user(NMManager *self, NMRfkillType rtype, gboolean enabled)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
RfkillRadioState *rstate = &priv->radio_states[rtype];
gboolean old_enabled, new_enabled;
/* Don't touch devices if asleep/networking disabled */
if (manager_sleeping(self))
return;
_LOGD(LOGD_RFKILL,
"rfkill: (%s): setting radio %s by user",
core/rfkill: add nm_rfkill_type_to_string() helper
2022-02-01 22:32:46 +01:00
nm_rfkill_type_to_string(rtype),
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
enabled ? "enabled" : "disabled");
/* Update enabled key in state file */
nm_config_state_set(priv->config, TRUE, FALSE, _rfkill_type_desc[rtype].key, enabled);
/* 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 = _rfkill_radio_state_get_enabled(rstate, TRUE);
rstate->user_enabled = enabled;
new_enabled = _rfkill_radio_state_get_enabled(rstate, FALSE);
if (new_enabled != old_enabled) {
/* Try to change the kernel rfkill state */
_rfkill_update_system(self, rtype, new_enabled);
_rfkill_update_devices(self, rtype, new_enabled);
}
}
/*****************************************************************************/
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, GDBusMethodInvocation *context, gpointer user_data)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(user_data);
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *device;
GCancellable *cancellable;
const char *permission;
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
NMManagerDeviceAuthRequestFunc callback;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMAuthSubject *subject;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
cancellable = nm_auth_chain_get_cancellable(chain);
nm_assert(!cancellable || G_IS_CANCELLABLE(cancellable));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
if (cancellable && g_cancellable_set_error_if_cancelled(cancellable, &error)) {
/* pass. */
} else {
if (result != NM_AUTH_CALL_RESULT_YES) {
_LOGD(LOGD_CORE, "%s request failed: not authorized", permission);
error = g_error_new(NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
"%s request failed: not authorized",
permission);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
nm_assert(error || (result == NM_AUTH_CALL_RESULT_YES));
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
callback(device, context, subject, error, nm_auth_chain_get_data(chain, "user-data"));
}
static void
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
_device_auth_done_fail_on_idle(gpointer user_data, GCancellable *cancellable)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_unref_object NMManager *self = NULL;
gs_unref_object NMDevice *device = NULL;
gs_unref_object GDBusMethodInvocation *context = NULL;
gs_unref_object NMAuthSubject *subject = NULL;
gs_free_error GError *error_original = NULL;
gs_free_error GError *error_cancelled = NULL;
NMManagerDeviceAuthRequestFunc callback;
gpointer callback_user_data;
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
manager: fix very bad usage of 'nm_utils_user_data_unpack' This results in the args of 'nm_utils_user_data_unpack' containing random data potentially also from the previous stack-frame which is really really bad. Signed-off-by: Antonio Cardace <acardace@redhat.com> Fixes: b50702775f1b ('device: implement auth-request as async operation nm_manager_device_auth_request()')
2020-10-22 14:40:15 +02:00
nm_utils_user_data_unpack(user_data,
&self,
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
&device,
&context,
&subject,
&error_original,
&callback,
&callback_user_data);
g_cancellable_set_error_if_cancelled(cancellable, &error_cancelled);
callback(device, context, subject, error_cancelled ?: error_original, callback_user_data);
}
void
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
nm_manager_device_auth_request(NMManager *self,
NMDevice *device,
GDBusMethodInvocation *context,
NMConnection *connection,
const char *permission,
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
gboolean allow_interaction,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GCancellable *cancellable,
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
NMManagerDeviceAuthRequestFunc callback,
gpointer user_data)
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
gs_free_error GError *error = NULL;
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
gs_unref_object NMAuthSubject *subject = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMAuthChain *chain;
char *permission_dup;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 */
shared: move nm-dbus-auth-subject to shared/nm-libnm-core-intern Move it to shared as it's useful for clients as well. Move and rename nm_dbus_manager_new_auth_subject_from_context() and nm_dbus_manager_new_auth_subject_from_message() in nm-dbus-manager.c as they're needed there.
2019-12-19 11:30:38 +01:00
subject = nm_dbus_manager_new_auth_subject_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) {
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
g_set_error_literal(&error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_PERMISSION_DENIED,
NM_UTILS_ERROR_MSG_REQ_UID_UKNOWN);
goto fail_on_idle;
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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))
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
goto fail_on_idle;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
chain = nm_auth_chain_new_subject(subject, context, device_auth_done_cb, self);
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
if (cancellable)
nm_auth_chain_set_cancellable(chain, cancellable);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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);
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
return;
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
device: implement "auth-request" as async operation nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
2020-04-26 13:59:13 +02:00
fail_on_idle:
nm_utils_invoke_on_idle(cancellable,
_device_auth_done_fail_on_idle,
nm_utils_user_data_pack(g_object_ref(self),
g_object_ref(device),
g_object_ref(context),
g_steal_pointer(&subject),
g_steal_pointer(&error),
callback,
user_data));
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,
manager: fix active_connection_find() Commit 33b9fa3a3caf ("manager: Keep volatile/external connections while referenced by async_op_lst") changed active_connection_find() to also return active connections that are not yet activating but are waiting authorization. This has side effect for other callers of the function. In particular, _get_activatable_connections_filter() should exclude only ACs that are really active, not those waiting for authorization. Otherwise, in ensure_master_active_connection() all the ACs waiting authorization are missed and we might fail to find the right master AC. Add an argument to active_connection_find to select whether include ACs waiting authorization. Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1955101
2021-05-13 10:49:39 +02:00
FALSE,
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
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSettingsConnection *added;
GError *error = NULL;
gs_free_error GError *gen_error = NULL;
NMDevice *master = NULL;
int ifindex = nm_device_get_ifindex(device);
NMSettingsConnection *matched = NULL;
NMSettingsConnection *connection_checked = NULL;
gboolean assume_state_guess_assume = FALSE;
const char *assume_state_connection_uuid = NULL;
gboolean maybe_later, only_by_uuid = FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: exit early in get_existing_connection() Later the function will become more complex. Add a check to exit early if the device can't assume connections.
2021-06-07 16:31:18 +02:00
if (!nm_device_can_assume_connections(device)) {
nm_device_assume_state_reset(device);
_LOG2D(LOGD_DEVICE, device, "assume: device cannot assume connection");
return 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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
ovs, dpdk: ignore ovs-netdev tun interface When configuring a OVS bridge to use the netdev datapath, OpenvSwitch will create a tun interface named ovs-netdev. This interface should be ignored by NetworkManager. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1169
2022-03-30 16:06:38 +02:00
* slave connection. However, ignore ovs-system/ovs-netdev master as
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
* 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;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
core: add 'keep-configuration' device configuration option Add a new 'keep-configuration' device option, set to 'yes' by default. When set to 'no', on startup NetworkManager ignores that the interface is pre-configured and doesn't try to keep its configuration. Instead, it activates one of the persistent connections.
2021-05-07 13:57:04 +02:00
if (nm_config_data_get_device_config_boolean(NM_CONFIG_GET_DATA,
NM_CONFIG_KEYFILE_KEY_DEVICE_KEEP_CONFIGURATION,
device,
TRUE,
TRUE)) {
/* The core of the API is nm_device_generate_connection() function, based on
* update_connection() virtual method and the @connection_type_supported
* class attribute. Devices that support assuming existing connections must
* have update_connection() implemented, otherwise
* nm_device_generate_connection() returns NULL. */
connection = nm_device_generate_connection(device, master, &maybe_later, &gen_error);
if (!connection) {
if (maybe_later) {
/* The device can potentially assume connections, but at this
* time we can't generate a connection because no address is
* configured. Allow the device to assume a connection indicated
* in the state file by UUID. */
only_by_uuid = TRUE;
} else {
nm_device_assume_state_reset(device);
_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
}
core: add 'keep-configuration' device configuration option Add a new 'keep-configuration' device option, set to 'yes' by default. When set to 'no', on startup NetworkManager ignores that the interface is pre-configured and doesn't try to keep its configuration. Instead, it activates one of the persistent connections.
2021-05-07 13:57:04 +02:00
} else {
connection = NULL;
only_by_uuid = TRUE;
g_set_error(&gen_error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_FAILED,
"device %s has 'keep-configuration=no'",
nm_device_get_iface(device));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: add comments about assuming connections
2021-05-07 10:13:26 +02:00
/* If the device state file indicates a connection that was active before NM
* restarted, perform basic sanity checks on it. */
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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 (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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: add comments about assuming connections
2021-05-07 10:13:26 +02:00
/* @assume_state_guess_assume=TRUE means this is the first start of NM
* and the state file contains no UUID. Search 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];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMConnection *con;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
g_qsort_with_data(sett_conns,
len,
sizeof(sett_conns[0]),
nm_settings_connection_cmp_timestamp_p_with_data,
NULL);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
conns = nm_settings_connections_array_to_connections(sett_conns, len);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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(matched);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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) {
core: fix taking over external connection after restart When we restart the daemon, it would find the previously present external connection and assume it. We need to keep it as external.
2020-06-09 09:10:53 +02:00
if (NM_FLAGS_HAS(nm_settings_connection_get_flags(matched),
NM_SETTINGS_CONNECTION_INT_FLAGS_EXTERNAL)) {
_LOG2D(LOGD_DEVICE,
device,
"assume: take over previous connection '%s' (%s)",
nm_settings_connection_get_id(matched),
nm_settings_connection_get_uuid(matched));
NM_SET_OUT(out_generated, TRUE);
} else {
_LOG2I(LOGD_DEVICE,
device,
"assume: will attempt to assume matching connection '%s' (%s)%s",
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: add comments about assuming connections
2021-05-07 10:13:26 +02:00
/* When no configured connection matches the generated connection, we keep
* the generated connection instead. */
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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_add_connection(priv->settings,
settings: add "plugin" argument to AddAndActivate2() This will confine a newly added connection to a particular settings plugin.
2022-03-14 10:20:11 +01:00
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
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,
core: add "external" flag for connections of external devices When a device is not marked as unmanaged, but also not actively managed by NetworkManager, then NetworkManager will generate an in-memory profile to represent the active state, if the device is up and configured (with an IP address). Such profiles are commonly named like "eth0", and they are utterly confusing to users, because they look as if NetworkManager actually manages the device, when it really just shows that somebody else configures the device. We should express this better in the UI, hence add flags to indicate that. In practice, such profiles are UNSAVED, NM_GENERATED, and VOLATILE. But add an explicit flag to represent that. https://bugzilla.redhat.com/show_bug.cgi?id=1816202
2020-06-08 19:34:50 +02:00
NM_SETTINGS_CONNECTION_INT_FLAGS_NM_GENERATED
| NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE
| NM_SETTINGS_CONNECTION_INT_FLAGS_EXTERNAL,
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
&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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
}
nm-manager: fix selinux label for dhclient lease file from initramfs When moving a lease file from initramfs directory to NetworkManager run directory, SELinux label for that file retains tmpfs_t type. Fix it by using sendfile() instead of rename(). That way, the lease file will have the default type: NetworkManager_var_run_t. Since we take ownership of the lease file, also drop it from the old location. * Before the patch: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease * After: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
2019-12-03 19:00:42 +03:00
static gboolean
copy_lease(const char *src, const char *dst)
{
nm-manager: remove lease file if copying dhclient lease fails - also use nm_auto_close and nm_close().
2019-12-10 14:58:29 +01:00
nm_auto_close int src_fd = -1;
int dst_fd;
nm-manager: restore passing correct size to sendfile in copy_lease() Otherwise sendfile() fails with EINVAL when the file offset is greater than zero (pos + size > max), always on the second iteration. Fixes: 0c6cd07ec81d ('nm-manager: remove lease file if copying dhclient lease fails') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/359
2019-12-11 18:55:07 +03:00
ssize_t res, size = SSIZE_MAX;
nm-manager: fix selinux label for dhclient lease file from initramfs When moving a lease file from initramfs directory to NetworkManager run directory, SELinux label for that file retains tmpfs_t type. Fix it by using sendfile() instead of rename(). That way, the lease file will have the default type: NetworkManager_var_run_t. Since we take ownership of the lease file, also drop it from the old location. * Before the patch: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease * After: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
2019-12-03 19:00:42 +03:00
src_fd = open(src, O_RDONLY | O_CLOEXEC);
if (src_fd < 0)
return FALSE;
dst_fd = open(dst, O_CREAT | O_EXCL | O_CLOEXEC | O_WRONLY, 0644);
nm-manager: remove lease file if copying dhclient lease fails - also use nm_auto_close and nm_close().
2019-12-10 14:58:29 +01:00
if (dst_fd < 0)
nm-manager: fix selinux label for dhclient lease file from initramfs When moving a lease file from initramfs directory to NetworkManager run directory, SELinux label for that file retains tmpfs_t type. Fix it by using sendfile() instead of rename(). That way, the lease file will have the default type: NetworkManager_var_run_t. Since we take ownership of the lease file, also drop it from the old location. * Before the patch: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease * After: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
2019-12-03 19:00:42 +03:00
return FALSE;
nm-manager: remove lease file if copying dhclient lease fails - also use nm_auto_close and nm_close().
2019-12-10 14:58:29 +01:00
nm-manager: restore passing correct size to sendfile in copy_lease() Otherwise sendfile() fails with EINVAL when the file offset is greater than zero (pos + size > max), always on the second iteration. Fixes: 0c6cd07ec81d ('nm-manager: remove lease file if copying dhclient lease fails') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/359
2019-12-11 18:55:07 +03:00
while ((res = sendfile(dst_fd, src_fd, NULL, size)) > 0)
size -= res;
nm-manager: fix selinux label for dhclient lease file from initramfs When moving a lease file from initramfs directory to NetworkManager run directory, SELinux label for that file retains tmpfs_t type. Fix it by using sendfile() instead of rename(). That way, the lease file will have the default type: NetworkManager_var_run_t. Since we take ownership of the lease file, also drop it from the old location. * Before the patch: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease * After: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
2019-12-03 19:00:42 +03:00
nm-manager: remove lease file if copying dhclient lease fails - also use nm_auto_close and nm_close().
2019-12-10 14:58:29 +01:00
nm_close(dst_fd);
nm-manager: fix selinux label for dhclient lease file from initramfs When moving a lease file from initramfs directory to NetworkManager run directory, SELinux label for that file retains tmpfs_t type. Fix it by using sendfile() instead of rename(). That way, the lease file will have the default type: NetworkManager_var_run_t. Since we take ownership of the lease file, also drop it from the old location. * Before the patch: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease * After: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
2019-12-03 19:00:42 +03:00
nm-manager: remove lease file if copying dhclient lease fails - also use nm_auto_close and nm_close().
2019-12-10 14:58:29 +01:00
if (res != 0) {
unlink(dst);
return FALSE;
}
nm-manager: fix selinux label for dhclient lease file from initramfs When moving a lease file from initramfs directory to NetworkManager run directory, SELinux label for that file retains tmpfs_t type. Fix it by using sendfile() instead of rename(). That way, the lease file will have the default type: NetworkManager_var_run_t. Since we take ownership of the lease file, also drop it from the old location. * Before the patch: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease * After: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
2019-12-03 19:00:42 +03:00
nm-manager: remove lease file if copying dhclient lease fails - also use nm_auto_close and nm_close().
2019-12-10 14:58:29 +01:00
return TRUE;
nm-manager: fix selinux label for dhclient lease file from initramfs When moving a lease file from initramfs directory to NetworkManager run directory, SELinux label for that file retains tmpfs_t type. Fix it by using sendfile() instead of rename(). That way, the lease file will have the default type: NetworkManager_var_run_t. Since we take ownership of the lease file, also drop it from the old location. * Before the patch: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease * After: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
2019-12-03 19:00:42 +03: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, 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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
if (!nm_device_get_managed(device, FALSE)) {
device: remove the possibility of inheriting the unmanaged condition from the parent of a device This commit is part of a broader change that eliminates inheriting the unmanaged condition from the parent of a device, for all device types: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1418 What motivates this change are the unncessary issues brought by this inheritance. You can see some problems described here: https://bugzilla.redhat.com/show_bug.cgi?id=2110307#c0.
2022-10-12 19:26:27 +02:00
/* If the device is unmanaged by NM_UNMANAGED_PLATFORM_INIT,
core: don't reset assume state too early If the device is still unmanaged by platform-init (which means that udev didn't emit the event for the interface) when the device gets realized, we currently clear the assume state. Later, when the device becomes managed, NM is not able to properly assume the device using the UUID. This situation arises, for example, when NM already configured the device in initrd; after NM is restarted in the real root, udev events can be delayed causing this race condition. Among all unamanaged flags, platform-init is the only one that can be delayed externally. We should not clear the assume state if the device has only platform-init in the unmanaged flags.
2021-05-11 14:44:20 +02:00
* don't reset the state now but wait until it becomes managed. */
device: remove the possibility of inheriting the unmanaged condition from the parent of a device This commit is part of a broader change that eliminates inheriting the unmanaged condition from the parent of a device, for all device types: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1418 What motivates this change are the unncessary issues brought by this inheritance. You can see some problems described here: https://bugzilla.redhat.com/show_bug.cgi?id=2110307#c0.
2022-10-12 19:26:27 +02:00
if (nm_device_get_unmanaged_flags(device, NM_UNMANAGED_ALL) & ~NM_UNMANAGED_PLATFORM_INIT)
core: don't reset assume state too early If the device is still unmanaged by platform-init (which means that udev didn't emit the event for the interface) when the device gets realized, we currently clear the assume state. Later, when the device becomes managed, NM is not able to properly assume the device using the UUID. This situation arises, for example, when NM already configured the device in initrd; after NM is restarted in the real root, udev events can be delayed causing this race condition. Among all unamanaged flags, platform-init is the only one that can be delayed externally. We should not clear the assume state if the device has only platform-init in the unmanaged flags.
2021-05-11 14:44:20 +02:00
nm_device_assume_state_reset(device);
manager: drop useless use of a format string https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1355
2022-08-30 13:41:36 +02:00
_LOG2D(LOGD_DEVICE, device, "assume: don't assume because device is 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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) {
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",
core: rename to_str() methods to to_string() It's more common to name the to-string method *_to_string(). Rename.
2021-08-09 14:54:17 +02:00
nm_device_state_to_string(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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
activation_type_assume = !generated;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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 (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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
nm-manager: fix selinux label for dhclient lease file from initramfs When moving a lease file from initramfs directory to NetworkManager run directory, SELinux label for that file retains tmpfs_t type. Fix it by using sendfile() instead of rename(). That way, the lease file will have the default type: NetworkManager_var_run_t. Since we take ownership of the lease file, also drop it from the old location. * Before the patch: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease * After: ls -Z /var/run/NetworkManager/dhclient-*.lease system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
2019-12-03 19:00:42 +03:00
if (copy_lease(initramfs_lease, connection_lease)) {
unlink(initramfs_lease);
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
/*
* 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.
all: fix typo in man pages There should be a comma after 'Otherwise' and 'Currently'. https://bugzilla.redhat.com/show_bug.cgi?id=1852452 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/560
2020-07-01 17:20:40 -04:00
* Otherwise, the address would just expire.
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
*/
_LOG2I(LOGD_DEVICE, device, "assume: taking over an initramfs-configured connection");
activation_type_assume = TRUE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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) {
core: fix modifying connection during recheck_assume_connection() Since commit d35d3c468a30 ('settings: rework tracking settings connections and settings plugins') must settings connections not be modified. They must be treated immutable and only updated by replacing them with a new variant. There is even an assertion for that. Fix the code that attempts to modify an existing NMConnection. https://bugzilla.redhat.com/show_bug.cgi?id=1900536 Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/690
2020-11-23 16:04:35 +01:00
gs_unref_object NMConnection *con2 = NULL;
con2 = nm_simple_connection_new_clone(
nm_settings_connection_get_connection(sett_conn));
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. */
core: fix modifying connection during recheck_assume_connection() Since commit d35d3c468a30 ('settings: rework tracking settings connections and settings plugins') must settings connections not be modified. They must be treated immutable and only updated by replacing them with a new variant. There is even an assertion for that. Fix the code that attempts to modify an existing NMConnection. https://bugzilla.redhat.com/show_bug.cgi?id=1900536 Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/690
2020-11-23 16:04:35 +01:00
nm_connection_add_setting(con2,
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
g_object_new(NM_TYPE_SETTING_IP4_CONFIG,
NM_SETTING_IP_CONFIG_METHOD,
NM_SETTING_IP4_CONFIG_METHOD_AUTO,
NULL));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
settings: add NM_SETTINGS_CONNECTION_UPDATE_REASON_UPDATE_NON_SECRET flag Along with NM_SETTINGS_CONNECTION_UPDATE_REASON_RESET_SYSTEM_SECRETS and NM_SETTINGS_CONNECTION_UPDATE_REASON_RESET_AGENT_SECRETS, which can be used in the NMSettingConnection's "updated" handlers to track secrets updates, add NM_SETTINGS_CONNECTION_UPDATE_REASON_UPDATE_NON_SECRET so that the handlers can tell when something other than secrets has been updated in the connection. It can also potentially be used in _connection_changed_update in src/core/settings/nm-settings.c to stop emitting the NetworkManager.Settings.Connection.Updated() dbus signal if only secrets are being updated (on agent queries etc.) if it is deemed to be correct.
2021-04-03 17:32:06 +02:00
nm_settings_connection_update(
sett_conn,
settings-connection: add a "plugin" argument to Update2() This will allow migrating a connection. If specified, the connection will be confined to a particular settings plugin when written back. If the plugin differs from the existing one, it will be removed from the old one.
2022-03-14 10:20:12 +01:00
NULL,
settings: add NM_SETTINGS_CONNECTION_UPDATE_REASON_UPDATE_NON_SECRET flag Along with NM_SETTINGS_CONNECTION_UPDATE_REASON_RESET_SYSTEM_SECRETS and NM_SETTINGS_CONNECTION_UPDATE_REASON_RESET_AGENT_SECRETS, which can be used in the NMSettingConnection's "updated" handlers to track secrets updates, add NM_SETTINGS_CONNECTION_UPDATE_REASON_UPDATE_NON_SECRET so that the handlers can tell when something other than secrets has been updated in the connection. It can also potentially be used in _connection_changed_update in src/core/settings/nm-settings.c to stop emitting the NetworkManager.Settings.Connection.Updated() dbus signal if only secrets are being updated (on agent queries etc.) if it is deemed to be correct.
2021-04-03 17:32:06 +02:00
con2,
NM_SETTINGS_CONNECTION_PERSIST_MODE_KEEP,
NM_SETTINGS_CONNECTION_INT_FLAGS_NONE,
NM_SETTINGS_CONNECTION_INT_FLAGS_VOLATILE
| NM_SETTINGS_CONNECTION_INT_FLAGS_EXTERNAL,
NM_SETTINGS_CONNECTION_UPDATE_REASON_UPDATE_NON_SECRET,
"assume-initrd",
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
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
g_return_val_if_fail(nm_device_get_state(device) >= NM_DEVICE_STATE_DISCONNECTED, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_unref_object NMActiveConnection *active = NULL;
gs_unref_object NMAuthSubject *subject = NULL;
NMActiveConnection *master_ac;
GError *error = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
subject = nm_auth_subject_new_internal();
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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,
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,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
if (was_unmanaged) {
nm_device_state_changed(device,
NM_DEVICE_STATE_UNAVAILABLE,
NM_DEVICE_STATE_REASON_CONFIG_FAILED);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
&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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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: use nm_streq*() instead of strcmp() in "nm-device.c" and "nm-manager.c"
2020-07-20 09:31:03 +02:00
if (candidate != device && nm_streq0(nm_device_get_iface(candidate), ip_iface)
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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));
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 = NM_CONNECTIVITY_UNKNOWN;
best_metric = G_MAXINT64;
c_list_for_each_entry (dev, &priv->devices_lst_head, devices_lst) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMPObject *r;
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 state;
gint64 metric;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
r = nm_device_get_best_default_route(dev, addr_family);
core: fix treating route metric zero of IPv6 routes special Userspace cannot add IPv6 routes with metric 0. Trying to do that, will be coerced by kernel to route metric 1024. For IPv4 this is different, and metric zero is commonly allowed. However, kernel itself can add IPv6 routes with metric zero: # ip -6 route show table local local fe80::2029:c7ff:fec9:698a dev v proto kernel metric 0 pref medium That means, we must not treat route metric zero special for most cases. Only, when we want to add routes (based on user configuration), we must coerce a route metric of zero to 1024. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/563
2020-07-03 15:25:51 +02:00
if (r)
metric = NMP_OBJECT_CAST_IP_ROUTE(r)->metric;
else {
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
/* 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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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: 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, 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)) {
device: remove the possibility of inheriting the unmanaged condition from the parent of a device This commit is part of a broader change that eliminates inheriting the unmanaged condition from the parent of a device, for all device types: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1418 What motivates this change are the unncessary issues brought by this inheritance. You can see some problems described here: https://bugzilla.redhat.com/show_bug.cgi?id=2110307#c0.
2022-10-12 19:26:27 +02:00
/* If the device is unmanaged by NM_UNMANAGED_PLATFORM_INIT,
core: don't reset assume state too early If the device is still unmanaged by platform-init (which means that udev didn't emit the event for the interface) when the device gets realized, we currently clear the assume state. Later, when the device becomes managed, NM is not able to properly assume the device using the UUID. This situation arises, for example, when NM already configured the device in initrd; after NM is restarted in the real root, udev events can be delayed causing this race condition. Among all unamanaged flags, platform-init is the only one that can be delayed externally. We should not clear the assume state if the device has only platform-init in the unmanaged flags.
2021-05-11 14:44:20 +02:00
* don't reset the state now but wait until it becomes managed. */
device: remove the possibility of inheriting the unmanaged condition from the parent of a device This commit is part of a broader change that eliminates inheriting the unmanaged condition from the parent of a device, for all device types: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1418 What motivates this change are the unncessary issues brought by this inheritance. You can see some problems described here: https://bugzilla.redhat.com/show_bug.cgi?id=2110307#c0.
2022-10-12 19:26:27 +02:00
if (nm_device_get_unmanaged_flags(device, NM_UNMANAGED_ALL) & ~NM_UNMANAGED_PLATFORM_INIT)
core: don't reset assume state too early If the device is still unmanaged by platform-init (which means that udev didn't emit the event for the interface) when the device gets realized, we currently clear the assume state. Later, when the device becomes managed, NM is not able to properly assume the device using the UUID. This situation arises, for example, when NM already configured the device in initrd; after NM is restarted in the real root, udev events can be delayed causing this race condition. Among all unamanaged flags, platform-init is the only one that can be delayed externally. We should not clear the assume state if the device has only platform-init in the unmanaged flags.
2021-05-11 14:44:20 +02:00
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *iface, *type_desc;
core/rfkill: add "nm" prefix to RfKillState and RfKillType enums Names in header files should have an "nm" prefix. We do that pretty consistently. Fix the offenders RfKillState and RfKillType. Also, rename the RfKillState enums to follow the type name. For example, NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED. Also, when we camel-case a typedef (NMRfKillState) we would want that the lower-case names use underscore between the words. So it should be `nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution here is to also rename "RfKill" to "Rfkill". That make is consistent with the spelling of the existing `NMRfkillManager` type and the `nm-rfkill-manager.h` file.
2022-02-01 20:21:34 +01:00
NMRfkillType rtype;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *dbus_path;
NMDevice *candidate;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
nm_assert(c_list_is_empty(&device->devices_lst));
c_list_link_tail(&priv->devices_lst_head, &device->devices_lst);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
g_signal_connect(device, NM_DEVICE_REMOVED, G_CALLBACK(device_removed_cb), self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
g_signal_connect_data(device,
NM_DEVICE_RECHECK_ASSUME,
G_CALLBACK(recheck_assume_connection_cb),
self,
NULL,
G_CONNECT_SWAPPED);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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,
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
"notify::" NM_DEVICE_IP_IFACE,
G_CALLBACK(device_ip_iface_changed),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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,
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
"notify::" NM_DEVICE_IFINDEX,
G_CALLBACK(device_ifindex_changed),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
g_signal_connect(device, "notify::" NM_DEVICE_IFACE, G_CALLBACK(device_iface_changed), self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
g_signal_connect(device, "notify::" NM_DEVICE_REAL, G_CALLBACK(device_realized), self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
if (priv->startup) {
g_signal_connect(device,
"notify::" NM_DEVICE_HAS_PENDING_ACTION,
G_CALLBACK(device_has_pending_action_changed),
self);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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);
core/rfkill: add "nm" prefix to RfKillState and RfKillType enums Names in header files should have an "nm" prefix. We do that pretty consistently. Fix the offenders RfKillState and RfKillType. Also, rename the RfKillState enums to follow the type name. For example, NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED. Also, when we camel-case a typedef (NMRfKillState) we would want that the lower-case names use underscore between the words. So it should be `nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution here is to also rename "RfKill" to "Rfkill". That make is consistent with the spelling of the existing `NMRfkillManager` type and the `nm-rfkill-manager.h` file.
2022-02-01 20:21:34 +01:00
if (rtype != NM_RFKILL_TYPE_UNKNOWN) {
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update(self, rtype);
nm_device_set_enabled(device, _rfkill_radio_state_get(self, 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
}
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: fix assuming connections when platform-init arrives late When the NM_UNMANAGED_PLATFORM_INIT flag is cleared last in device_link_changed(), a recheck-assume is scheduled and then the device goes immediately to UNAVAILABLE. During the state transition, addresses and routes are removed from the interface. Then, recheck-assume finds that the device can be assumed but it's too late since the device was already deconfigured. This is a problem as the whole point of assuming a device is to activate a connection while leaving the device untouched. In the NMCI "dracut_NM_vlan_over_bridge and dracut_NM_vlan_over_bond" test, NM in real root tries to assume a vlan device that was activated in initrd. When the interface gets deconfigured in UNAVAILABLE, the connection to the NFS server breaks and the rootfs becomes inaccessible. The fix to this problem is to delay state transitions in device_link_changed() to a idle handler, so that recheck-assume can run before. Fixes-test: @dracut_NM_vlan_over_bridge Fixes-test: @dracut_NM_vlan_over_bond https://bugzilla.redhat.com/show_bug.cgi?id=2047302
2022-02-02 09:39:23 +01:00
nm_device_set_unmanaged_by_user_settings(device, TRUE);
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError *error = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
g_return_if_fail(NM_IS_MANAGER(self));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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,
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
all: fix minor typos https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
2020-07-04 11:37:01 +03:00
nm_manager_notify_device_availability_maybe_changed(NMManager *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
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *device;
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
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
platform_link_added(NMManager *self,
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceFactory *factory;
NMDevice *device = NULL;
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) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gboolean compatible = TRUE;
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: use nm_streq*() instead of strcmp() in "nm-device.c" and "nm-manager.c"
2020-07-20 09:31:03 +02:00
if (!nm_streq(nm_device_get_iface(candidate), plink->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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gboolean ignore = FALSE;
gs_free_error GError *error = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
all: unify spelling of "fall-through" comment for switch statements We used "/* fall through */" and "/* fall-through */" inconsistently. Rename to use only one variant.
2020-02-21 12:56:03 +01: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: 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: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
manager: ensure auto default connection is deleted when a veth goes away When the link goes away the manager keeps software devices alive as unrealized because there is still a connection for them. If the device is software and has a NM-generated connection, keeping the device alive means that also the generated connection stays alive. The result is that both stick around forever even if there is no longer a kernel link. Add a check to avoid this situation. https://bugzilla.redhat.com/show_bug.cgi?id=1945282 Fixes: cd0cf9229d49 ('veth: add support to configure veth interfaces')
2021-03-31 21:32:43 +02:00
static gboolean
_check_remove_dev_on_link_deleted(NMManager *self, NMDevice *device)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
manager: ensure auto default connection is deleted when a veth goes away When the link goes away the manager keeps software devices alive as unrealized because there is still a connection for them. If the device is software and has a NM-generated connection, keeping the device alive means that also the generated connection stays alive. The result is that both stick around forever even if there is no longer a kernel link. Add a check to avoid this situation. https://bugzilla.redhat.com/show_bug.cgi?id=1945282 Fixes: cd0cf9229d49 ('veth: add support to configure veth interfaces')
2021-03-31 21:32:43 +02:00
NMSettingsConnection *const *scons = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMConnection *con;
manager: ensure auto default connection is deleted when a veth goes away When the link goes away the manager keeps software devices alive as unrealized because there is still a connection for them. If the device is software and has a NM-generated connection, keeping the device alive means that also the generated connection stays alive. The result is that both stick around forever even if there is no longer a kernel link. Add a check to avoid this situation. https://bugzilla.redhat.com/show_bug.cgi?id=1945282 Fixes: cd0cf9229d49 ('veth: add support to configure veth interfaces')
2021-03-31 21:32:43 +02:00
guint i;
nm_assert(nm_device_is_software(device));
/* In general, software devices stick around as unrealized
* until their connection is removed. However, we don't want
* that a NM-generated connection keeps the device alive.
* If there are no other compatible connections, the device
* should be also removed.
*/
scons = nm_settings_get_connections(priv->settings, NULL);
for (i = 0; scons[i]; i++) {
con = nm_settings_connection_get_connection(scons[i]);
if (!nm_connection_is_virtual(con))
continue;
if (NM_FLAGS_HAS(nm_settings_connection_get_flags(scons[i]),
NM_SETTINGS_CONNECTION_INT_FLAGS_NM_GENERATED))
continue;
if (!nm_device_check_connection_compatible(device, con, NULL))
continue;
/* Found a virtual connection compatible, the device must
* stay around unrealized. */
return FALSE;
}
return TRUE;
}
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
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = data->self;
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError *error = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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: 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 {
manager: ensure auto default connection is deleted when a veth goes away When the link goes away the manager keeps software devices alive as unrealized because there is still a connection for them. If the device is software and has a NM-generated connection, keeping the device alive means that also the generated connection stays alive. The result is that both stick around forever even if there is no longer a kernel link. Add a check to avoid this situation. https://bugzilla.redhat.com/show_bug.cgi?id=1945282 Fixes: cd0cf9229d49 ('veth: add support to configure veth interfaces')
2021-03-31 21:32:43 +02:00
if (_check_remove_dev_on_link_deleted(self, device))
remove_device(self, device, FALSE);
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
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
PlatformLinkCbData *data;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_free char *order = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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++) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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/rfkill: cleanup arguments for "rfkill-changed" signal The signal parameters are G_TYPE_UINT. We should not assume that our enums are a compatible integer type. In practice of course they always were. Let's just be clear about when we have an integer and when we have an enum.
2022-02-02 12:04:27 +01:00
rfkill_manager_rfkill_changed_cb(NMRfkillManager *rfkill_mgr,
/* NMRfkillType */ guint rtype,
/* NMRfkillState */ guint 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
{
core/rfkill: cleanup arguments for "rfkill-changed" signal The signal parameters are G_TYPE_UINT. We should not assume that our enums are a compatible integer type. In practice of course they always were. Let's just be clear about when we have an integer and when we have an enum.
2022-02-02 12:04:27 +01:00
nm_assert(rtype < NM_RFKILL_TYPE_MAX);
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_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,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
_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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMActiveConnection *ac;
NMDevice *ac_device;
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 {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_unref_ptrarray GPtrArray *all_ac_arr = NULL;
gs_free_error GError *local_best = NULL;
NMConnectionMultiConnect multi_connect;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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 (!connection)
connection = nm_settings_connection_get_connection(sett_conn);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
if (all_ac_arr) {
guint i;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_state = nm_active_connection_get_state(ac);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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++) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMActiveConnection *ac2 = all_ac_arr->pdata[i];
NMDevice *ac_device2 = nm_active_connection_get_device(ac2);
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_state2;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
if (!ac_device2
|| (unavailable_devices
&& g_hash_table_contains(unavailable_devices, ac_device2))
|| !nm_device_check_connection_available(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
connection,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
flags,
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
NULL))
continue;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_state2 = nm_active_connection_get_state(ac2);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
if (!ac_device)
goto found_better;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
break;
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
case NM_ACTIVE_CONNECTION_STATE_ACTIVATED:
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
break;
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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
break;
default:
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
nm_assert_not_reached();
goto found_better;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
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;
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
found_better:
ac = ac2;
ac_state = ac_state2;
ac_device = ac_device2;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
if (ac_device)
return ac_device;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* Pick the first device that's compatible with the connection. */
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError *local = 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
DeviceActivationPrio prio;
if (unavailable_devices && g_hash_table_contains(unavailable_devices, device))
continue;
/* determine the priority of this device. Currently, this priority is independent
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
* 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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (error) {
gboolean reset_error;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (!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);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
if (best.device)
return best.device;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_get_devices(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_get_all_devices(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_get_device_by_ip_iface(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER(obj);
NMDevice *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
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice **out_master_device,
NMActiveConnection **out_master_ac,
GError **error)
{
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
s_con = nm_connection_get_setting_connection(connection);
g_assert(s_con);
master = nm_setting_connection_get_master(s_con);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
if (master == NULL)
return TRUE; /* success, but no master */
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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,
manager: fix active_connection_find() Commit 33b9fa3a3caf ("manager: Keep volatile/external connections while referenced by async_op_lst") changed active_connection_find() to also return active connections that are not yet activating but are waiting authorization. This has side effect for other callers of the function. In particular, _get_activatable_connections_filter() should exclude only ACs that are really active, not those waiting for authorization. Otherwise, in ensure_master_active_connection() all the ACs waiting authorization are missed and we might fail to find the right master AC. Add an argument to active_connection_find to select whether include ACs waiting authorization. Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1955101
2021-05-13 10:49:39 +02:00
FALSE,
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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
ensure_master_active_connection(NMManager *self,
NMAuthSubject *subject,
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
g_return_val_if_fail(connection, NULL);
g_return_val_if_fail(master_connection || master_device, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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 =
NM_FLAGS_HAS(nm_device_get_activation_state_flags(device),
NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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];
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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,
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,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: don't bring up master connections on devices that are not disconnected Otherwise we're likely interfering with an in-progress activation. Consider the following connections, first two being active: id=bond0a type=bond interface-name=bond0, (Active) id=dummy0a type=dummy interface-name=dummy0 master=bond0a, (Active) id=bond0b type=bond interface-name=bond0 id=dummy0b type=dummy interface-name=dummy0 master=bond0b Note there's two hierarchies with bond0 bond having a dummy0 port, first one (bond0a, dummy0a) being active. Suppose the users wants to bring the other one up (bond0b, dummy0b) and does a "nmcli c up bond0b". This is what happens: 1.) bond0b starts activation due to user request 2.) bond0a starts deactivation due to new activation 3.) dummy0 loses its master, begins deactivation 4.) dummy0 finishes deactivation 5.) both dummy0 being deactivated and bond0b check for slaves enqueues auto-activation check for dummy0 6.) auto-activation picks dummy0a for dummy0 7.) dummy0a begins activation 8.) dummy0a looks for master connection, picks bond0a 9.) bond0a starts activating on bond0, kicks bond0b away 10.) bond0a and dummy0a end up finishing activation 11.) Everybody unhappy :( NM's auto-activation logic is only takes autoconnect priority into account when figuring out a connection to activate and can't be expected to bring up most sensible combination of connection when there's multiple ones for the same devices with complex dependencies. Nevertheless, it shouldn't ever undo the activations if the user is bringing up the connections manually. This patch prevents bringing up of master devices that are not DISCONNECTED and therefore shouldn't be up for grabs. This was previously done for hardware devices only whereas I believe it should be the case for *all* realized devices. https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1172 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1364
2022-09-05 17:34:01 +02:00
if (nm_device_is_real(candidate)
&& nm_device_get_state(candidate) != NM_DEVICE_STATE_DISCONNECTED)
continue;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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,
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,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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();
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *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
} 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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *device,
guint *out_n_slaves,
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
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(manager);
NMSettingsConnection *const *all_connections = NULL;
guint n_all_connections;
guint i;
SlaveConnectionInfo *slaves = NULL;
guint n_slaves = 0;
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: add nm_settings_get_connection_sorted_by_autoconnect_priority() Turns out, we call nm_settings_get_connection_clone() *a lot* with sort order nm_settings_connection_cmp_autoconnect_priority_p_with_data(). As we cache the (differently sorted) list of connections, also cache the presorted list. The only complication is that every time we still need to check whether the list is still sorted, because it would be more complicated to invalidate the list when an entry changes which affects the sort order. Still, such a check is usually successful and requires "only" N-1 comparisons.
2021-06-15 00:41:45 +02:00
all_connections =
nm_settings_get_connections_sorted_by_autoconnect_priority(priv->settings,
&n_all_connections);
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
manager: fix syntax Remove the commas and use compound literals.
2022-09-15 16:19:24 +02:00
slaves[n_slaves++] = (SlaveConnectionInfo){
.connection = candidate,
.device = slave_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
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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)) {
core: use nm_streq*() instead of strcmp() in "nm-device.c" and "nm-manager.c"
2020-07-20 09:31:03 +02:00
return nm_strcmp0(nm_device_get_iface(a_info->device), nm_device_get_iface(b_info->device));
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
}
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *master_device,
NMAuthSubject *subject,
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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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 (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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
for (i = 0; i < n_slaves; i++) {
SlaveConnectionInfo *slave = &slaves[i];
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *uuid;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
/* 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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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: 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,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
nm_device_set_unmanaged_by_flags(device,
NM_UNMANAGED_USER_EXPLICIT,
FALSE,
NM_DEVICE_STATE_REASON_USER_REQUESTED);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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)
{
shared: nm-auth-subject: add unix-session type
2019-12-17 20:36:18 +01:00
if (nm_auth_subject_get_subject_type(subject) == NM_AUTH_SUBJECT_TYPE_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
|| 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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *parent;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
all: use G_CALLBACK() macro instead of plain cast
2021-08-05 09:06:12 +02:00
g_signal_handlers_disconnect_by_func(active, G_CALLBACK(active_connection_parent_active), self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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 (!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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *device, *master_device = NULL;
NMConnection *applied;
NMSettingsConnection *sett_conn;
NMSettingsConnection *master_connection = NULL;
NMConnection *existing_connection = NULL;
NMActiveConnection *master_ac = NULL;
NMAuthSubject *subject;
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: check for master existence before realizing the device If we find out that no compatible master connection exists, we shouldn't realize the slave in the first place.
2020-01-28 18:45:12 +01:00
/* Try to find the master connection/device if the connection has a dependency */
if (!find_master(self,
applied,
device,
&master_connection,
&master_device,
&master_ac,
error)) {
g_prefix_error(error,
"Can not find a master for %s: ",
nm_settings_connection_get_id(sett_conn));
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* Create any backing resources the device needs */
if (!nm_device_is_real(device)) {
NMDevice *parent;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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) {
g_set_error(error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_DEPENDENCY_FAILED,
"parent device '%s' not found",
parent_spec);
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (parent && !nm_device_is_real(parent)) {
NMSettingsConnection *parent_con;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMActiveConnection *parent_ac;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: forbid autoactivation of parent when it is blocked by user request If a device is being autoactivated and requires a parent that is blocked due to user request, the autoactivation attempt should fail because NM shouldn't overrule the user decision. https://bugzilla.redhat.com/show_bug.cgi?id=1765566
2019-12-03 16:29:15 +01:00
if (nm_active_connection_get_activation_reason(active)
== NM_ACTIVATION_REASON_AUTOCONNECT
core: drop mask argument from nm_settings_connection_autoconnect_blocked_reason_get() We don't need the mask argument. If the caller wants to check only for certain flags, she can do that right away with NM_FLAGS_ANY (nm_settings_connection_autoconnect_blocked_reason_get (sett_con), flags)
2020-06-03 18:35:07 +02:00
&& NM_FLAGS_HAS(nm_settings_connection_autoconnect_blocked_reason_get(parent_con),
NM_SETTINGS_AUTO_CONNECT_BLOCKED_REASON_USER_REQUEST)) {
manager: forbid autoactivation of parent when it is blocked by user request If a device is being autoactivated and requires a parent that is blocked due to user request, the autoactivation attempt should fail because NM shouldn't overrule the user decision. https://bugzilla.redhat.com/show_bug.cgi?id=1765566
2019-12-03 16:29:15 +01:00
g_set_error(error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_DEPENDENCY_FAILED,
"the parent connection of %s cannot autoactivate because it is blocked "
"due to user request",
nm_device_get_iface(device));
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
parent_ac = nm_manager_activate_connection(
self,
parent_con,
NULL,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* We can't realize now; defer until the parent device is ready. */
g_signal_connect(active,
NM_ACTIVE_CONNECTION_PARENT_ACTIVE,
all: use G_CALLBACK() macro instead of plain cast
2021-08-05 09:06:12 +02:00
G_CALLBACK(active_connection_parent_active),
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
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
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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: ",
manager: improve error messages
2021-01-25 14:56:46 +01:00
nm_device_get_ip_iface(master_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
} else {
g_prefix_error(error,
"Master connection '%s' can't be activated: ",
manager: improve error messages
2021-01-25 14:56:46 +01:00
nm_settings_connection_get_id(master_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
}
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMActiveConnection *ac;
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
guint i, n_all;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
/* 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: fix active_connection_find() Commit 33b9fa3a3caf ("manager: Keep volatile/external connections while referenced by async_op_lst") changed active_connection_find() to also return active connections that are not yet activating but are waiting authorization. This has side effect for other callers of the function. In particular, _get_activatable_connections_filter() should exclude only ACs that are really active, not those waiting for authorization. Otherwise, in ensure_master_active_connection() all the ACs waiting authorization are missed and we might fail to find the right master AC. Add an argument to active_connection_find to select whether include ACs waiting authorization. Fixes: 33b9fa3a3caf ('manager: Keep volatile/external connections while referenced by async_op_lst') https://bugzilla.redhat.com/show_bug.cgi?id=1955101
2021-05-13 10:49:39 +02:00
FALSE,
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] : 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
}
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
if (NM_IS_VPN_CONNECTION(active))
success = _internal_activate_vpn(self, active, error);
else
success = _internal_activate_device(self, active, error);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSettingsConnection *sett_conn,
NMConnection *incompl_conn,
NMConnection *applied,
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError **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
{
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *parent_device;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
if (!parent) {
g_set_error_literal(error,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_UNKNOWN_CONNECTION,
"Could not find source connection.");
return NULL;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_internal_activation_auth_done(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
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
NMActiveConnection *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
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
*/
Revert "manager: change autoconnect-slaves logic for already active slaves" The commit breaks many nmstate CI tests. It also breaks the autoconnect-slaves functionality: if the master gets reactivated and the slave was active, the slave is not reconnected. A different solution is needed for the original issue. This reverts commit 024e983c8e38d1f325ac64b9d84b2332afcd6549.
2020-06-15 09:36:41 +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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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:
manager: Keep volatile/external connections while referenced by async_op_lst If an NMSettingsConnection with the VOLATILE or EXTENRAL flags is created and passed to nm_manager_activate_connection, it's immediately scheduled for deletion in an idle callback and will likely be deleted before the authorization step in nm_manager_activate_connection finishes and the connection will be aborted. This is because there's no NMActiveConnection in priv->active_connection_lst_head referencing it until _internal_activate_device(). Change active_connection_find_by_connection to also look for connections in priv->async_op_lst_head. New _delete_volatile_connection_do() calls are added. Previously it would be called when an active connection may have been removed from priv->active_connection_lst_head, now also call it when an active connection may have been removed from priv->async_op_lst_head without being added to priv->active_connection_lst_head. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/671
2020-11-04 09:46:41 +01:00
_delete_volatile_connection_do(self, 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
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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
nm_manager_activate_connection(NMManager *self,
NMSettingsConnection *sett_conn,
NMConnection *applied,
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError **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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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, "/"));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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 (!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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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) {
if (async_op_data->async_op_type != ASYNC_OP_TYPE_AC_AUTH_ACTIVATE_INTERNAL)
continue;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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)
shared: nm-auth-subject: add unix-session type
2019-12-17 20:36:18 +01:00
&& nm_auth_subject_get_subject_type(nm_active_connection_get_subject(active))
== NM_AUTH_SUBJECT_TYPE_INTERNAL
&& nm_auth_subject_get_subject_type(subject) == NM_AUTH_SUBJECT_TYPE_INTERNAL
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_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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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 *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
validate_activation_request(NMManager *self,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSettingsConnection *sett_conn,
NMConnection *connection,
const char *device_path,
NMDevice **out_device,
gboolean *out_is_vpn,
GError **error)
{
NMDevice *device = NULL;
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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 (!connection)
connection = nm_settings_connection_get_connection(sett_conn);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: use NMAuthSubject in D-Bus triggered activation paths
2013-07-29 12:42:16 -05:00
/* Validate the caller */
shared: move nm-dbus-auth-subject to shared/nm-libnm-core-intern Move it to shared as it's useful for clients as well. Move and rename nm_dbus_manager_new_auth_subject_from_context() and nm_dbus_manager_new_auth_subject_from_message() in nm-dbus-manager.c as they're needed there.
2019-12-19 11:30:38 +01:00
subject = nm_dbus_manager_new_auth_subject_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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* 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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_activation_auth_done(NMManager *self,
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
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError *error = NULL;
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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) {
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: 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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))
goto fail;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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:
manager: Keep volatile/external connections while referenced by async_op_lst If an NMSettingsConnection with the VOLATILE or EXTENRAL flags is created and passed to nm_manager_activate_connection, it's immediately scheduled for deletion in an idle callback and will likely be deleted before the authorization step in nm_manager_activate_connection finishes and the connection will be aborted. This is because there's no NMActiveConnection in priv->active_connection_lst_head referencing it until _internal_activate_device(). Change active_connection_find_by_connection to also look for connections in priv->async_op_lst_head. New _delete_volatile_connection_do() calls are added. Previously it would be called when an active connection may have been removed from priv->active_connection_lst_head, now also call it when an active connection may have been removed from priv->async_op_lst_head without being added to priv->active_connection_lst_head. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/671
2020-11-04 09:46:41 +01:00
_delete_volatile_connection_do(self, connection);
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_activate_connection(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *dbus_connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER(obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
gs_unref_object NMActiveConnection *active = NULL;
gs_unref_object NMAuthSubject *subject = NULL;
NMSettingsConnection *sett_conn = NULL;
NMDevice *device = NULL;
gboolean is_vpn = FALSE;
GError *error = NULL;
const char *connection_path;
const char *device_path;
const char *specific_object_path;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
g_variant_get(parameters, "(&o&o&o)", &connection_path, &device_path, &specific_object_path);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
shared: drop nm_utils_dbus_normalize_object_path() in favor of nm_dbus_path_not_empty() They do the same thing. Unify and drop one.
2020-01-29 15:55:38 +01:00
connection_path = nm_dbus_path_not_empty(connection_path);
specific_object_path = nm_dbus_path_not_empty(specific_object_path);
device_path = nm_dbus_path_not_empty(device_path);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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.
all: fix typo in man pages There should be a comma after 'Otherwise' and 'Currently'. https://bugzilla.redhat.com/show_bug.cgi?id=1852452 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/560
2020-07-01 17:20:40 -04:00
* Otherwise, the "best" connection for the device is chosen and activated,
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
* 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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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,
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,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
/* we passed the pointer on to _async_op_data_new_ac_auth_activate_user() */
g_steal_pointer(&active);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
activation_add_done(NMSettings *settings,
NMSettingsConnection *new_connection,
GError *error,
core: port NMManager to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
gs_unref_object NMActiveConnection *active = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_free_error GError *local = NULL;
gpointer async_op_type_ptr;
AsyncOpType async_op_type;
GVariant *result_floating;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
nm_active_connection_set_settings_connection(active, new_connection);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (!_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: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (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)),
all: use nm_g_variant_singleton_a*() helpers
2021-04-14 21:12:02 +02:00
nm_g_variant_singleton_aLsvI());
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError *error = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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,
settings: add "plugin" argument to AddAndActivate2() This will confine a newly added connection to a particular settings plugin.
2022-03-14 10:20:11 +01:00
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
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,
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_utils_user_data_pack(self, g_object_ref(active), 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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_add_and_activate_connection(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *dbus_connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER(obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
gs_unref_object NMConnection *incompl_conn = NULL;
gs_unref_object NMActiveConnection *active = NULL;
gs_unref_object NMAuthSubject *subject = NULL;
GError *error = NULL;
NMDevice *device = NULL;
gboolean is_vpn = FALSE;
gs_unref_variant GVariant *settings = NULL;
gs_unref_variant GVariant *options = NULL;
const char *device_path;
const char *specific_object_path;
gs_free NMConnection **conns = NULL;
NMSettingsConnectionPersistMode persist_mode = NM_SETTINGS_CONNECTION_PERSIST_MODE_TO_DISK;
gboolean is_volatile = FALSE;
gboolean bind_dbus_client = FALSE;
AsyncOpType async_op_type;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *option_name;
GVariant *option_value;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *s;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
option_value_free = option_value;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
shared: drop nm_utils_dbus_normalize_object_path() in favor of nm_dbus_path_not_empty() They do the same thing. Unify and drop one.
2020-01-29 15:55:38 +01:00
specific_object_path = nm_dbus_path_not_empty(specific_object_path);
device_path = nm_dbus_path_not_empty(device_path);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
conns = nm_settings_connections_array_to_connections(
nm_settings_get_connections(priv->settings, NULL),
-1);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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"),
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,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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, GDBusMethodInvocation *context, gpointer user_data)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(user_data);
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
char *path;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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: 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_deactivate_connection(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *dbus_connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER(obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError *error = NULL;
NMAuthSubject *subject = NULL;
NMAuthChain *chain;
const char *active_path;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
g_variant_get(parameters, "(&o)", &active_path);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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) {
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 */
shared: move nm-dbus-auth-subject to shared/nm-libnm-core-intern Move it to shared as it's useful for clients as well. Move and rename nm_dbus_manager_new_auth_subject_from_context() and nm_dbus_manager_new_auth_subject_from_message() in nm-dbus-manager.c as they're needed there.
2019-12-19 11:30:38 +01:00
subject = nm_dbus_manager_new_auth_subject_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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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 (!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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
chain = nm_auth_chain_new_subject(subject, invocation, deactivate_net_auth_done_cb, self);
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: make "nmcli net off" wait for deactivations The current behavior of "nmcli networking off" is that it starts disconnecting the devices, but doesn't wait for them to actually come down. That is not too helpful: the user never knows when the network is actually disconnected. Some users, notably the NetworkManager-CI test suite, seem to expect the devices are all disconnected after the command finishes. Even worse, it immediately proceeds activating the connections: @ovs_cloned_mac_set_on_iface ... * Execute "nmcli networking off && nmcli networking on" This results in pure utter chaos. In particular, the slave connections sometimes refuse to activate after "nmcli networking on", because the master connections are still getting disconnected in response to preceding "nmcli networking off". Let's make Enable(FALSE) and Sleep(TRUE) block until none of the devices are expected to go down. Note that this makes those call also return when Enable(TRUE) and Sleep(FALSE) is issued in meanwhile. Therefore a return from Enable(FALSE) doesn't necessarily imply the networking is disabled. This is a feature, not a bug -- the actual manager state is available in the "state" property. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:06:14 +02:00
static void
sleep_devices_check_empty(NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
GDBusMethodInvocation *invocation;
if (g_hash_table_size(priv->sleep_devices) > 0)
return;
while (priv->sleep_invocations) {
invocation = priv->sleep_invocations->data;
g_dbus_method_invocation_return_value(invocation, NULL);
priv->sleep_invocations = g_slist_remove(priv->sleep_invocations, invocation);
}
}
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
g_hash_table_insert(priv->sleep_devices,
g_object_ref(device),
suspending ? nm_sleep_monitor_inhibit_take(priv->sleep_monitor) : NULL);
all: use G_CALLBACK() macro instead of plain cast
2021-08-05 09:06:12 +02:00
g_signal_connect(device, "notify::" NM_DEVICE_STATE, G_CALLBACK(device_sleep_cb), 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
return TRUE;
}
static gboolean
sleep_devices_remove(NMManager *self, NMDevice *device)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(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
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);
manager: make "nmcli net off" wait for deactivations The current behavior of "nmcli networking off" is that it starts disconnecting the devices, but doesn't wait for them to actually come down. That is not too helpful: the user never knows when the network is actually disconnected. Some users, notably the NetworkManager-CI test suite, seem to expect the devices are all disconnected after the command finishes. Even worse, it immediately proceeds activating the connections: @ovs_cloned_mac_set_on_iface ... * Execute "nmcli networking off && nmcli networking on" This results in pure utter chaos. In particular, the slave connections sometimes refuse to activate after "nmcli networking on", because the master connections are still getting disconnected in response to preceding "nmcli networking off". Let's make Enable(FALSE) and Sleep(TRUE) block until none of the devices are expected to go down. Note that this makes those call also return when Enable(TRUE) and Sleep(FALSE) is issued in meanwhile. Therefore a return from Enable(FALSE) doesn't necessarily imply the networking is disabled. This is a feature, not a bug -- the actual manager state is available in the "state" property. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:06:14 +02:00
sleep_devices_check_empty(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
return TRUE;
}
static void
sleep_devices_clear(NMManager *self)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
NMDevice *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
NMSleepMonitorInhibitorHandle *handle;
GHashTableIter iter;
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);
}
manager: make "nmcli net off" wait for deactivations The current behavior of "nmcli networking off" is that it starts disconnecting the devices, but doesn't wait for them to actually come down. That is not too helpful: the user never knows when the network is actually disconnected. Some users, notably the NetworkManager-CI test suite, seem to expect the devices are all disconnected after the command finishes. Even worse, it immediately proceeds activating the connections: @ovs_cloned_mac_set_on_iface ... * Execute "nmcli networking off && nmcli networking on" This results in pure utter chaos. In particular, the slave connections sometimes refuse to activate after "nmcli networking on", because the master connections are still getting disconnected in response to preceding "nmcli networking off". Let's make Enable(FALSE) and Sleep(TRUE) block until none of the devices are expected to go down. Note that this makes those call also return when Enable(TRUE) and Sleep(FALSE) is issued in meanwhile. Therefore a return from Enable(FALSE) doesn't necessarily imply the networking is disabled. This is a feature, not a bug -- the actual manager state is available in the "state" property. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:06:14 +02:00
sleep_devices_check_empty(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
}
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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_remove(self, device))
g_return_if_reached();
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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 (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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: fix race condition when resuming from sleep If the device state change (to disconnected or unmanaged) triggered by a sleep event happens after the wake, the devices becomes wrongly unmanaged and it's necessary to manually manage it again, or restart NM. During the wake event we should disconnect the device_sleep_cb() callback for all devices because we don't want to react to state changes anymore; in particular we don't need to detect when the device becomes disconnected to unmanage it.
2020-07-16 11:57:14 +02:00
sleep_devices_clear(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
if (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
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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.
*/
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update(self, NM_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. */
core: log when dynamic IP configuration is restarted and why (cherry picked from commit 6cd69fde339cc69717671226e06156339de71314)
2022-08-24 16:50:14 +02:00
nm_device_update_dynamic_ip_setup(device, "wake up");
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.
*/
core/rfkill: add "nm" prefix to RfKillState and RfKillType enums Names in header files should have an "nm" prefix. We do that pretty consistently. Fix the offenders RfKillState and RfKillType. Also, rename the RfKillState enums to follow the type name. For example, NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED. Also, when we camel-case a typedef (NMRfKillState) we would want that the lower-case names use underscore between the words. So it should be `nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution here is to also rename "RfKill" to "Rfkill". That make is consistent with the spelling of the existing `NMRfkillManager` type and the `nm-rfkill-manager.h` file.
2022-02-01 20:21:34 +01:00
for (i = 0; i < NM_RFKILL_TYPE_MAX; i++) {
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
const NMRfkillType rtype = i;
const RfkillRadioState *rstate = &priv->radio_states[rtype];
gboolean enabled = _rfkill_radio_state_get_enabled(rstate, TRUE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
_LOGD(LOGD_RFKILL,
core: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
"rfkill: %s %s devices (hw_enabled %d, sw_enabled %d, user_enabled %d, "
"os_owner %d)",
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
enabled ? "enabling" : "disabling",
core/rfkill: add nm_rfkill_type_to_string() helper
2022-02-01 22:32:46 +01:00
nm_rfkill_type_to_string(rtype),
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
rstate->hw_enabled,
rstate->sw_enabled,
core: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
rstate->user_enabled,
rstate->os_owner);
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
if (nm_device_get_rfkill_type(device) == 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
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: recreate virtual devices on "nmcli net on" "nmcli networking off" brings down all connections, resulting in virtual devices disappearing: # nmcli c add type dummy ifname dummy0 # nmcli networking off # nmcli networking on # nmcli d show dummy0 Error: Device 'dummy0' not found. Attempt to recreate them all upon bringing the networking back up. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:07:09 +02:00
/* Give the connections a chance to recreate the virtual devices.
trivial: fix indentation
2022-10-11 18:23:15 +02:00
* We've torn them down on sleep. */
manager: recreate virtual devices on "nmcli net on" "nmcli networking off" brings down all connections, resulting in virtual devices disappearing: # nmcli c add type dummy ifname dummy0 # nmcli networking off # nmcli networking on # nmcli d show dummy0 Error: Device 'dummy0' not found. Attempt to recreate them all upon bringing the networking back up. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:07:09 +02:00
connections_changed(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_sleep(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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);
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
g_variant_get(parameters, "(b)", &do_sleep);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
shared: move nm-dbus-auth-subject to shared/nm-libnm-core-intern Move it to shared as it's useful for clients as well. Move and rename nm_dbus_manager_new_auth_subject_from_context() and nm_dbus_manager_new_auth_subject_from_message() in nm-dbus-manager.c as they're needed there.
2019-12-19 11:30:38 +01:00
subject = nm_dbus_manager_new_auth_subject_from_context(invocation);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
manager: make "nmcli net off" wait for deactivations The current behavior of "nmcli networking off" is that it starts disconnecting the devices, but doesn't wait for them to actually come down. That is not too helpful: the user never knows when the network is actually disconnected. Some users, notably the NetworkManager-CI test suite, seem to expect the devices are all disconnected after the command finishes. Even worse, it immediately proceeds activating the connections: @ovs_cloned_mac_set_on_iface ... * Execute "nmcli networking off && nmcli networking on" This results in pure utter chaos. In particular, the slave connections sometimes refuse to activate after "nmcli networking on", because the master connections are still getting disconnected in response to preceding "nmcli networking off". Let's make Enable(FALSE) and Sleep(TRUE) block until none of the devices are expected to go down. Note that this makes those call also return when Enable(TRUE) and Sleep(FALSE) is issued in meanwhile. Therefore a return from Enable(FALSE) doesn't necessarily imply the networking is disabled. This is a feature, not a bug -- the actual manager state is available in the "state" property. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:06:14 +02:00
priv->sleep_invocations = g_slist_prepend(priv->sleep_invocations, invocation);
sleep_devices_check_empty(self);
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, GDBusMethodInvocation *context, gpointer user_data)
{
manager: make "nmcli net off" wait for deactivations The current behavior of "nmcli networking off" is that it starts disconnecting the devices, but doesn't wait for them to actually come down. That is not too helpful: the user never knows when the network is actually disconnected. Some users, notably the NetworkManager-CI test suite, seem to expect the devices are all disconnected after the command finishes. Even worse, it immediately proceeds activating the connections: @ovs_cloned_mac_set_on_iface ... * Execute "nmcli networking off && nmcli networking on" This results in pure utter chaos. In particular, the slave connections sometimes refuse to activate after "nmcli networking on", because the master connections are still getting disconnected in response to preceding "nmcli networking off". Let's make Enable(FALSE) and Sleep(TRUE) block until none of the devices are expected to go down. Note that this makes those call also return when Enable(TRUE) and Sleep(FALSE) is issued in meanwhile. Therefore a return from Enable(FALSE) doesn't necessarily imply the networking is disabled. This is a feature, not a bug -- the actual manager state is available in the "state" property. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:06:14 +02:00
NMManager *self = NM_MANAGER(user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
NMAuthCallResult result;
gboolean enable;
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);
nm_audit_log_control_op(NM_AUDIT_OP_NET_CONTROL, enable ? "on" : "off", TRUE, subject, NULL);
manager: make "nmcli net off" wait for deactivations The current behavior of "nmcli networking off" is that it starts disconnecting the devices, but doesn't wait for them to actually come down. That is not too helpful: the user never knows when the network is actually disconnected. Some users, notably the NetworkManager-CI test suite, seem to expect the devices are all disconnected after the command finishes. Even worse, it immediately proceeds activating the connections: @ovs_cloned_mac_set_on_iface ... * Execute "nmcli networking off && nmcli networking on" This results in pure utter chaos. In particular, the slave connections sometimes refuse to activate after "nmcli networking on", because the master connections are still getting disconnected in response to preceding "nmcli networking off". Let's make Enable(FALSE) and Sleep(TRUE) block until none of the devices are expected to go down. Note that this makes those call also return when Enable(TRUE) and Sleep(FALSE) is issued in meanwhile. Therefore a return from Enable(FALSE) doesn't necessarily imply the networking is disabled. This is a feature, not a bug -- the actual manager state is available in the "state" property. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:06:14 +02:00
priv->sleep_invocations = g_slist_prepend(priv->sleep_invocations, context);
sleep_devices_check_empty(self);
core: PolicyKit-protect enable/disable networking method
2010-05-29 23:00:46 -07:00
}
static void
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_enable(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(obj);
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
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMAuthChain *chain;
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
g_variant_get(parameters, "(b)", &enable);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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, GDBusMethodInvocation *context, gpointer user_data)
{
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_get_permissions(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_state(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_set_logging(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
{
NMManager *self = NM_MANAGER(obj);
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_get_logging(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
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("(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 {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
device_connectivity_done(NMDevice *device,
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
NMDeviceConnectivityHandle *handle,
NMConnectivityState state,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError *error,
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
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self;
NMManagerPrivate *priv;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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--;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
GError *error = NULL;
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
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDevice *device;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
result = nm_auth_chain_get_result(chain, NM_AUTH_PERMISSION_NETWORK_CONTROL);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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: 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
c_list_for_each_entry (device, &priv->devices_lst_head, devices_lst) {
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
if (nm_device_check_connectivity(device, AF_INET, device_connectivity_done, data))
data->remaining++;
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, AF_INET6, 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_check_connectivity(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMAuthChain *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
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
core: return ifindex from nm_manager_write_device_state() nm_manager_write_device_state() writes the device state to a file. The ifindex is here important, because that is the identifier for the device and is also used as file name. Return the ifindex that was used, instead of letting the caller reimplement the knowledge which ifindex was used.
2020-03-04 13:38:49 +01:00
nm_manager_write_device_state(NMManager *self, NMDevice *device, int *out_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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *uuid = NULL;
const char *perm_hw_addr_fake = NULL;
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 perm_hw_addr_is_fake;
guint32 route_metric_default_aspired;
guint32 route_metric_default_effective;
config: avoid lgtm.com warning about int bitfield for NMConfigDeviceStateData.nm_owned lgtm.com warns: int nm_owned:3; >> Bit field nm_owned of type int should have explicitly unsigned integral, explicitly signed integral, or enumeration type. So make it a NMTernary instead. It's nicer anyway.
2020-05-06 23:03:10 +02:00
NMTernary nm_owned;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: return ifindex from nm_manager_write_device_state() nm_manager_write_device_state() writes the device state to a file. The ifindex is here important, because that is the identifier for the device and is also used as file name. Return the ifindex that was used, instead of letting the caller reimplement the knowledge which ifindex was used.
2020-03-04 13:38:49 +01:00
NM_SET_OUT(out_ifindex, 0);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
libnm-base,all: add and use NM_LOOPBACK_IFINDEX define Co-authored-by: Thomas Haller <thaller@redhat.com>
2022-06-12 19:50:09 -04:00
if (ifindex == NM_LOOPBACK_IFINDEX) {
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
/* ignore loopback */
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
config: avoid lgtm.com warning about int bitfield for NMConfigDeviceStateData.nm_owned lgtm.com warns: int nm_owned:3; >> Bit field nm_owned of type int should have explicitly unsigned integral, explicitly signed integral, or enumeration type. So make it a NMTernary instead. It's nicer anyway.
2020-05-06 23:03:10 +02:00
nm_owned = nm_device_is_software(device) ? nm_device_is_nm_owned(device) : NM_TERNARY_DEFAULT;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: return ifindex from nm_manager_write_device_state() nm_manager_write_device_state() writes the device state to a file. The ifindex is here important, because that is the identifier for the device and is also used as file name. Return the ifindex that was used, instead of letting the caller reimplement the knowledge which ifindex was used.
2020-03-04 13:38:49 +01:00
if (!nm_config_device_state_write(ifindex,
managed_type,
perm_hw_addr_fake,
uuid,
nm_owned,
route_metric_default_aspired,
route_metric_default_effective,
core: save DHCP lease information in state file in /run DHCP leases for a given interface are already exported on D-Bus through DHCP4Config and DHCP6Config objects. It is useful to have the same information also available on the filesystem so that it can be easily used by scripts. NM already saves some information about DHCP leases in /var, however that directory can only be accessed by root, for good reasons. Append lease options to the existing state file /run/NetworkManager/devices/$ifindex. Contrary to /var this directory is not persistent, but it seems more correct to expose the lease only when it is active and not after it expired or after a reboot. Since the file is in keyfile format, we add new [dhcp4] and [dhcp6] sections; however, since some options have the same name for DHCPv4 and DHCPv6, we add a "dhcp4." or "dhcp6." prefix to make the parsing by scripts (e.g. via "grep") easier. The option name is the same we use on D-Bus. Since some DHCPv6 options also have a "dhcp6_" prefix, the key name can contain "dhcp6" twice. The new sections look like this: [dhcp4] dhcp4.broadcast_address=172.25.1.255 dhcp4.dhcp_lease_time=120 dhcp4.dhcp_server_identifier=172.25.1.4 dhcp4.domain_name_servers=172.25.1.4 dhcp4.domain_search=example.com dhcp4.expiry=1641214444 dhcp4.ip_address=172.25.1.182 dhcp4.next_server=172.25.1.4 dhcp4.routers=172.25.1.4 dhcp4.subnet_mask=255.255.255.0 [dhcp6] dhcp6.dhcp6_name_servers=fd01::1 dhcp6.dhcp6_ntp_servers=ntp.example.com dhcp6.ip6_address=fd01::1aa
2022-04-19 18:09:49 +02:00
nm_device_get_dhcp_config(device, AF_INET),
nm_device_get_dhcp_config(device, AF_INET6)))
core: return ifindex from nm_manager_write_device_state() nm_manager_write_device_state() writes the device state to a file. The ifindex is here important, because that is the identifier for the device and is also used as file name. Return the ifindex that was used, instead of letting the caller reimplement the knowledge which ifindex was used.
2020-03-04 13:38:49 +01:00
return FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: return ifindex from nm_manager_write_device_state() nm_manager_write_device_state() writes the device state to a file. The ifindex is here important, because that is the identifier for the device and is also used as file name. Return the ifindex that was used, instead of letting the caller reimplement the knowledge which ifindex was used.
2020-03-04 13:38:49 +01:00
NM_SET_OUT(out_ifindex, ifindex);
return TRUE;
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
core: cleanup nm_config_device_state_prune_unseen() and accept NMPlatform for skipping pruning
2020-03-04 13:21:48 +01:00
gs_unref_hashtable GHashTable *preserve_ifindexes = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
core: cleanup nm_config_device_state_prune_unseen() and accept NMPlatform for skipping pruning
2020-03-04 13:21:48 +01:00
preserve_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) {
core: return ifindex from nm_manager_write_device_state() nm_manager_write_device_state() writes the device state to a file. The ifindex is here important, because that is the identifier for the device and is also used as file name. Return the ifindex that was used, instead of letting the caller reimplement the knowledge which ifindex was used.
2020-03-04 13:38:49 +01:00
int ifindex;
if (nm_manager_write_device_state(self, device, &ifindex)) {
core: cleanup nm_config_device_state_prune_unseen() and accept NMPlatform for skipping pruning
2020-03-04 13:21:48 +01:00
g_hash_table_add(preserve_ifindexes, GINT_TO_POINTER(ifindex));
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
}
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/trivial: rename nm_config_device_state_prune_unseen() to nm_config_device_state_prune_stale() It's just a more fitting name after the previous change.
2020-03-04 16:52:57 +01:00
nm_config_device_state_prune_stale(preserve_ifindexes, 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: 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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = user_data;
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
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
priv->devices_inited_id = 0;
Revert "manager: drop devices_inited field in NManagerPrivate for devices_inited_id" After this change the startup-complete event is reached too early, even before priv->devices_inited_id is initialized. This reverts commit d50856b5c66e6d7a8ab1af7826297787e72e06e7.
2020-02-17 13:24:28 +01:00
priv->devices_inited = TRUE;
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
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
{
manager: recreate virtual devices on "nmcli net on" "nmcli networking off" brings down all connections, resulting in virtual devices disappearing: # nmcli c add type dummy ifname dummy0 # nmcli networking off # nmcli networking on # nmcli d show dummy0 Error: Device 'dummy0' not found. Attempt to recreate them all upon bringing the networking back up. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:07:09 +02:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
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 */
core/rfkill: add "nm" prefix to RfKillState and RfKillType enums Names in header files should have an "nm" prefix. We do that pretty consistently. Fix the offenders RfKillState and RfKillType. Also, rename the RfKillState enums to follow the type name. For example, NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED. Also, when we camel-case a typedef (NMRfKillState) we would want that the lower-case names use underscore between the words. So it should be `nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution here is to also rename "RfKill" to "Rfkill". That make is consistent with the spelling of the existing `NMRfkillManager` type and the `nm-rfkill-manager.h` file.
2022-02-01 20:21:34 +01:00
for (i = 0; i < NM_RFKILL_TYPE_MAX; i++) {
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
const NMRfkillType rtype = i;
RfkillRadioState *rstate = &priv->radio_states[rtype];
gboolean 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
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 */
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
_rfkill_radio_state_set_from_manager(self, rtype, rstate);
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
_LOGI(LOGD_RFKILL,
"rfkill: %s %s by radio killswitch; %s by state file",
core/rfkill: add nm_rfkill_type_to_string() helper
2022-02-01 22:32:46 +01:00
nm_rfkill_type_to_string(rtype),
core/rfkill: move immutable type description of Rfkill to global field RadioState contained both the mutable user-data and meta-data about the radio state. The latter is immutable. The parts that cannot change, should be separate from those that can change. Move them to a separate array. Of course, we only have on NMManager instance, so having these fields embedded in NMManagerPrivate did not waste memory. This change is done, because immutable fields should be const. In this case, they are now const global data, which is even protected by the linker from accidental mutation.
2022-02-01 22:08:52 +01:00
(rstate->hw_enabled && rstate->sw_enabled) ? "enabled" : "disabled",
rstate->user_enabled ? "enabled" : "disabled");
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
enabled = _rfkill_radio_state_get_enabled(rstate, TRUE);
_rfkill_update_devices(self, rtype, 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
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
_static_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);
manager: recreate virtual devices on "nmcli net on" "nmcli networking off" brings down all connections, resulting in virtual devices disappearing: # nmcli c add type dummy ifname dummy0 # nmcli networking off # nmcli networking on # nmcli d show dummy0 Error: Device 'dummy0' not found. Attempt to recreate them all upon bringing the networking back up. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:07:09 +02:00
/* Make sure virtual devices for all connections are created so
* that they could be autoconnected. */
connections_changed(self);
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
Revert "manager: drop devices_inited field in NManagerPrivate for devices_inited_id" After this change the startup-complete event is reached too early, even before priv->devices_inited_id is initialized. This reverts commit d50856b5c66e6d7a8ab1af7826297787e72e06e7.
2020-02-17 13:24:28 +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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(user_data);
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
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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
if (nm_device_get_firmware_missing(device) && (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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
firmware_dir_changed(GFileMonitor *monitor,
GFile *file,
GFile *other_file,
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
GFileMonitorEvent event_type,
gpointer user_data)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(user_data);
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
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(user_data);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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 {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self;
NMDBusObject *obj;
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 NMDBusInterfaceInfoExtended *interface_info;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusPropertyInfoExtended *property_info;
GVariant *value;
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
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
audit: improve audit logging for setting NMDevice D-Bus objects Previously, we would log: audit: op="device-autoconnect" arg="autoconnect" pid=282087 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled" pid=559201 uid=0 result="success" Now we log: audit: op="device-autoconnect" interface="eth0" ifindex=2 args="false" pid=443054 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled:off" pid=629726 uid=0 result="success"
2021-04-12 10:04:19 +02:00
static const char *
_dbus_set_property_audit_log_get_args(NMDBusObject *obj,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *property_name,
GVariant *value,
char **str_to_free)
audit: improve audit logging for setting NMDevice D-Bus objects Previously, we would log: audit: op="device-autoconnect" arg="autoconnect" pid=282087 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled" pid=559201 uid=0 result="success" Now we log: audit: op="device-autoconnect" interface="eth0" ifindex=2 args="false" pid=443054 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled:off" pid=629726 uid=0 result="success"
2021-04-12 10:04:19 +02:00
{
nm_assert(str_to_free && !*str_to_free);
/* We assert here that the property is one of the few expected ones.
*
* Future properties should not made writable! Add a D-Bus method instead,
* they are more flexible (for example, you can set multiple properties at
* once). */
if (NM_IS_DEVICE(obj)) {
nm_assert(NM_IN_STRSET(property_name,
NM_DEVICE_MANAGED,
NM_DEVICE_AUTOCONNECT,
NM_DEVICE_STATISTICS_REFRESH_RATE_MS));
return (*str_to_free = g_variant_print(value, FALSE));
}
nm_assert(NM_IS_MANAGER(obj));
if (NM_IN_STRSET(property_name,
NM_MANAGER_WIRELESS_ENABLED,
NM_MANAGER_WWAN_ENABLED,
NM_MANAGER_WIMAX_ENABLED,
NM_MANAGER_CONNECTIVITY_CHECK_ENABLED)) {
return (*str_to_free = g_strdup_printf("%s:%s",
property_name,
g_variant_get_boolean(value) ? "on" : "off"));
}
if (NM_IN_STRSET(property_name, NM_MANAGER_GLOBAL_DNS_CONFIGURATION)) {
return NM_MANAGER_GLOBAL_DNS_CONFIGURATION;
}
return nm_assert_unreachable_val("???");
}
/* this is a macro to catch the caller's line number. */
#define _dbus_set_property_audit_log(obj, \
audit_op, \
auth_subject, \
property_name, \
value, \
error_message) \
G_STMT_START \
{ \
NMDBusObject *const _obj = (obj); \
const char *const _audit_op = (audit_op); \
NMAuthSubject *const _auth_subject = (auth_subject); \
const char *const _property_name = (property_name); \
GVariant *const _value = (value); \
const char *const _error_message = (error_message); \
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_free char *_args_to_free = NULL; \
audit: improve audit logging for setting NMDevice D-Bus objects Previously, we would log: audit: op="device-autoconnect" arg="autoconnect" pid=282087 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled" pid=559201 uid=0 result="success" Now we log: audit: op="device-autoconnect" interface="eth0" ifindex=2 args="false" pid=443054 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled:off" pid=629726 uid=0 result="success"
2021-04-12 10:04:19 +02:00
\
if (NM_IS_DEVICE(_obj)) { \
nm_audit_log_device_op(_audit_op, \
NM_DEVICE(_obj), \
!_error_message, \
_dbus_set_property_audit_log_get_args(_obj, \
_property_name, \
_value, \
&_args_to_free), \
_auth_subject, \
_error_message); \
} else { \
nm_audit_log_control_op(_audit_op, \
_dbus_set_property_audit_log_get_args(_obj, \
_property_name, \
_value, \
&_args_to_free), \
!_error_message, \
_auth_subject, \
_error_message); \
} \
} \
G_STMT_END
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_dbus_set_property_auth_cb(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
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +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);
NMAuthCallResult result;
gs_free_error GError *local = NULL;
const char *error_name = NULL;
const char *error_message = NULL;
GValue gvalue;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
g_slice_free(DBusSetPropertyHandle, handle_data);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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));
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
/* 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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
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:
audit: improve audit logging for setting NMDevice D-Bus objects Previously, we would log: audit: op="device-autoconnect" arg="autoconnect" pid=282087 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled" pid=559201 uid=0 result="success" Now we log: audit: op="device-autoconnect" interface="eth0" ifindex=2 args="false" pid=443054 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled:off" pid=629726 uid=0 result="success"
2021-04-12 10:04:19 +02:00
_dbus_set_property_audit_log(obj,
property_info->writable.audit_op,
nm_auth_chain_get_subject(chain),
property_info->property_name,
value,
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
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
nm_manager_dbus_set_property_handle(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusPropertyInfoExtended *property_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *value,
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
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = user_data;
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
NMAuthChain *chain;
const char *error_message = NULL;
gs_unref_object NMAuthSubject *subject = NULL;
DBusSetPropertyHandle *handle_data;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
audit: improve audit logging for setting NMDevice D-Bus objects Previously, we would log: audit: op="device-autoconnect" arg="autoconnect" pid=282087 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled" pid=559201 uid=0 result="success" Now we log: audit: op="device-autoconnect" interface="eth0" ifindex=2 args="false" pid=443054 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled:off" pid=629726 uid=0 result="success"
2021-04-12 10:04:19 +02:00
/* we only have writable properties on Device or Manager. In the future,
* we probably should not add new API with writable properties. Add
* methods instead. Systemd also avoids writable properties. */
nm_assert(obj == (gpointer) self || NM_IS_DEVICE(obj));
shared: move nm-dbus-auth-subject to shared/nm-libnm-core-intern Move it to shared as it's useful for clients as well. Move and rename nm_dbus_manager_new_auth_subject_from_context() and nm_dbus_manager_new_auth_subject_from_message() in nm-dbus-manager.c as they're needed there.
2019-12-19 11:30:38 +01:00
subject = nm_dbus_manager_new_auth_subject_from_context(invocation);
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 (!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;
audit: improve audit logging for setting NMDevice D-Bus objects Previously, we would log: audit: op="device-autoconnect" arg="autoconnect" pid=282087 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled" pid=559201 uid=0 result="success" Now we log: audit: op="device-autoconnect" interface="eth0" ifindex=2 args="false" pid=443054 uid=0 result="success" audit: op="radio-control" arg="wimax-enabled:off" pid=629726 uid=0 result="success"
2021-04-12 10:04:19 +02:00
_dbus_set_property_audit_log(obj,
property_info->writable.audit_op,
NULL,
property_info->property_name,
value,
error_message);
g_dbus_method_invocation_return_error_literal(invocation,
G_DBUS_ERROR,
G_DBUS_ERROR_AUTH_FAILED,
error_message);
return;
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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
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);
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(user_data);
char *op;
char *checkpoint_path = NULL;
char **devices;
NMCheckpoint *checkpoint;
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
NMAuthCallResult result;
guint32 timeout, flags;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GVariant *variant = NULL;
GError *error = NULL;
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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) {
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");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
checkpoint: use polkit to check permission
2016-08-01 17:57:13 +02:00
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();
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_checkpoint_create(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
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: reject unsupported flags for CheckpointCreate D-Bus request
2022-02-22 22:08:18 +01:00
NMManager *self = NM_MANAGER(obj);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
NMAuthChain *chain;
gs_strfreev char **devices = NULL;
guint32 rollback_timeout;
guint32 flags;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
G_STATIC_ASSERT_EXPR(sizeof(flags) <= sizeof(NMCheckpointCreateFlags));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: reject unsupported flags for CheckpointCreate D-Bus request
2022-02-22 22:08:18 +01:00
g_variant_get(parameters, "(^aouu)", &devices, &rollback_timeout, &flags);
if ((NMCheckpointCreateFlags) flags != flags
|| NM_FLAGS_ANY(flags,
~((guint32) (NM_CHECKPOINT_CREATE_FLAG_DESTROY_ALL
| NM_CHECKPOINT_CREATE_FLAG_DELETE_NEW_CONNECTIONS
| NM_CHECKPOINT_CREATE_FLAG_DISCONNECT_NEW_DEVICES
core: preserve external ports during checkpoint rollback When we have a bridge interface with ports attached externally (that is, not by NetworkManager itself), then it can make sense that during checkpoint rollback we want to keep those ports attached. During rollback, we may need to deactivate the bridge device and re-activate it. Implement this, by setting a flag before deactivating, which prevents external ports to be detached. The flag gets cleared, when the device state changes to activated (the following activation) or unmanaged. This is an ugly solution, for several reasons. For one, NMDevice tracks its ports in the "slaves" list. But what it does is ugly. There is no clear concept to understand what it actually tacks. For example, it tracks externally added interfaces (nm_device_sys_iface_state_is_external()) that are attached while not being connected. But it also tracks interfaces that we want to attach during activation (but which are not yet actually enslaved). It also tracks slaves that have no actual netdev device (OVS). So it's not clear what this list contains and what it should contain at any point in time. When we skip the change of the slaves states during nm_device_master_release_slaves_all(), it's not really clear what the effects are. It's ugly, but probably correct enough. What would be better, if we had a clear purpose of what the lists (or several lists) mean. E.g. a list of all ports that are currently, physically attached vs. a list of ports we want to attach vs. a list of OVS slaves that have no actual netdev device. Another problem is that we attach state on the device ("activation_state_preserve_external_ports"), which should linger there during the deactivation and reactivation. How can we be sure that we don't leave that flag dangling there, and that the desired following activation is the one we cared about? If the follow-up activation fails short (e.g. an unmanaged command comes first), will we properly disconnect the slaves? Should we even? In practice, it might be correct enough. Also, we only implement this for bridges. I think this is where it makes the most sense. And after all, it's an odd thing to preserve unknown, external things during a rollback -- unknown, because we have no knowledge about why these ports are attached and what to do with them. Also, the change doesn't remember the ports that were attached when the checkpoint was created. Instead, we preserve all ports that are attached during rollback. That seems more useful and easier to implement. So we don't actually rollback to the configuration when the checkpoint was created. Instead, we rollback, but keep external devices. Also, we do this now by default and introduce a flag to get the previous behavior. https://bugzilla.redhat.com/show_bug.cgi?id=2035519 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ # 909
2022-02-22 21:55:57 +01:00
| NM_CHECKPOINT_CREATE_FLAG_ALLOW_OVERLAPPING
| NM_CHECKPOINT_CREATE_FLAG_NO_PRESERVE_EXTERNAL_PORTS)))) {
core: reject unsupported flags for CheckpointCreate D-Bus request
2022-02-22 22:08:18 +01:00
g_dbus_method_invocation_return_error_literal(invocation,
NM_MANAGER_ERROR,
NM_MANAGER_ERROR_INVALID_ARGUMENTS,
"Invalid flags");
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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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: reject unsupported flags for CheckpointCreate D-Bus request
2022-02-22 22:08:18 +01:00
nm_auth_chain_set_data(chain,
"devices",
g_steal_pointer(&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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_checkpoint_destroy(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(obj);
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
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMAuthChain *chain;
const char *checkpoint_path;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
g_variant_get(parameters, "(&o)", &checkpoint_path);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_checkpoint_rollback(NMDBusObject *obj,
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 NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(obj);
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
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMAuthChain *chain;
const char *checkpoint_path;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
g_variant_get(parameters, "(&o)", &checkpoint_path);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
impl_manager_checkpoint_adjust_rollback_timeout(NMDBusObject *obj,
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
const NMDBusInterfaceInfoExtended *interface_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMDBusMethodInfoExtended *method_info,
GDBusConnection *connection,
const char *sender,
GDBusMethodInvocation *invocation,
GVariant *parameters)
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(obj);
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
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMAuthChain *chain;
const char *checkpoint_path;
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
g_variant_get(parameters, "(&ou)", &checkpoint_path, &add_timeout);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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
core: add nm_manager_get_dns_manager() getter nm_dns_manager_get() is already a singleton. So users usually can just get it whenever they need -- except during shutdown after the singleton was destroyed. This is usually fine, because users really should not try to get it late during shutdown. However, if you subscribe a signal handler on the singleton, then you will also eventually want to unsubscribe it. While the moment when you subscribe it is clearly not during late-shutdown, it's not clear how to ensure that the signal listener gets destroyed before the DNS manager singleton. So usually, whenever you are going to subscribe a signal, you need to make sure that the target object stays alive long enough. Which may mean to keep a reference to it. Next, we will have NMDevice subscribe to the singleton. With above said, that would mean that potentially every NMDevice needs to keep a reference to the NMDnsManager. That is not best. Also, later NMManager will face the same problem, because it will also subscribe to NMDnsManager. So, instead let NMManager own a reference to the NMDnsManager. This ensures the lifetimes are properly guarded (NMDevice also references NMManager already). Also, access nm_dns_manager_get() lazy on first use, to only initialize it when needed the first time (which might be quite late).
2022-04-08 11:40:42 +02:00
NMDnsManager *
nm_manager_get_dns_manager(NMManager *self)
{
NMManagerPrivate *priv;
g_return_val_if_fail(NM_IS_MANAGER(self), NULL);
priv = NM_MANAGER_GET_PRIVATE(self);
if (G_UNLIKELY(!priv->dns_mgr)) {
/* Initialize lazily on first use.
*
* But keep a reference. This is to ensure proper lifetimes between
* singleton instances (i.e. nm_dns_manager_get() outlives NMManager). */
priv->dns_mgr = g_object_ref(nm_dns_manager_get());
}
return priv->dns_mgr;
}
/*****************************************************************************/
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
}
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01: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: unblock OVS interfaces when the ovsdb is ready OVS system interfaces can start to connect even before the ovsdb is ready. However, the connection attempt is doomed to fail and the NMSettingsConnection gets blocked with reason FAILED. Unblock them once the ovsdb is ready. Ideally, NMPolicy should subscribe to the NMOvsdb::ready signal, however NMOvsdb is in a plugin, so it's easier if NMOvsdb directly calls a function of the core.
2021-01-25 15:02:35 +01:00
void
nm_manager_unblock_failed_ovs_interfaces(NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
nm_policy_unblock_failed_ovs_interfaces(priv->policy);
}
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));
core: add and indicate NM_CAPABILITY_OVS capability on D-Bus https://bugzilla.redhat.com/show_bug.cgi?id=1785147
2019-12-20 17:52:34 +01:00
if (cap < 1 || cap > _NM_CAPABILITY_MAX)
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_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
glib-aux: rename nm_utils_array_find_binary_search() to nm_array_bsearch() The "nm_utils_" prefix is just too verbose. Drop it. Also, Posix has a bsearch function. As this function is similar, rename it. Note that currently the arguments are provided in differnt order from bsearch(). That will be partly addressed next. That is the main reason for the rename. The next commit will swap the arguments, so do a rename first to get a compilation error when backporting a patch that uses the changed API.
2022-09-27 09:08:35 +02:00
idx = nm_array_find_bsearch(nm_g_array_index_p(priv->capabilities, guint32, 0),
priv->capabilities->len,
glib-aux: swap arguments for nm_array_find_bsearch() Have "len" before "elem_size". That is consistent with g_qsort_with_data() and bsearch(), and is also what I would expect. Note that the previous commit just renamed the function. If a user of the new, changed API gets backported to an older branch, we will get a compilation error and note that the arguments need to be adjusted.
2022-09-27 09:14:30 +02:00
sizeof(guint32),
glib-aux: rename nm_utils_array_find_binary_search() to nm_array_bsearch() The "nm_utils_" prefix is just too verbose. Drop it. Also, Posix has a bsearch function. As this function is similar, rename it. Note that currently the arguments are provided in differnt order from bsearch(). That will be partly addressed next. That is the main reason for the rename. The next commit will swap the arguments, so do a rename first to get a compilation error when backporting a patch that uses the changed API.
2022-09-27 09:08:35 +02:00
&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
}
core: add 'device-ifindex-changed' signal NMManager now emits a 'device-ifindex-changed' whenever a device ifindex gets changed. https://bugzilla.redhat.com/show_bug.cgi?id=1870691 Signed-off-by: Antonio Cardace <acardace@redhat.com>
2021-01-19 18:57:58 +01:00
void
nm_manager_emit_device_ifindex_changed(NMManager *self, NMDevice *device)
{
g_signal_emit(self, signals[DEVICE_IFINDEX_CHANGED], 0, device);
}
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
G_OBJECT_CLASS(nm_manager_parent_class)->constructed(object);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
settings: let NMSettings reference NMManager NMSettings needs access to the list of all devices, which is tracked by NMManager. Of course, this ties NMSettings and NMManager closer together. Note that NMManager already owns a reference to NMSettings, so they are in fact related. The alternatives of just letting NMSettings reference NMManager (and vice versa) would be more complicated, and likely not help to simplify the code (on the contrary).
2020-08-11 15:32:46 +02:00
priv->settings = nm_settings_new(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
nm_dbus_object_export(NM_DBUS_OBJECT(priv->settings));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
priv->hostname_manager = g_object_ref(nm_hostname_manager_get());
g_signal_connect(priv->hostname_manager,
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
"notify::" NM_HOSTNAME_MANAGER_STATIC_HOSTNAME,
G_CALLBACK(_static_hostname_changed_cb),
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
self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/rfkill: add "nm" prefix to RfKillState and RfKillType enums Names in header files should have an "nm" prefix. We do that pretty consistently. Fix the offenders RfKillState and RfKillType. Also, rename the RfKillState enums to follow the type name. For example, NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED. Also, when we camel-case a typedef (NMRfKillState) we would want that the lower-case names use underscore between the words. So it should be `nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution here is to also rename "RfKill" to "Rfkill". That make is consistent with the spelling of the existing `NMRfkillManager` type and the `nm-rfkill-manager.h` file.
2022-02-01 20:21:34 +01:00
priv->radio_states[NM_RFKILL_TYPE_WLAN].user_enabled = state->wifi_enabled;
priv->radio_states[NM_RFKILL_TYPE_WWAN].user_enabled = state->wwan_enabled;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
*/
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update_system(self,
NM_RFKILL_TYPE_WLAN,
priv->radio_states[NM_RFKILL_TYPE_WLAN].user_enabled);
_rfkill_update_system(self,
NM_RFKILL_TYPE_WWAN,
priv->radio_states[NM_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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GFile *file;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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_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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
priv->radio_states[NM_RFKILL_TYPE_WLAN] = (RfkillRadioState){
core/rfkill: cleanup rfkill handling in NMManager - use "const RadioState" where possible - use "bool" bitfields in RadioState (boolean flags in structs should be `bool` types for consistency) and order fields by alignment. - break lines for variable declaration in manager_rfkill_update_one_type(). - return (and nm_assert()) from update_rstate_from_rfkill(). By not adding a default case, compiler would warn if we forget to handle an enum value. We can easily do that, by just returning, and let the "default" case be handled by nm_assert_not_reached() -- which unlike g_warn_if_reached() compiles to nothing in release build. - add nm_assert() that `priv->radio_states[rtype]` is not out of range. - use designated initializers for priv->radio_states[].
2022-02-01 20:07:18 +01:00
.user_enabled = TRUE,
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
.sw_enabled = FALSE,
core/rfkill: cleanup rfkill handling in NMManager - use "const RadioState" where possible - use "bool" bitfields in RadioState (boolean flags in structs should be `bool` types for consistency) and order fields by alignment. - break lines for variable declaration in manager_rfkill_update_one_type(). - return (and nm_assert()) from update_rstate_from_rfkill(). By not adding a default case, compiler would warn if we forget to handle an enum value. We can easily do that, by just returning, and let the "default" case be handled by nm_assert_not_reached() -- which unlike g_warn_if_reached() compiles to nothing in release build. - add nm_assert() that `priv->radio_states[rtype]` is not out of range. - use designated initializers for priv->radio_states[].
2022-02-01 20:07:18 +01:00
.hw_enabled = TRUE,
core: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
.os_owner = TRUE,
core/rfkill: cleanup rfkill handling in NMManager - use "const RadioState" where possible - use "bool" bitfields in RadioState (boolean flags in structs should be `bool` types for consistency) and order fields by alignment. - break lines for variable declaration in manager_rfkill_update_one_type(). - return (and nm_assert()) from update_rstate_from_rfkill(). By not adding a default case, compiler would warn if we forget to handle an enum value. We can easily do that, by just returning, and let the "default" case be handled by nm_assert_not_reached() -- which unlike g_warn_if_reached() compiles to nothing in release build. - add nm_assert() that `priv->radio_states[rtype]` is not out of range. - use designated initializers for priv->radio_states[].
2022-02-01 20:07:18 +01:00
};
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
priv->radio_states[NM_RFKILL_TYPE_WWAN] = (RfkillRadioState){
core/rfkill: cleanup rfkill handling in NMManager - use "const RadioState" where possible - use "bool" bitfields in RadioState (boolean flags in structs should be `bool` types for consistency) and order fields by alignment. - break lines for variable declaration in manager_rfkill_update_one_type(). - return (and nm_assert()) from update_rstate_from_rfkill(). By not adding a default case, compiler would warn if we forget to handle an enum value. We can easily do that, by just returning, and let the "default" case be handled by nm_assert_not_reached() -- which unlike g_warn_if_reached() compiles to nothing in release build. - add nm_assert() that `priv->radio_states[rtype]` is not out of range. - use designated initializers for priv->radio_states[].
2022-02-01 20:07:18 +01:00
.user_enabled = TRUE,
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
.sw_enabled = FALSE,
core/rfkill: cleanup rfkill handling in NMManager - use "const RadioState" where possible - use "bool" bitfields in RadioState (boolean flags in structs should be `bool` types for consistency) and order fields by alignment. - break lines for variable declaration in manager_rfkill_update_one_type(). - return (and nm_assert()) from update_rstate_from_rfkill(). By not adding a default case, compiler would warn if we forget to handle an enum value. We can easily do that, by just returning, and let the "default" case be handled by nm_assert_not_reached() -- which unlike g_warn_if_reached() compiles to nothing in release build. - add nm_assert() that `priv->radio_states[rtype]` is not out of range. - use designated initializers for priv->radio_states[].
2022-02-01 20:07:18 +01:00
.hw_enabled = TRUE,
core: teach nm-manager about os_owner Reflect what the rfkill-manager saw in the nm-manager. This will allow to take decision based on the os_owner state.
2022-02-16 15:54:44 +02:00
.os_owner = TRUE,
core/rfkill: cleanup rfkill handling in NMManager - use "const RadioState" where possible - use "bool" bitfields in RadioState (boolean flags in structs should be `bool` types for consistency) and order fields by alignment. - break lines for variable declaration in manager_rfkill_update_one_type(). - return (and nm_assert()) from update_rstate_from_rfkill(). By not adding a default case, compiler would warn if we forget to handle an enum value. We can easily do that, by just returning, and let the "default" case be handled by nm_assert_not_reached() -- which unlike g_warn_if_reached() compiles to nothing in release build. - add nm_assert() that `priv->radio_states[rtype]` is not out of range. - use designated initializers for priv->radio_states[].
2022-02-01 20:07:18 +01:00
};
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
priv->sleeping = FALSE;
priv->state = NM_STATE_DISCONNECTED;
priv->startup = TRUE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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, G_CALLBACK(sleeping_cb), self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* 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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
if (priv->fw_monitor) {
g_signal_connect(priv->fw_monitor, "changed", G_CALLBACK(firmware_dir_changed), self);
manager: use logging helpers
2016-03-02 11:38:26 +01:00
_LOGI(LOGD_CORE, "monitoring 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
} 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
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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, GValue *value, GParamSpec *pspec)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(object);
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
NMConfigData *config_data;
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
const NMGlobalDnsConfig *dns_config;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *type;
const char *path;
NMActiveConnection *ac;
GPtrArray *ptrarr;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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,
all: use nm_g_variant_new_au() helper
2021-04-15 09:43:42 +02:00
nm_g_variant_new_au((const guint32 *) priv->capabilities->data,
priv->capabilities->len));
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:
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
g_value_set_boolean(value, _rfkill_radio_state_get(self, NM_RFKILL_TYPE_WLAN));
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:
core/rfkill: add "nm" prefix to RfKillState and RfKillType enums Names in header files should have an "nm" prefix. We do that pretty consistently. Fix the offenders RfKillState and RfKillType. Also, rename the RfKillState enums to follow the type name. For example, NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED. Also, when we camel-case a typedef (NMRfKillState) we would want that the lower-case names use underscore between the words. So it should be `nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution here is to also rename "RfKill" to "Rfkill". That make is consistent with the spelling of the existing `NMRfkillManager` type and the `nm-rfkill-manager.h` file.
2022-02-01 20:21:34 +01:00
g_value_set_boolean(value, priv->radio_states[NM_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:
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
g_value_set_boolean(value, _rfkill_radio_state_get(self, NM_RFKILL_TYPE_WWAN));
manager: add WWAN enable/disable support
2009-12-23 00:18:18 -08:00
break;
case PROP_WWAN_HARDWARE_ENABLED:
core/rfkill: add "nm" prefix to RfKillState and RfKillType enums Names in header files should have an "nm" prefix. We do that pretty consistently. Fix the offenders RfKillState and RfKillType. Also, rename the RfKillState enums to follow the type name. For example, NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED. Also, when we camel-case a typedef (NMRfKillState) we would want that the lower-case names use underscore between the words. So it should be `nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution here is to also rename "RfKill" to "Rfkill". That make is consistent with the spelling of the existing `NMRfkillManager` type and the `nm-rfkill-manager.h` file.
2022-02-01 20:21:34 +01:00
g_value_set_boolean(value, priv->radio_states[NM_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;
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
case PROP_RADIO_FLAGS:
g_value_set_uint(value, priv->radio_flags);
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();
core: reverse the order of active connections in the manager When a new active connection is created, it gets added at the beginning of manager's list. This means that the list contains most recently activated connections first. Since the list is doubly-linked, it is possible to efficiently iterate in both directions, so the order of the list is mostly a matter of convention. I think it is preferable to have oldest active connections at the beginning of the list; let's reverse the order. In most places where the list is iterated, the order doesn't matter. Where it does, use the *_prev() variant to maintain the old iteration order.
2020-11-04 13:53:57 +01:00
c_list_for_each_entry_prev (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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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:
all: unify and rename strv helper API Naming is important, because the name of a thing should give you a good idea what it does. Also, to find a thing, it needs a good name in the first place. But naming is also hard. Historically, some strv helper API was named as nm_utils_strv_*(), and some API had a leading underscore (as it is internal API). This was all inconsistent. Do some renaming and try to unify things. We get rid of the leading underscore if this is just a regular (internal) helper. But not for example from _nm_strv_find_first(), because that is the implementation of nm_strv_find_first(). - _nm_utils_strv_cleanup() -> nm_strv_cleanup() - _nm_utils_strv_cleanup_const() -> nm_strv_cleanup_const() - _nm_utils_strv_cmp_n() -> _nm_strv_cmp_n() - _nm_utils_strv_dup() -> _nm_strv_dup() - _nm_utils_strv_dup_packed() -> _nm_strv_dup_packed() - _nm_utils_strv_find_first() -> _nm_strv_find_first() - _nm_utils_strv_sort() -> _nm_strv_sort() - _nm_utils_strv_to_ptrarray() -> nm_strv_to_ptrarray() - _nm_utils_strv_to_slist() -> nm_strv_to_gslist() - nm_utils_strv_cmp_n() -> nm_strv_cmp_n() - nm_utils_strv_dup() -> nm_strv_dup() - nm_utils_strv_dup_packed() -> nm_strv_dup_packed() - nm_utils_strv_dup_shallow_maybe_a() -> nm_strv_dup_shallow_maybe_a() - nm_utils_strv_equal() -> nm_strv_equal() - nm_utils_strv_find_binary_search() -> nm_strv_find_binary_search() - nm_utils_strv_find_first() -> nm_strv_find_first() - nm_utils_strv_make_deep_copied() -> nm_strv_make_deep_copied() - nm_utils_strv_make_deep_copied_n() -> nm_strv_make_deep_copied_n() - nm_utils_strv_make_deep_copied_nonnull() -> nm_strv_make_deep_copied_nonnull() - nm_utils_strv_sort() -> nm_strv_sort() Note that no names are swapped and none of the new names existed previously. That means, all the new names are really new, which simplifies to find errors due to this larger refactoring. E.g. if you backport a patch from after this change to an old branch, you'll get a compiler error and notice that something is missing.
2021-07-29 10:02:11 +02:00
g_value_take_boxed(value, nm_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:
all: unify and rename strv helper API Naming is important, because the name of a thing should give you a good idea what it does. Also, to find a thing, it needs a good name in the first place. But naming is also hard. Historically, some strv helper API was named as nm_utils_strv_*(), and some API had a leading underscore (as it is internal API). This was all inconsistent. Do some renaming and try to unify things. We get rid of the leading underscore if this is just a regular (internal) helper. But not for example from _nm_strv_find_first(), because that is the implementation of nm_strv_find_first(). - _nm_utils_strv_cleanup() -> nm_strv_cleanup() - _nm_utils_strv_cleanup_const() -> nm_strv_cleanup_const() - _nm_utils_strv_cmp_n() -> _nm_strv_cmp_n() - _nm_utils_strv_dup() -> _nm_strv_dup() - _nm_utils_strv_dup_packed() -> _nm_strv_dup_packed() - _nm_utils_strv_find_first() -> _nm_strv_find_first() - _nm_utils_strv_sort() -> _nm_strv_sort() - _nm_utils_strv_to_ptrarray() -> nm_strv_to_ptrarray() - _nm_utils_strv_to_slist() -> nm_strv_to_gslist() - nm_utils_strv_cmp_n() -> nm_strv_cmp_n() - nm_utils_strv_dup() -> nm_strv_dup() - nm_utils_strv_dup_packed() -> nm_strv_dup_packed() - nm_utils_strv_dup_shallow_maybe_a() -> nm_strv_dup_shallow_maybe_a() - nm_utils_strv_equal() -> nm_strv_equal() - nm_utils_strv_find_binary_search() -> nm_strv_find_binary_search() - nm_utils_strv_find_first() -> nm_strv_find_first() - nm_utils_strv_make_deep_copied() -> nm_strv_make_deep_copied() - nm_utils_strv_make_deep_copied_n() -> nm_strv_make_deep_copied_n() - nm_utils_strv_make_deep_copied_nonnull() -> nm_strv_make_deep_copied_nonnull() - nm_utils_strv_sort() -> nm_strv_sort() Note that no names are swapped and none of the new names existed previously. That means, all the new names are really new, which simplifies to find errors due to this larger refactoring. E.g. if you backport a patch from after this change to an old branch, you'll get a compiler error and notice that something is missing.
2021-07-29 10:02:11 +02:00
g_value_take_boxed(value, nm_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,
all: unify and rename strv helper API Naming is important, because the name of a thing should give you a good idea what it does. Also, to find a thing, it needs a good name in the first place. But naming is also hard. Historically, some strv helper API was named as nm_utils_strv_*(), and some API had a leading underscore (as it is internal API). This was all inconsistent. Do some renaming and try to unify things. We get rid of the leading underscore if this is just a regular (internal) helper. But not for example from _nm_strv_find_first(), because that is the implementation of nm_strv_find_first(). - _nm_utils_strv_cleanup() -> nm_strv_cleanup() - _nm_utils_strv_cleanup_const() -> nm_strv_cleanup_const() - _nm_utils_strv_cmp_n() -> _nm_strv_cmp_n() - _nm_utils_strv_dup() -> _nm_strv_dup() - _nm_utils_strv_dup_packed() -> _nm_strv_dup_packed() - _nm_utils_strv_find_first() -> _nm_strv_find_first() - _nm_utils_strv_sort() -> _nm_strv_sort() - _nm_utils_strv_to_ptrarray() -> nm_strv_to_ptrarray() - _nm_utils_strv_to_slist() -> nm_strv_to_gslist() - nm_utils_strv_cmp_n() -> nm_strv_cmp_n() - nm_utils_strv_dup() -> nm_strv_dup() - nm_utils_strv_dup_packed() -> nm_strv_dup_packed() - nm_utils_strv_dup_shallow_maybe_a() -> nm_strv_dup_shallow_maybe_a() - nm_utils_strv_equal() -> nm_strv_equal() - nm_utils_strv_find_binary_search() -> nm_strv_find_binary_search() - nm_utils_strv_find_first() -> nm_strv_find_first() - nm_utils_strv_make_deep_copied() -> nm_strv_make_deep_copied() - nm_utils_strv_make_deep_copied_n() -> nm_strv_make_deep_copied_n() - nm_utils_strv_make_deep_copied_nonnull() -> nm_strv_make_deep_copied_nonnull() - nm_utils_strv_sort() -> nm_strv_sort() Note that no names are swapped and none of the new names existed previously. That means, all the new names are really new, which simplifies to find errors due to this larger refactoring. E.g. if you backport a patch from after this change to an old branch, you'll get a compiler error and notice that something is missing.
2021-07-29 10:02:11 +02:00
priv->checkpoint_mgr ? nm_strv_make_deep_copied(
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
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, 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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01: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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError *error = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
switch (prop_id) {
case PROP_WIRELESS_ENABLED:
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update_from_user(NM_MANAGER(object),
NM_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:
core/rfkill: rename Rfkill related functions in "nm-manager.c" Naming is important. Especially when we have a 8k LOC monster, that manages everything. Rename things related to Rfkill to give them a common prefix. Also, move code around so it's beside each other.
2022-02-01 22:19:36 +01:00
_rfkill_update_from_user(NM_MANAGER(object),
NM_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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
nm_global_dns_config_free(dns_config);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: export DNS global configuration D-Bus property
2015-07-03 11:06:39 +02:00
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
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMManager *self = NM_MANAGER(object);
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
CList *iter;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
nm_assert(c_list_is_empty(&priv->async_op_lst_head));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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);
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
g_source_remove(data->idle_id);
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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->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
nm_auth_chain_destroy(nm_auth_chain_parent_lst_entry(iter));
nm_clear_g_source(&priv->devices_inited_id);
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
nm_clear_pointer(&priv->checkpoint_mgr, nm_checkpoint_manager_free);
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
if (priv->concheck_mgr) {
g_signal_handlers_disconnect_by_func(priv->concheck_mgr,
G_CALLBACK(concheck_config_changed_cb),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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
g_clear_object(&priv->concheck_mgr);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
core: delay startup complete while we have pending DNS updates While we have DNS updates pending, we cannot reach startup complete.
2022-04-08 12:01:51 +02:00
nm_clear_g_signal_handler(priv->dns_mgr, &priv->dns_mgr_update_pending_signal_id);
core: add nm_manager_get_dns_manager() getter nm_dns_manager_get() is already a singleton. So users usually can just get it whenever they need -- except during shutdown after the singleton was destroyed. This is usually fine, because users really should not try to get it late during shutdown. However, if you subscribe a signal handler on the singleton, then you will also eventually want to unsubscribe it. While the moment when you subscribe it is clearly not during late-shutdown, it's not clear how to ensure that the signal listener gets destroyed before the DNS manager singleton. So usually, whenever you are going to subscribe a signal, you need to make sure that the target object stays alive long enough. Which may mean to keep a reference to it. Next, we will have NMDevice subscribe to the singleton. With above said, that would mean that potentially every NMDevice needs to keep a reference to the NMDnsManager. That is not best. Also, later NMManager will face the same problem, because it will also subscribe to NMDnsManager. So, instead let NMManager own a reference to the NMDnsManager. This ensures the lifetimes are properly guarded (NMDevice also references NMManager already). Also, access nm_dns_manager_get() lazy on first use, to only initialize it when needed the first time (which might be quite late).
2022-04-08 11:40:42 +02:00
g_clear_object(&priv->dns_mgr);
all: use nm_clear_pointer() instead of g_clear_pointer() g_clear_pointer() would always cast the destroy notify function pointer to GDestroyNotify. That means, it lost some type safety, like GPtrArray *ptr_arr = ... g_clear_pointer (&ptr_arr, g_array_unref); Since glib 2.58 ([1]), g_clear_pointer() is also more type safe. But this is not used by NetworkManager, because we don't set GLIB_VERSION_MIN_REQUIRED to 2.58. [1] https://gitlab.gnome.org/GNOME/glib/-/commit/f9a9902aac826ab4aecc25f6eb533a418a4fa559 We have nm_clear_pointer() to avoid this issue for a long time (pre 1.12.0). Possibly we should redefine in our source tree g_clear_pointer() as nm_clear_pointer(). However, I don't like to patch glib functions with our own variant. Arguably, we do patch g_clear_error() in such a manner. But there the point is to make the function inlinable. Also, nm_clear_pointer() returns a boolean that indicates whether anything was cleared. That is sometimes useful. I think we should just consistently use nm_clear_pointer() instead, which does always the preferable thing. Replace: sed 's/\<g_clear_pointer *(\([^;]*\), *\([a-z_A-Z0-9]\+\) *)/nm_clear_pointer (\1, \2)/g' $(git grep -l g_clear_pointer) -i
2020-03-23 11:09:24 +01:00
if (priv->auth_mgr) {
g_signal_handlers_disconnect_by_func(priv->auth_mgr, G_CALLBACK(auth_mgr_changed), self);
g_clear_object(&priv->auth_mgr);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
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
nm_assert(c_list_is_empty(&priv->devices_lst_head));
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
nm_clear_g_source(&priv->ac_cleanup_id);
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
while ((iter = c_list_first(&priv->active_connections_lst_head)))
active_connection_remove(self,
c_list_entry(iter, NMActiveConnection, active_connections_lst));
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_assert(c_list_is_empty(&priv->active_connections_lst_head));
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
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
if (priv->config) {
g_signal_handlers_disconnect_by_func(priv->config, _config_changed_cb, self);
g_clear_object(&priv->config);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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 (priv->policy) {
g_signal_handlers_disconnect_by_func(priv->policy, policy_default_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_signal_handlers_disconnect_by_func(priv->policy, policy_activating_ac_changed, self);
g_clear_object(&priv->policy);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
if (priv->settings) {
g_signal_handlers_disconnect_by_func(priv->settings,
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
settings_startup_complete_changed,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
self);
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
g_signal_handlers_disconnect_by_func(priv->settings,
system_unmanaged_devices_changed_cb,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
self);
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
g_signal_handlers_disconnect_by_func(priv->settings, connection_added_cb, self);
g_signal_handlers_disconnect_by_func(priv->settings, connection_updated_cb, self);
g_signal_handlers_disconnect_by_func(priv->settings, connection_flags_changed, self);
config: implement reloading of connectivity parameters
2015-01-30 19:52:53 +01:00
g_clear_object(&priv->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
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->hostname_manager) {
core: rename related things explicitly to "static-hostname" We have at least static and transient hostnames. Let's be clear which one we are talking about. Note that also NM_SETTINGS_HOSTNAME gets renamed to NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer. The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing property for the "Hostname" D-Bus property for the NMDBusObject glue. So, while the new name makes more sense to me, it's now also inconsistent with it's primary use (the D-Bus property). Still...
2022-01-04 18:28:46 +01:00
g_signal_handlers_disconnect_by_func(priv->hostname_manager,
_static_hostname_changed_cb,
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->hostname_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: 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->vpn_manager);
manager: make "nmcli net off" wait for deactivations The current behavior of "nmcli networking off" is that it starts disconnecting the devices, but doesn't wait for them to actually come down. That is not too helpful: the user never knows when the network is actually disconnected. Some users, notably the NetworkManager-CI test suite, seem to expect the devices are all disconnected after the command finishes. Even worse, it immediately proceeds activating the connections: @ovs_cloned_mac_set_on_iface ... * Execute "nmcli networking off && nmcli networking on" This results in pure utter chaos. In particular, the slave connections sometimes refuse to activate after "nmcli networking on", because the master connections are still getting disconnected in response to preceding "nmcli networking off". Let's make Enable(FALSE) and Sleep(TRUE) block until none of the devices are expected to go down. Note that this makes those call also return when Enable(TRUE) and Sleep(FALSE) is issued in meanwhile. Therefore a return from Enable(FALSE) doesn't necessarily imply the networking is disabled. This is a feature, not a bug -- the actual manager state is available in the "state" property. Fixes-test: @ovs_cloned_mac_set_on_iface https://bugzilla.redhat.com/show_bug.cgi?id=2093175 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1292
2022-07-11 16:06:14 +02:00
if (priv->sleep_devices) {
sleep_devices_clear(self);
nm_clear_pointer(&priv->sleep_devices, g_hash_table_unref);
}
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
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->sleep_monitor) {
g_signal_handlers_disconnect_by_func(priv->sleep_monitor, sleeping_cb, self);
g_clear_object(&priv->sleep_monitor);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
if (priv->fw_monitor) {
all: use nm_clear_pointer() instead of g_clear_pointer() g_clear_pointer() would always cast the destroy notify function pointer to GDestroyNotify. That means, it lost some type safety, like GPtrArray *ptr_arr = ... g_clear_pointer (&ptr_arr, g_array_unref); Since glib 2.58 ([1]), g_clear_pointer() is also more type safe. But this is not used by NetworkManager, because we don't set GLIB_VERSION_MIN_REQUIRED to 2.58. [1] https://gitlab.gnome.org/GNOME/glib/-/commit/f9a9902aac826ab4aecc25f6eb533a418a4fa559 We have nm_clear_pointer() to avoid this issue for a long time (pre 1.12.0). Possibly we should redefine in our source tree g_clear_pointer() as nm_clear_pointer(). However, I don't like to patch glib functions with our own variant. Arguably, we do patch g_clear_error() in such a manner. But there the point is to make the function inlinable. Also, nm_clear_pointer() returns a boolean that indicates whether anything was cleared. That is sometimes useful. I think we should just consistently use nm_clear_pointer() instead, which does always the preferable thing. Replace: sed 's/\<g_clear_pointer *(\([^;]*\), *\([a-z_A-Z0-9]\+\) *)/nm_clear_pointer (\1, \2)/g' $(git grep -l g_clear_pointer) -i
2020-03-23 11:09:24 +01:00
g_signal_handlers_disconnect_by_func(priv->fw_monitor, firmware_dir_changed, 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
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
nm_clear_g_source(&priv->fw_changed_id);
core: add permissions framework for various operations (rh #585182) (bgo #619323)
2010-05-28 18:23:00 -07:00
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
g_file_monitor_cancel(priv->fw_monitor);
g_clear_object(&priv->fw_monitor);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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
if (priv->rfkill_mgr) {
g_signal_handlers_disconnect_by_func(priv->rfkill_mgr,
rfkill_manager_rfkill_changed_cb,
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
self);
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
g_clear_object(&priv->rfkill_mgr);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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
nm_clear_g_source(&priv->delete_volatile_connection_idle_id);
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
_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));
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/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: cleanup NMRfkillManager in dispose() Fixes: b15fb8641e26eb63c2d83d9dcc9510705086e2f2
2015-09-21 14:38:25 +02:00
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->timestamp_update_id);
manager/trivial: rename self variable in NMManager:dispose()
2017-09-29 15:18:48 +02:00
nm_clear_pointer(&priv->device_route_metrics, g_hash_table_destroy);
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
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)
{
all: drop explicit casts from _GET_PRIVATE() macro calls The _GET_PRIVATE() macros are all implemented based on _NM_GET_PRIVATE(). That macro tries to be more type safe and uses _Generic() to do the right thing. Explicitly casting is not only unnecessary, it defeats these (static) type checks. Don't do that.
2020-02-14 10:50:25 +01:00
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE(object);
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
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",
manager: fix typo in 'PrimaryConnectionType' D-Bus property name Fixes: 297d4985abcc7b571b8c090ee90622357fc60e16
2018-06-22 15:53:46 +02:00
.in_args = NM_DEFINE_GDBUS_ARG_INFOS(NM_DEFINE_GDBUS_ARG_INFO("iface", "s"), ),
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_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(
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_GDBUS_ARG_INFO("path", "o"),
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_GDBUS_ARG_INFO("active_connection", "o"), ), ),
.handle = impl_manager_add_and_activate_connection, ),
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"),
NM_DEFINE_GDBUS_ARG_INFO("result", "a{sv}"), ), ),
.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(
"DeactivateConnection",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS(
NM_DEFINE_GDBUS_ARG_INFO("active_connection", "o"), ), ),
.handle = impl_manager_deactivate_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(
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_GDBUS_METHOD_INFO_INIT("Sleep",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS(
NM_DEFINE_GDBUS_ARG_INFO("sleep", "b"), ), ),
.handle = impl_manager_sleep, ),
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(
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_GDBUS_METHOD_INFO_INIT("Enable",
.in_args = NM_DEFINE_GDBUS_ARG_INFOS(
NM_DEFINE_GDBUS_ARG_INFO("enable", "b"), ), ),
.handle = impl_manager_enable, ),
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(
"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, ),
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: drop deprecated PropertiesChanged D-Bus signal (API BREAK) D-Bus 1.3.1 (2010) introduced the standard "PropertiesChanged" signal on "org.freedesktop.DBus.Properties". NetworkManager is old, and predates this API. From that time, it still had it's own PropertiesChanged signal that are emitted together with the standard ones. NetworkManager supports the standard PropertiesChanged signal since it switched to gdbus library in version 1.2.0 (2016). These own signals are deprecated for a long time already ([1], 2016), and are hopefully not used by anybody anymore. libnm-glib was using them and relied on them, but that library is gone. libnm does not use them and neither does plasma-nm. Hopefully no users are left that are affected by this API break. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commits/6fb917178aa19c61e909957f5146aa4565e0cb2f
2021-05-12 18:18:57 +02:00
.signals = NM_DEFINE_GDBUS_SIGNAL_INFOS(&signal_info_check_permissions,
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
&signal_info_state_changed,
&signal_info_device_added,
&signal_info_device_removed, ),
.properties = NM_DEFINE_GDBUS_PROPERTY_INFOS(
core: drop deprecated PropertiesChanged D-Bus signal (API BREAK) D-Bus 1.3.1 (2010) introduced the standard "PropertiesChanged" signal on "org.freedesktop.DBus.Properties". NetworkManager is old, and predates this API. From that time, it still had it's own PropertiesChanged signal that are emitted together with the standard ones. NetworkManager supports the standard PropertiesChanged signal since it switched to gdbus library in version 1.2.0 (2016). These own signals are deprecated for a long time already ([1], 2016), and are hopefully not used by anybody anymore. libnm-glib was using them and relied on them, but that library is gone. libnm does not use them and neither does plasma-nm. Hopefully no users are left that are affected by this API break. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commits/6fb917178aa19c61e909957f5146aa4565e0cb2f
2021-05-12 18:18:57 +02:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("Devices", "ao", NM_MANAGER_DEVICES),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("AllDevices",
"ao",
NM_MANAGER_ALL_DEVICES),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("Checkpoints",
"ao",
NM_MANAGER_CHECKPOINTS),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("NetworkingEnabled",
"b",
NM_MANAGER_NETWORKING_ENABLED),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READWRITABLE(
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
"WirelessEnabled",
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
"b",
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_MANAGER_WIRELESS_ENABLED,
NM_AUTH_PERMISSION_ENABLE_DISABLE_WIFI,
NM_AUDIT_OP_RADIO_CONTROL),
core: drop deprecated PropertiesChanged D-Bus signal (API BREAK) D-Bus 1.3.1 (2010) introduced the standard "PropertiesChanged" signal on "org.freedesktop.DBus.Properties". NetworkManager is old, and predates this API. From that time, it still had it's own PropertiesChanged signal that are emitted together with the standard ones. NetworkManager supports the standard PropertiesChanged signal since it switched to gdbus library in version 1.2.0 (2016). These own signals are deprecated for a long time already ([1], 2016), and are hopefully not used by anybody anymore. libnm-glib was using them and relied on them, but that library is gone. libnm does not use them and neither does plasma-nm. Hopefully no users are left that are affected by this API break. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commits/6fb917178aa19c61e909957f5146aa4565e0cb2f
2021-05-12 18:18:57 +02:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("WirelessHardwareEnabled",
"b",
NM_MANAGER_WIRELESS_HARDWARE_ENABLED),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READWRITABLE(
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
"WwanEnabled",
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
"b",
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_MANAGER_WWAN_ENABLED,
NM_AUTH_PERMISSION_ENABLE_DISABLE_WWAN,
NM_AUDIT_OP_RADIO_CONTROL),
core: drop deprecated PropertiesChanged D-Bus signal (API BREAK) D-Bus 1.3.1 (2010) introduced the standard "PropertiesChanged" signal on "org.freedesktop.DBus.Properties". NetworkManager is old, and predates this API. From that time, it still had it's own PropertiesChanged signal that are emitted together with the standard ones. NetworkManager supports the standard PropertiesChanged signal since it switched to gdbus library in version 1.2.0 (2016). These own signals are deprecated for a long time already ([1], 2016), and are hopefully not used by anybody anymore. libnm-glib was using them and relied on them, but that library is gone. libnm does not use them and neither does plasma-nm. Hopefully no users are left that are affected by this API break. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commits/6fb917178aa19c61e909957f5146aa4565e0cb2f
2021-05-12 18:18:57 +02:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("WwanHardwareEnabled",
"b",
NM_MANAGER_WWAN_HARDWARE_ENABLED),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READWRITABLE(
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
"WimaxEnabled",
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
"b",
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_MANAGER_WIMAX_ENABLED,
NM_AUTH_PERMISSION_ENABLE_DISABLE_WIMAX,
NM_AUDIT_OP_RADIO_CONTROL),
core: drop deprecated PropertiesChanged D-Bus signal (API BREAK) D-Bus 1.3.1 (2010) introduced the standard "PropertiesChanged" signal on "org.freedesktop.DBus.Properties". NetworkManager is old, and predates this API. From that time, it still had it's own PropertiesChanged signal that are emitted together with the standard ones. NetworkManager supports the standard PropertiesChanged signal since it switched to gdbus library in version 1.2.0 (2016). These own signals are deprecated for a long time already ([1], 2016), and are hopefully not used by anybody anymore. libnm-glib was using them and relied on them, but that library is gone. libnm does not use them and neither does plasma-nm. Hopefully no users are left that are affected by this API break. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commits/6fb917178aa19c61e909957f5146aa4565e0cb2f
2021-05-12 18:18:57 +02:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("WimaxHardwareEnabled",
"b",
NM_MANAGER_WIMAX_HARDWARE_ENABLED),
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("RadioFlags",
"u",
NM_MANAGER_RADIO_FLAGS),
core: drop deprecated PropertiesChanged D-Bus signal (API BREAK) D-Bus 1.3.1 (2010) introduced the standard "PropertiesChanged" signal on "org.freedesktop.DBus.Properties". NetworkManager is old, and predates this API. From that time, it still had it's own PropertiesChanged signal that are emitted together with the standard ones. NetworkManager supports the standard PropertiesChanged signal since it switched to gdbus library in version 1.2.0 (2016). These own signals are deprecated for a long time already ([1], 2016), and are hopefully not used by anybody anymore. libnm-glib was using them and relied on them, but that library is gone. libnm does not use them and neither does plasma-nm. Hopefully no users are left that are affected by this API break. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commits/6fb917178aa19c61e909957f5146aa4565e0cb2f
2021-05-12 18:18:57 +02:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("ActiveConnections",
"ao",
NM_MANAGER_ACTIVE_CONNECTIONS),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("PrimaryConnection",
"o",
NM_MANAGER_PRIMARY_CONNECTION),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("PrimaryConnectionType",
"s",
NM_MANAGER_PRIMARY_CONNECTION_TYPE),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("Metered", "u", NM_MANAGER_METERED),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("ActivatingConnection",
"o",
NM_MANAGER_ACTIVATING_CONNECTION),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("Startup", "b", NM_MANAGER_STARTUP),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("Version", "s", NM_MANAGER_VERSION),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("Capabilities",
"au",
NM_MANAGER_CAPABILITIES),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("State", "u", NM_MANAGER_STATE),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("Connectivity",
"u",
NM_MANAGER_CONNECTIVITY),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("ConnectivityCheckAvailable",
"b",
NM_MANAGER_CONNECTIVITY_CHECK_AVAILABLE),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READWRITABLE(
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
"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: drop deprecated PropertiesChanged D-Bus signal (API BREAK) D-Bus 1.3.1 (2010) introduced the standard "PropertiesChanged" signal on "org.freedesktop.DBus.Properties". NetworkManager is old, and predates this API. From that time, it still had it's own PropertiesChanged signal that are emitted together with the standard ones. NetworkManager supports the standard PropertiesChanged signal since it switched to gdbus library in version 1.2.0 (2016). These own signals are deprecated for a long time already ([1], 2016), and are hopefully not used by anybody anymore. libnm-glib was using them and relied on them, but that library is gone. libnm does not use them and neither does plasma-nm. Hopefully no users are left that are affected by this API break. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commits/6fb917178aa19c61e909957f5146aa4565e0cb2f
2021-05-12 18:18:57 +02:00
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READWRITABLE(
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
"GlobalDnsConfiguration",
"a{sv}",
NM_MANAGER_GLOBAL_DNS_CONFIGURATION,
NM_AUTH_PERMISSION_SETTINGS_MODIFY_GLOBAL_DNS,
NM_AUDIT_OP_NET_CONTROL), ), ),
};
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: use nm-sudo symbols in NetworkManager binary for plugin The two nm-sudo helper functions are only used by the OVS device plugin, but they are part of NetworkManager core binary. This is done commonly, where the NetworkManager binary has symbols that are used by the plugins. But in this case, NetworkManager itself doesn't use the symbols. That will case the linker to drop them. A previous solution for that was commit 684f2acffea3 ('build: add way to keep unused symbols when linking NetworkManager'), but that doesn't seem to work with clang 3.4 (rhel-7). Instead, actually use the symbol so that it cannot be dropped.
2021-08-31 13:20:59 +02:00
#if WITH_OPENVSWITCH
/* Use the symbols. These symbols are in NetworkManager binary but will be
* used by the OVS device plugin. If we don't use the symbol here, it will
* be wrongly dropped. */
nm-sudo: rename to nm-priv-helper The name "nm-sudo" reminds of the "sudo" tool, and this is a bit confusing because it's not related. Rename the service to "nm-priv-helper", which stands for "NM privileged helper". https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/938
2021-12-13 16:06:16 +01:00
manager_class->_use_symbol_nm_priv_helper_call_get_fd =
(void (*)(void)) nm_priv_helper_call_get_fd;
manager_class->_use_symbol_nm_priv_helper_utils_open_fd =
(void (*)(void)) nm_priv_helper_utils_open_fd;
core: use nm-sudo symbols in NetworkManager binary for plugin The two nm-sudo helper functions are only used by the OVS device plugin, but they are part of NetworkManager core binary. This is done commonly, where the NetworkManager binary has symbols that are used by the plugins. But in this case, NetworkManager itself doesn't use the symbols. That will case the linker to drop them. A previous solution for that was commit 684f2acffea3 ('build: add way to keep unused symbols when linking NetworkManager'), but that doesn't seem to work with clang 3.4 (rhel-7). Instead, actually use the symbol so that it cannot be dropped.
2021-08-31 13:20:59 +02:00
#endif
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_STARTUP] = g_param_spec_boolean(NM_MANAGER_STARTUP,
"",
"",
TRUE,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_NETWORKING_ENABLED] =
g_param_spec_boolean(NM_MANAGER_NETWORKING_ENABLED,
"",
"",
TRUE,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_WIRELESS_ENABLED] =
g_param_spec_boolean(NM_MANAGER_WIRELESS_ENABLED,
"",
"",
TRUE,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_WIRELESS_HARDWARE_ENABLED] =
g_param_spec_boolean(NM_MANAGER_WIRELESS_HARDWARE_ENABLED,
"",
"",
TRUE,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_WWAN_ENABLED] =
g_param_spec_boolean(NM_MANAGER_WWAN_ENABLED,
"",
"",
TRUE,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_WWAN_HARDWARE_ENABLED] =
g_param_spec_boolean(NM_MANAGER_WWAN_HARDWARE_ENABLED,
"",
"",
TRUE,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_WIMAX_ENABLED] =
g_param_spec_boolean(NM_MANAGER_WIMAX_ENABLED,
"",
"",
TRUE,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_WIMAX_HARDWARE_ENABLED] =
g_param_spec_boolean(NM_MANAGER_WIMAX_HARDWARE_ENABLED,
"",
"",
TRUE,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
core: export radio flags Introduce a RadioFlags property on the manager object. For now it contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether any radio interface is present in the system. The presence of a radio is detected by looking at devices and rfkill switches. In future, any radio-related read-only boolean flag can be exposed via this property, including the already existing WirelessHardwareEnabled and WwanHardwareEnabled properties.
2022-03-21 10:19:37 +01:00
obj_properties[PROP_RADIO_FLAGS] = g_param_spec_uint(NM_MANAGER_RADIO_FLAGS,
"",
"",
0,
G_MAXUINT32,
NM_RADIO_FLAG_NONE,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_ACTIVE_CONNECTIONS] =
g_param_spec_boxed(NM_MANAGER_ACTIVE_CONNECTIONS,
"",
"",
G_TYPE_STRV,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_CONNECTIVITY] =
g_param_spec_uint(NM_MANAGER_CONNECTIVITY,
"",
"",
NM_CONNECTIVITY_UNKNOWN,
NM_CONNECTIVITY_FULL,
NM_CONNECTIVITY_UNKNOWN,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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_ENABLED] =
g_param_spec_boolean(NM_MANAGER_CONNECTIVITY_CHECK_ENABLED,
"",
"",
TRUE,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_PRIMARY_CONNECTION] =
g_param_spec_string(NM_MANAGER_PRIMARY_CONNECTION,
"",
"",
NULL,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_PRIMARY_CONNECTION_TYPE] =
g_param_spec_string(NM_MANAGER_PRIMARY_CONNECTION_TYPE,
"",
"",
NULL,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_ACTIVATING_CONNECTION] =
g_param_spec_string(NM_MANAGER_ACTIVATING_CONNECTION,
"",
"",
NULL,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_DEVICES] = g_param_spec_boxed(NM_MANAGER_DEVICES,
"",
"",
G_TYPE_STRV,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* signals */
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
/* emitted only for realized devices */
manager: use defines for signal names
2016-04-04 14:17:09 +02:00
signals[DEVICE_ADDED] = 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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* Emitted for both realized devices and placeholder devices */
manager: use defines for signal names
2016-04-04 14:17:09 +02:00
signals[INTERNAL_DEVICE_ADDED] = 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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03: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
/* 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 */
manager: use defines for signal names
2016-04-04 14:17:09 +02:00
signals[DEVICE_REMOVED] = 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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +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
/* Emitted for both realized devices and placeholder devices */
manager: use defines for signal names
2016-04-04 14:17:09 +02:00
signals[INTERNAL_DEVICE_REMOVED] = 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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
signals[ACTIVE_CONNECTION_ADDED] = 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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
signals[ACTIVE_CONNECTION_REMOVED] = 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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
manager: refactor handling GObject properties Use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() function.
2016-04-01 17:34:51 +02:00
signals[CONFIGURE_QUIT] = 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);
core: add 'device-ifindex-changed' signal NMManager now emits a 'device-ifindex-changed' whenever a device ifindex gets changed. https://bugzilla.redhat.com/show_bug.cgi?id=1870691 Signed-off-by: Antonio Cardace <acardace@redhat.com>
2021-01-19 18:57:58 +01:00
signals[DEVICE_IFINDEX_CHANGED] = g_signal_new(NM_MANAGER_DEVICE_IFINDEX_CHANGED,
G_OBJECT_CLASS_TYPE(object_class),
G_SIGNAL_RUN_FIRST,
0,
NULL,
NULL,
NULL,
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
}
Reference in a new issue Copy permalink