2020-12-23 22:21:36 +01:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2019-09-25 13:13:40 +02:00
|
|
|
/*
|
2017-03-20 13:36:00 +00:00
|
|
|
* Copyright (C) 2005 - 2017 Red Hat, Inc.
|
2008-11-03 04:13:42 +00:00
|
|
|
* Copyright (C) 2006 - 2008 Novell, Inc.
|
2005-12-31 08:21:24 +00:00
|
|
|
*/
|
|
|
|
|
|
all: fix up multiple-include-guard defines
Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
Fix this by changing the include guards in the non-API-stable parts of
the tree:
- libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H
- libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__
- src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__
And likewise for all other headers.
The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.
2014-08-13 14:10:11 -04:00
|
|
|
#ifndef __NETWORKMANAGER_DEVICE_H__
|
|
|
|
|
#define __NETWORKMANAGER_DEVICE_H__
|
2005-12-31 08:21:24 +00:00
|
|
|
|
|
|
|
|
#include <netinet/in.h>
|
|
|
|
|
|
2014-04-10 15:29:45 -05:00
|
|
|
#include "NetworkManagerUtils.h"
|
2021-08-06 15:17:05 +02:00
|
|
|
#include "nm-connection.h"
|
|
|
|
|
#include "nm-dbus-interface.h"
|
|
|
|
|
#include "nm-dbus-object.h"
|
2021-05-04 09:47:06 +02:00
|
|
|
#include "nm-device-utils.h"
|
2021-08-06 15:17:05 +02:00
|
|
|
#include "nm-l3cfg.h"
|
|
|
|
|
#include "nm-rfkill-manager.h"
|
|
|
|
|
#include "nm-setting-connection.h"
|
2017-01-27 13:57:15 +01:00
|
|
|
|
2011-11-18 00:34:08 -06:00
|
|
|
/* Properties */
|
|
|
|
|
#define NM_DEVICE_UDI "udi"
|
2020-06-10 15:17:39 +02:00
|
|
|
#define NM_DEVICE_PATH "path"
|
2011-11-18 00:34:08 -06:00
|
|
|
#define NM_DEVICE_IFACE "interface"
|
|
|
|
|
#define NM_DEVICE_IP_IFACE "ip-interface"
|
|
|
|
|
#define NM_DEVICE_DRIVER "driver"
|
2012-06-01 16:48:57 +02:00
|
|
|
#define NM_DEVICE_DRIVER_VERSION "driver-version"
|
|
|
|
|
#define NM_DEVICE_FIRMWARE_VERSION "firmware-version"
|
2011-11-18 00:34:08 -06:00
|
|
|
#define NM_DEVICE_CAPABILITIES "capabilities"
|
2013-05-07 10:23:44 -04:00
|
|
|
#define NM_DEVICE_CARRIER "carrier"
|
2011-11-18 00:34:08 -06:00
|
|
|
#define NM_DEVICE_IP4_ADDRESS "ip4-address"
|
|
|
|
|
#define NM_DEVICE_IP4_CONFIG "ip4-config"
|
|
|
|
|
#define NM_DEVICE_DHCP4_CONFIG "dhcp4-config"
|
|
|
|
|
#define NM_DEVICE_IP6_CONFIG "ip6-config"
|
|
|
|
|
#define NM_DEVICE_DHCP6_CONFIG "dhcp6-config"
|
|
|
|
|
#define NM_DEVICE_STATE "state"
|
2012-01-29 22:40:37 +01:00
|
|
|
#define NM_DEVICE_STATE_REASON "state-reason"
|
2011-11-18 00:34:08 -06:00
|
|
|
#define NM_DEVICE_ACTIVE_CONNECTION "active-connection"
|
|
|
|
|
#define NM_DEVICE_DEVICE_TYPE "device-type" /* ugh */
|
2015-12-08 14:49:50 +01:00
|
|
|
#define NM_DEVICE_LINK_TYPE "link-type"
|
2011-11-18 00:34:08 -06:00
|
|
|
#define NM_DEVICE_MANAGED "managed"
|
2012-05-14 15:32:54 +02:00
|
|
|
#define NM_DEVICE_AUTOCONNECT "autoconnect"
|
2011-11-18 00:34:08 -06:00
|
|
|
#define NM_DEVICE_FIRMWARE_MISSING "firmware-missing"
|
2015-04-14 14:16:04 +02:00
|
|
|
#define NM_DEVICE_NM_PLUGIN_MISSING "nm-plugin-missing"
|
2013-05-01 09:28:16 -04:00
|
|
|
#define NM_DEVICE_AVAILABLE_CONNECTIONS "available-connections"
|
2013-10-11 14:59:26 -04:00
|
|
|
#define NM_DEVICE_PHYSICAL_PORT_ID "physical-port-id"
|
2013-12-16 15:16:43 +01:00
|
|
|
#define NM_DEVICE_MTU "mtu"
|
2014-07-14 17:59:45 -05:00
|
|
|
#define NM_DEVICE_HW_ADDRESS "hw-address"
|
2021-10-06 16:09:28 +02:00
|
|
|
#define NM_DEVICE_PORTS "ports"
|
2016-06-17 18:53:45 +02:00
|
|
|
|
|
|
|
|
/* "perm-hw-address" is exposed on D-Bus both for NMDeviceEthernet
|
|
|
|
|
* and NMDeviceWifi. */
|
|
|
|
|
#define NM_DEVICE_PERM_HW_ADDRESS "perm-hw-address"
|
|
|
|
|
|
2015-04-29 16:34:38 +02:00
|
|
|
#define NM_DEVICE_METERED "metered"
|
2015-10-07 11:48:38 +02:00
|
|
|
#define NM_DEVICE_LLDP_NEIGHBORS "lldp-neighbors"
|
2014-09-05 08:50:02 -05:00
|
|
|
#define NM_DEVICE_REAL "real"
|
2014-07-14 17:59:45 -05:00
|
|
|
|
2016-12-30 12:06:30 +01:00
|
|
|
/* "parent" is exposed on D-Bus by subclasses like NMDeviceIPTunnel */
|
2016-12-26 11:12:39 +01:00
|
|
|
#define NM_DEVICE_PARENT "parent"
|
|
|
|
|
|
2015-12-02 10:33:19 +01:00
|
|
|
/* the "slaves" property is internal in the parent class, but exposed
|
2018-06-29 22:52:43 +02:00
|
|
|
* by the derived classes NMDeviceBond, NMDeviceBridge, NMDeviceTeam,
|
|
|
|
|
* NMDeviceOvsBridge and NMDeviceOvsPort. */
|
2015-12-02 10:33:19 +01:00
|
|
|
#define NM_DEVICE_SLAVES "slaves" /* partially internal */
|
|
|
|
|
|
2021-05-03 21:48:58 +02:00
|
|
|
#define NM_DEVICE_TYPE_DESC "type-desc" /* Internal only */
|
|
|
|
|
#define NM_DEVICE_IFINDEX "ifindex" /* Internal only */
|
|
|
|
|
#define NM_DEVICE_MASTER "master" /* Internal only */
|
2013-08-13 17:45:34 -04:00
|
|
|
#define NM_DEVICE_HAS_PENDING_ACTION "has-pending-action" /* Internal only */
|
2011-11-18 00:34:08 -06:00
|
|
|
|
2012-05-29 09:56:50 -05:00
|
|
|
/* Internal signals */
|
2021-10-25 11:47:26 +02:00
|
|
|
#define NM_DEVICE_DNS_LOOKUP_DONE "dns-lookup-done"
|
|
|
|
|
#define NM_DEVICE_L3CD_CHANGED "l3cd-changed"
|
|
|
|
|
#define NM_DEVICE_IP6_PREFIX_DELEGATED "ip6-prefix-delegated"
|
|
|
|
|
#define NM_DEVICE_IP6_SUBNET_NEEDED "ip6-subnet-needed"
|
|
|
|
|
#define NM_DEVICE_REMOVED "removed"
|
|
|
|
|
#define NM_DEVICE_RECHECK_AUTO_ACTIVATE "recheck-auto-activate"
|
|
|
|
|
#define NM_DEVICE_RECHECK_ASSUME "recheck-assume"
|
|
|
|
|
#define NM_DEVICE_STATE_CHANGED "state-changed"
|
|
|
|
|
#define NM_DEVICE_LINK_INITIALIZED "link-initialized"
|
|
|
|
|
#define NM_DEVICE_AUTOCONNECT_ALLOWED "autoconnect-allowed"
|
|
|
|
|
#define NM_DEVICE_PLATFORM_ADDRESS_CHANGED "platform-address-changed"
|
2011-11-18 00:34:08 -06:00
|
|
|
|
2016-08-10 11:54:31 +02:00
|
|
|
#define NM_DEVICE_STATISTICS_REFRESH_RATE_MS "refresh-rate-ms"
|
|
|
|
|
#define NM_DEVICE_STATISTICS_TX_BYTES "tx-bytes"
|
|
|
|
|
#define NM_DEVICE_STATISTICS_RX_BYTES "rx-bytes"
|
|
|
|
|
|
2018-07-03 19:09:34 +02:00
|
|
|
#define NM_DEVICE_IP4_CONNECTIVITY "ip4-connectivity"
|
|
|
|
|
#define NM_DEVICE_IP6_CONNECTIVITY "ip6-connectivity"
|
2019-10-10 09:23:22 +02:00
|
|
|
#define NM_DEVICE_INTERFACE_FLAGS "interface-flags"
|
2017-03-20 13:36:00 +00:00
|
|
|
|
2016-04-04 13:52:50 +02:00
|
|
|
#define NM_TYPE_DEVICE (nm_device_get_type())
|
2022-12-14 16:21:48 +01:00
|
|
|
#define NM_DEVICE(obj) (_NM_G_TYPE_CHECK_INSTANCE_CAST((obj), NM_TYPE_DEVICE, NMDevice))
|
2016-04-04 13:52:50 +02:00
|
|
|
#define NM_DEVICE_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST((klass), NM_TYPE_DEVICE, NMDeviceClass))
|
|
|
|
|
#define NM_IS_DEVICE(obj) (G_TYPE_CHECK_INSTANCE_TYPE((obj), NM_TYPE_DEVICE))
|
|
|
|
|
#define NM_IS_DEVICE_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE((klass), NM_TYPE_DEVICE))
|
|
|
|
|
#define NM_DEVICE_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS((obj), NM_TYPE_DEVICE, NMDeviceClass))
|
2005-12-31 08:21:24 +00:00
|
|
|
|
2011-11-17 22:39:34 -06:00
|
|
|
typedef enum NMActStageReturn NMActStageReturn;
|
|
|
|
|
|
2015-01-16 14:54:11 +01:00
|
|
|
/* These flags affect whether a connection is considered available on a device
|
|
|
|
|
* (check_connection_available()). The flags should have the meaning of relaxing
|
|
|
|
|
* a condition, so that adding a flag might make a connection available that would
|
|
|
|
|
* not be available otherwise. Adding a flag should never make a connection
|
|
|
|
|
* not available if it would be available otherwise. */
|
2022-02-02 12:12:12 +01:00
|
|
|
typedef enum {
|
|
|
|
|
NM_DEVICE_CHECK_CON_AVAILABLE_NONE = 0,
|
2015-01-20 21:06:31 +01:00
|
|
|
|
2022-02-02 12:12:12 +01:00
|
|
|
/* since NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST is a collection of flags with more fine grained
|
2018-10-17 12:13:49 +02:00
|
|
|
* parts, this flag in general indicates that this is a user-request. */
|
2022-02-02 12:12:12 +01:00
|
|
|
_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST = (1L << 0),
|
2018-10-17 12:13:49 +02:00
|
|
|
|
2022-02-02 12:12:12 +01:00
|
|
|
/* we also consider devices which have no carrier but are still waiting for the driver
|
2018-10-17 12:13:49 +02:00
|
|
|
* to detect carrier. Usually, such devices are not yet available, however for a user-request
|
|
|
|
|
* they are. They might fail later if carrier doesn't come. */
|
2022-02-02 12:12:12 +01:00
|
|
|
_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_WAITING_CARRIER = (1L << 1),
|
2018-10-17 12:13:49 +02:00
|
|
|
|
2022-02-02 12:12:12 +01:00
|
|
|
/* usually, a profile is only available if the Wi-Fi AP is in range. For an
|
2018-10-17 12:13:49 +02:00
|
|
|
* explicit user request, we also consider profiles for APs that are not (yet)
|
|
|
|
|
* visible. */
|
2022-02-02 12:12:12 +01:00
|
|
|
_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_IGNORE_AP = (1L << 2),
|
2018-10-17 12:13:49 +02:00
|
|
|
|
2022-02-02 12:12:12 +01:00
|
|
|
/* a device can be marked as unmanaged for various reasons. Some of these reasons
|
2019-01-11 17:07:03 -02:00
|
|
|
* are authoritative, others not. Non-authoritative reasons can be overruled by
|
2018-10-17 12:26:35 +02:00
|
|
|
* `nmcli device set $DEVICE managed yes`. Also, for an explicit user activation
|
|
|
|
|
* request we may want to consider the device as managed. This flag makes devices
|
|
|
|
|
* that are unmanaged appear available. */
|
2022-02-02 12:12:12 +01:00
|
|
|
_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_OVERRULE_UNMANAGED = (1L << 3),
|
2018-10-17 12:26:35 +02:00
|
|
|
|
2022-02-02 12:12:12 +01:00
|
|
|
/* a collection of flags, that are commonly set for an explicit user-request. */
|
|
|
|
|
NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST =
|
|
|
|
|
_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST
|
|
|
|
|
| _NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_WAITING_CARRIER
|
|
|
|
|
| _NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_IGNORE_AP
|
|
|
|
|
| _NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_OVERRULE_UNMANAGED,
|
2015-01-16 14:54:11 +01:00
|
|
|
|
2022-02-02 12:12:12 +01:00
|
|
|
NM_DEVICE_CHECK_CON_AVAILABLE_ALL = (1L << 4) - 1,
|
2015-01-16 14:54:11 +01:00
|
|
|
} NMDeviceCheckConAvailableFlags;
|
|
|
|
|
|
2015-12-07 17:05:12 +01:00
|
|
|
struct _NMDevicePrivate;
|
|
|
|
|
|
2012-08-30 09:45:32 -05:00
|
|
|
struct _NMDevice {
|
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API
Previously, we used the generated GDBusInterfaceSkeleton types and glued
them via the NMExportedObject base class to our NM types. We also used
GDBusObjectManagerServer.
Don't do that anymore. The resulting code was more complicated despite (or
because?) using generated classes. It was hard to understand, complex, had
ordering-issues, and had a runtime and memory overhead.
This patch refactors this entirely and uses the lower layer API GDBusConnection
directly. It replaces the generated code, GDBusInterfaceSkeleton, and
GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager
and static descriptor instances of type GDBusInterfaceInfo.
This adds a net plus of more then 1300 lines of hand written code. I claim
that this implementation is easier to understand. Note that previously we
also required extensive and complex glue code to bind our objects to the
generated skeleton objects. Instead, now glue our objects directly to
GDBusConnection. The result is more immediate and gets rid of layers of
code in between.
Now that the D-Bus glue us more under our control, we can address issus and
bottlenecks better, instead of adding code to bend the generated skeletons
to our needs.
Note that the current implementation now only supports one D-Bus connection.
That was effectively the case already, although there were places (and still are)
where the code pretends it could also support connections from a private socket.
We dropped private socket support mainly because it was unused, untested and
buggy, but also because GDBusObjectManagerServer could not export the same
objects on multiple connections. Now, it would be rather straight forward to
fix that and re-introduce ObjectManager on each private connection. But this
commit doesn't do that yet, and the new code intentionally supports only one
D-Bus connection.
Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start()
succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to
connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough
for the moment. It could be easily extended later, for example with polling whether the
system bus appears (like was done previously). Also, restart of D-Bus daemon isn't
supported either -- just like before.
Note how NMDBusManager now implements the ObjectManager D-Bus interface
directly.
Also, this fixes race issues in the server, by no longer delaying
PropertiesChanged signals. NMExportedObject would collect changed
properties and send the signal out in idle_emit_properties_changed()
on idle. This messes up the ordering of change events w.r.t. other
signals and events on the bus. Note that not only NMExportedObject
messed up the ordering. Also the generated code would hook into
notify() and process change events in and idle handle, exhibiting the
same ordering issue too.
No longer do that. PropertiesChanged signals will be sent right away
by hooking into dispatch_properties_changed(). This means, changing
a property in quick succession will no longer be combined and is
guaranteed to emit signals for each individual state. Quite possibly
we emit now more PropertiesChanged signals then before.
However, we are now able to group a set of changes by using standard
g_object_freeze_notify()/g_object_thaw_notify(). We probably should
make more use of that.
Also, now that our signals are all handled in the right order, we
might find places where we still emit them in the wrong order. But that
is then due to the order in which our GObjects emit signals, not due
to an ill behavior of the D-Bus glue. Possibly we need to identify
such ordering issues and fix them.
Numbers (for contrib/rpm --without debug on x86_64):
- the patch changes the code size of NetworkManager by
- 2809360 bytes
+ 2537528 bytes (-9.7%)
- Runtime measurements are harder because there is a large variance
during testing. In other words, the numbers are not reproducible.
Currently, the implementation performs no caching of GVariants at all,
but it would be rather simple to add it, if that turns out to be
useful.
Anyway, without strong claim, it seems that the new form tends to
perform slightly better. That would be no surprise.
$ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done)
- real 1m39.355s
+ real 1m37.432s
$ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done)
- real 0m26.843s
+ real 0m25.281s
- Regarding RSS size, just looking at the processes in similar
conditions, doesn't give a large difference. On my system they
consume about 19MB RSS. 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;
|
2016-09-05 16:55:07 +02:00
|
|
|
struct _NMDevicePrivate *_priv;
|
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;
|
2012-08-30 09:45:32 -05:00
|
|
|
};
|
2005-12-31 08:21:24 +00:00
|
|
|
|
2015-01-20 20:25:25 +01:00
|
|
|
/* The flags have an relaxing meaning, that means, specifying more flags, can make
|
|
|
|
|
* a device appear more available. It can never make a device less available. */
|
2022-02-02 12:12:12 +01:00
|
|
|
typedef enum {
|
|
|
|
|
NM_DEVICE_CHECK_DEV_AVAILABLE_NONE = 0,
|
2015-01-20 20:25:25 +01:00
|
|
|
|
2022-02-02 12:12:12 +01:00
|
|
|
/* the device is considered available, even if it has no carrier.
|
2018-10-17 12:13:49 +02:00
|
|
|
*
|
|
|
|
|
* For various device types (software devices) we ignore carrier based
|
|
|
|
|
* on the type. So, for them, this flag has no effect anyway. */
|
2022-02-02 12:12:12 +01:00
|
|
|
_NM_DEVICE_CHECK_DEV_AVAILABLE_IGNORE_CARRIER = (1L << 0),
|
2018-10-17 12:13:49 +02:00
|
|
|
|
2022-02-02 12:12:12 +01:00
|
|
|
NM_DEVICE_CHECK_DEV_AVAILABLE_FOR_USER_REQUEST = _NM_DEVICE_CHECK_DEV_AVAILABLE_IGNORE_CARRIER,
|
2015-12-09 12:08:40 +01:00
|
|
|
|
2022-02-02 12:12:12 +01:00
|
|
|
NM_DEVICE_CHECK_DEV_AVAILABLE_ALL = (1L << 1) - 1,
|
2015-01-20 20:25:25 +01:00
|
|
|
} NMDeviceCheckDevAvailableFlags;
|
|
|
|
|
|
2018-10-09 16:37:06 +02:00
|
|
|
typedef void (*NMDeviceDeactivateCallback)(NMDevice *self, GError *error, gpointer user_data);
|
2022-04-27 16:27:24 +02:00
|
|
|
typedef void (*NMDeviceAttachPortCallback)(NMDevice *self, GError *error, gpointer user_data);
|
2018-10-09 16:37:06 +02:00
|
|
|
|
2018-04-24 20:53:18 +02:00
|
|
|
typedef struct _NMDeviceClass {
|
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API
Previously, we used the generated GDBusInterfaceSkeleton types and glued
them via the NMExportedObject base class to our NM types. We also used
GDBusObjectManagerServer.
Don't do that anymore. The resulting code was more complicated despite (or
because?) using generated classes. It was hard to understand, complex, had
ordering-issues, and had a runtime and memory overhead.
This patch refactors this entirely and uses the lower layer API GDBusConnection
directly. It replaces the generated code, GDBusInterfaceSkeleton, and
GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager
and static descriptor instances of type GDBusInterfaceInfo.
This adds a net plus of more then 1300 lines of hand written code. I claim
that this implementation is easier to understand. Note that previously we
also required extensive and complex glue code to bind our objects to the
generated skeleton objects. Instead, now glue our objects directly to
GDBusConnection. The result is more immediate and gets rid of layers of
code in between.
Now that the D-Bus glue us more under our control, we can address issus and
bottlenecks better, instead of adding code to bend the generated skeletons
to our needs.
Note that the current implementation now only supports one D-Bus connection.
That was effectively the case already, although there were places (and still are)
where the code pretends it could also support connections from a private socket.
We dropped private socket support mainly because it was unused, untested and
buggy, but also because GDBusObjectManagerServer could not export the same
objects on multiple connections. Now, it would be rather straight forward to
fix that and re-introduce ObjectManager on each private connection. But this
commit doesn't do that yet, and the new code intentionally supports only one
D-Bus connection.
Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start()
succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to
connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough
for the moment. It could be easily extended later, for example with polling whether the
system bus appears (like was done previously). Also, restart of D-Bus daemon isn't
supported either -- just like before.
Note how NMDBusManager now implements the ObjectManager D-Bus interface
directly.
Also, this fixes race issues in the server, by no longer delaying
PropertiesChanged signals. NMExportedObject would collect changed
properties and send the signal out in idle_emit_properties_changed()
on idle. This messes up the ordering of change events w.r.t. other
signals and events on the bus. Note that not only NMExportedObject
messed up the ordering. Also the generated code would hook into
notify() and process change events in and idle handle, exhibiting the
same ordering issue too.
No longer do that. PropertiesChanged signals will be sent right away
by hooking into dispatch_properties_changed(). This means, changing
a property in quick succession will no longer be combined and is
guaranteed to emit signals for each individual state. Quite possibly
we emit now more PropertiesChanged signals then before.
However, we are now able to group a set of changes by using standard
g_object_freeze_notify()/g_object_thaw_notify(). We probably should
make more use of that.
Also, now that our signals are all handled in the right order, we
might find places where we still emit them in the wrong order. But that
is then due to the order in which our GObjects emit signals, not due
to an ill behavior of the D-Bus glue. Possibly we need to identify
such ordering issues and fix them.
Numbers (for contrib/rpm --without debug on x86_64):
- the patch changes the code size of NetworkManager by
- 2809360 bytes
+ 2537528 bytes (-9.7%)
- Runtime measurements are harder because there is a large variance
during testing. In other words, the numbers are not reproducible.
Currently, the implementation performs no caching of GVariants at all,
but it would be rather simple to add it, if that turns out to be
useful.
Anyway, without strong claim, it seems that the new form tends to
perform slightly better. That would be no surprise.
$ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done)
- real 1m39.355s
+ real 1m37.432s
$ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done)
- real 0m26.843s
+ real 0m25.281s
- Regarding RSS size, just looking at the processes in similar
conditions, doesn't give a large difference. On my system they
consume about 19MB RSS. 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;
|
2005-12-31 08:21:24 +00:00
|
|
|
|
2018-04-24 20:53:18 +02:00
|
|
|
struct _NMDeviceClass *default_type_description_klass;
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *default_type_description;
|
2017-12-27 09:40:59 +01:00
|
|
|
|
2018-07-10 08:14:56 +02:00
|
|
|
const char *connection_type_supported;
|
2018-06-27 17:00:55 +02:00
|
|
|
|
|
|
|
|
/* most device types, can only handle profiles of a particular type. This
|
|
|
|
|
* is the connection.type setting, as checked by nm_device_check_connection_compatible() */
|
|
|
|
|
const char *connection_type_check_compatible;
|
|
|
|
|
|
2014-10-09 12:42:29 -05:00
|
|
|
const NMLinkType *link_types;
|
2013-06-27 14:39:13 +02:00
|
|
|
|
2019-09-12 17:29:49 +02:00
|
|
|
/* if the device MTU is set based on parent's one, this specifies
|
|
|
|
|
* a delta in the MTU allowed value due the encapsulation overhead */
|
|
|
|
|
guint16 mtu_parent_delta;
|
|
|
|
|
|
2017-06-01 23:08:30 +02:00
|
|
|
/* Whether the device type is a master-type. This depends purely on the
|
|
|
|
|
* type (NMDeviceClass), not the actual device instance. */
|
|
|
|
|
bool is_master : 1;
|
|
|
|
|
|
2020-10-21 18:57:18 +02:00
|
|
|
/* Force setting the MTU actually means first setting the MTU
|
|
|
|
|
* to (desired_MTU-1) and then setting the desired_MTU
|
|
|
|
|
* so that kernel actually applies the MTU, otherwise
|
|
|
|
|
* kernel will ignore the request if the link's MTU is the
|
|
|
|
|
* same as the desired one.
|
|
|
|
|
*
|
|
|
|
|
* This is just a workaround made for bridges (ATM) that employ
|
|
|
|
|
* a auto-MTU adjust mechanism if no MTU is manually set.
|
|
|
|
|
*/
|
|
|
|
|
bool mtu_force_set : 1;
|
|
|
|
|
|
2021-02-01 09:53:59 +01:00
|
|
|
/* Control whether to call stage1 and stage2 callbacks also for assuming
|
|
|
|
|
* a device or for external activations. In this case, the callback must
|
|
|
|
|
* take care not to touch the device's configuration. */
|
|
|
|
|
bool act_stage1_prepare_also_for_external_or_assume : 1;
|
|
|
|
|
bool act_stage2_config_also_for_external_or_assume : 1;
|
|
|
|
|
|
|
|
|
|
bool act_stage1_prepare_set_hwaddr_ethernet : 1;
|
|
|
|
|
|
|
|
|
|
bool can_reapply_change_ovs_external_ids : 1;
|
|
|
|
|
|
2022-07-22 10:28:30 -04:00
|
|
|
bool allow_autoconnect_on_external : 1;
|
|
|
|
|
|
2022-02-01 20:21:34 +01:00
|
|
|
NMRfkillType rfkill_type : 4;
|
core/rfkill: move rfkill_type property to NMDeviceClass
GObject Properties are flexible and powerful. In practice, NMDevicePrivate.rfkill_type
was only set once via the construct-only property NM_DEVICE_RFKILL_TYPE.
Which in turn was always set to a well-known value, only depending on the device
type.
We don't need this flexibility. The rfkill-type only depends on the
device type and doesn't change. Replace the property by a field in
NMDeviceClass.
For one, construct properties have an overhead, that the property setter is
called whenever we construct a NMDevice. But the real reason for this
change, is that a property give a notion as this could change during the
lifetime of a NMDevice (which it in fact did not, being construct-only).
Or that the type depends on something more complex, when instead it only
depends on the device type. A non-mutated class property is simpler,
because it's clear that it does not depend on the device instance,
only on the type/class.
Also, `git grep -w rfkill_type` now nicely shows the (few) references to
this variable and its easier to understand.
2022-02-01 19:42:26 +01:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
void (*state_changed)(NMDevice *device,
|
2011-11-18 00:09:37 -06:00
|
|
|
NMDeviceState new_state,
|
|
|
|
|
NMDeviceState old_state,
|
|
|
|
|
NMDeviceStateReason reason);
|
|
|
|
|
|
2017-01-02 15:38:24 +01:00
|
|
|
void (*link_changed)(NMDevice *self, const NMPlatformLink *pllink);
|
2013-07-27 10:41:44 +02:00
|
|
|
|
2014-09-05 08:50:02 -05:00
|
|
|
/**
|
|
|
|
|
* create_and_realize():
|
|
|
|
|
* @self: the #NMDevice
|
|
|
|
|
* @connection: the #NMConnection being activated
|
|
|
|
|
* @parent: the parent #NMDevice, if any
|
2015-12-09 15:13:57 +01:00
|
|
|
* @out_plink: on success, a backing kernel network device if one exists.
|
|
|
|
|
* The returned pointer is owned by platform and only valid until the
|
|
|
|
|
* next platform operation.
|
2014-09-05 08:50:02 -05:00
|
|
|
* @error: location to store error, or %NULL
|
|
|
|
|
*
|
|
|
|
|
* Create any backing resources (kernel devices, etc) required for this
|
|
|
|
|
* device to activate @connection. If the device is backed by a kernel
|
|
|
|
|
* network device, that device should be returned in @out_plink after
|
|
|
|
|
* being created.
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE on success, %FALSE on error
|
|
|
|
|
*/
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*create_and_realize)(NMDevice *self,
|
|
|
|
|
NMConnection *connection,
|
|
|
|
|
NMDevice *parent,
|
2015-12-09 15:13:57 +01:00
|
|
|
const NMPlatformLink **out_plink,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error);
|
2014-09-05 08:50:02 -05:00
|
|
|
|
|
|
|
|
/**
|
2016-01-08 17:24:24 +01:00
|
|
|
* realize_start_notify():
|
2014-09-05 08:50:02 -05:00
|
|
|
* @self: the #NMDevice
|
2017-01-02 15:53:18 +01:00
|
|
|
* @pllink: the #NMPlatformLink if backed by a kernel netdevice
|
2014-09-05 08:50:02 -05:00
|
|
|
*
|
2016-01-08 17:24:24 +01:00
|
|
|
* Hook for derived classes to be notfied during realize_start_setup()
|
|
|
|
|
* and perform additional setup.
|
2017-01-02 15:53:18 +01:00
|
|
|
*
|
2018-09-14 23:49:20 -04:00
|
|
|
* The default implementation of NMDevice calls link_changed().
|
2014-09-05 08:50:02 -05:00
|
|
|
*/
|
2017-01-02 15:53:18 +01:00
|
|
|
void (*realize_start_notify)(NMDevice *self, const NMPlatformLink *pllink);
|
2014-09-24 16:58:07 -05:00
|
|
|
|
2016-04-20 09:16:41 +02:00
|
|
|
/**
|
|
|
|
|
* unrealize():
|
|
|
|
|
* @self: the #NMDevice
|
|
|
|
|
*
|
|
|
|
|
* Remove the device backing resources.
|
|
|
|
|
*/
|
|
|
|
|
gboolean (*unrealize)(NMDevice *self, GError **error);
|
|
|
|
|
|
2014-09-24 15:13:19 -05:00
|
|
|
/**
|
2016-01-10 15:18:31 +01:00
|
|
|
* unrealize_notify():
|
2014-09-24 15:13:19 -05:00
|
|
|
* @self: the #NMDevice
|
|
|
|
|
*
|
2016-01-10 15:19:58 +01:00
|
|
|
* Hook for derived classes to clear any properties that depend on backing resources
|
|
|
|
|
* (kernel devices, etc). This is called by nm_device_unrealize() during unrealization.
|
2014-09-24 15:13:19 -05:00
|
|
|
*/
|
2016-01-10 15:19:58 +01:00
|
|
|
void (*unrealize_notify)(NMDevice *self);
|
2014-09-24 15:13:19 -05:00
|
|
|
|
2013-05-07 10:23:44 -04:00
|
|
|
/* Hardware state (IFF_UP) */
|
2015-04-07 14:24:12 +02:00
|
|
|
gboolean (*can_unmanaged_external_down)(NMDevice *self);
|
2008-04-28 Dan Williams <dcbw@redhat.com>
Fix the device up/down ambiguities. Up/down state used to be a
conglomeration of hardware state (IFF_UP) and any device-specific things
(supplicant, periodic timers, etc) that the device used to indicate
readiness. Unfortunately, if the hardware was already IFF_UP for some
reason, then the device specific stuff wouldn't get run, and the device
would be stuck.
* src/nm-device.c
src/nm-device.h
- Create hw_is_up, hw_bring_up, and hw_take_down
- Rename bring_down -> take_down
- (real_hw_is_up): check interface flags for IFF_UP
- (nm_device_hw_is_up): let subclasses figure out their own HW state
- (nm_device_is_up): make static; only used locally
- (nm_device_hw_bring_up): update the hardware and IPv4 addresses even
if the device is already up; if the device isn't up, bring it up
- (nm_device_hw_take_down): just take down hardware
- (nm_device_bring_up): bring up HW first, then device specific stuff
- (nm_device_take_down): always deactivate device when called; always
try to take hardware down too
- (nm_device_state_changed): take device down when entering unmanaged
state from a higher state
* src/nm-device-802-11-wireless.c
- (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just
check IFF_UP really
- (real_take_down, supplicant_iface_state_cb_handler,
supplicant_iface_connection_state_cb_handler,
supplicant_mgr_state_cb_handler): fix some messages
* src/nm-device-802-3-ethernet.c
- (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just
check IFF_UP really
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
|
|
|
|
2013-05-07 10:23:44 -04:00
|
|
|
/* Carrier state (IFF_LOWER_UP) */
|
2017-05-12 16:17:18 +02:00
|
|
|
void (*carrier_changed_notify)(NMDevice *, gboolean carrier);
|
2013-05-07 10:23:44 -04:00
|
|
|
|
2014-04-10 15:29:45 -05:00
|
|
|
gboolean (*get_ip_iface_identifier)(NMDevice *self, NMUtilsIPv6IfaceId *out_iid);
|
|
|
|
|
|
2015-04-17 15:15:38 +02:00
|
|
|
NMDeviceCapabilities (*get_generic_capabilities)(NMDevice *self);
|
2005-12-31 08:21:24 +00:00
|
|
|
|
2016-04-04 13:52:50 +02:00
|
|
|
gboolean (*is_available)(NMDevice *self, NMDeviceCheckDevAvailableFlags flags);
|
2008-03-07 Dan Williams <dcbw@redhat.com>
First pass of multiple active device support. Expect bugs.
* src/nm-ip4-config.c
src/nm-ip4-config.h
- (nm_ip4_config_get_secondary, nm_ip4_config_set_secondary): remove;
there are better ways to do this in the named manager
* src/nm-device.c
src/nm-device.h
- (nm_device_can_activate): return whether the device can activate a
connection right now; taking into account things like carrier state
and rfkill state
- (nm_device_get_best_auto_connection): renamed from
nm_device_get_best_connection
- (real_act_stage4_get_ip4_config): MTU stuff is now handled in the
device subclasses themselves, so that each device can override the
MTU from it's NMSetting subclass if needed
- (nm_device_set_ip4_config): set MTU when setting up routes and stuff
in NetworkManagerSystem.c, not here
* src/named-manager/nm-named-manager.c
src/named-manager/nm-named-manager.h
- (nm_named_manager_name_owner_changed,
nm_named_manager_dbus_connection_changed): fix for changes to
rewrite_resolv_conf()
- (compute_nameservers): don't need the NMNamedManager at all, remove
from parameter list
- (merge_one_ip4_config): new function; merge ip4 configs together
- (rewrite_resolv_conf): write out resolv.conf from all the stored
ip4 configs; the VPN config takes precedence, then the best
device config, then the rest of the configs
- (get_domain_for_config): take the NMNamedManager as an argument
to check whether the config is the VPN config
- (add_ip4_config_to_named): fixups for removal of the 'secondary'
attribute from ip4 configs
- (add_all_ip4_configs_to_named): add all the configs in priority order
- (remove_ip4_config_from_named): fix for changes to
get_domain_for_config()
- (nm_named_manager_add_ip4_config): assign the config to the right slot
based on its type; callers must pass in the type now
- (get_last_default_domain): remove, unused
- (nm_named_manager_remove_ip4_config): handle config slots correctly
* src/nm-device-802-11-wireless.c
- (real_can_activate): new function
- (real_get_best_auto_connection): renamed from real_get_best_connection
- (real_act_stage4_get_ip4_config): handle MTU override
* src/nm-device-802-3-ethernet.c
- (real_can_activate): new function
- (real_get_best_auto_connection): renamed from real_get_best_connection
- (real_act_stage4_get_ip4_config): new function; handle MTU override
* src/vpn-manager/nm-vpn-connection.c
- (nm_vpn_connection_ip4_config_get): don't need to set the 'secondary'
attribute on the ip4 config
* src/NetworkManagerPolicy.c
- (nm_policy_auto_get_best_device): remove
- (nm_policy_device_change_check): remove
- (update_default_route): new function; set the default route via
the specified device
- (get_device_priority): new function; return the priority number of
a device type WRT which one should have the default route. Order is
(highest to lowest) wired, wireless, GSM, CDMA.
- (update_routing_and_dns): new function; determine which device should
have the default route, then update the routing table and DNS
- (maybe_auto_activate_device): new function; if a device is now
available for activation, find out what connection it would like to
activate and do it
- (schedule_activate_check): new function; if a device can be activated
now, schedule the activation. Each device may have only one
pending activation at a given time.
- (device_state_changed): if activation was canceled, try again,
possibly with another connection; if the device was activated,
update routing and DNS; if the device was deactivated, try again
with another connection
- (device_carrier_changed): if there is no carrier, deactivate the
device; otherwise schedule an activation check for the device
- (wireless_networks_changed): schedule an activation check for the
device
- (device_added): keep track of the signal handler IDs so they can
be removed when the device goes away
- (device_removed): remove any signal handlers that might be attached
to the device; update routing and DNS
- (schedule_activate_all): new function
- (connections_added, connection_added, connection_updated): when
connections change, schedule all devices for an activation check
- (connection_removed): when a device is deactivated because its
connection was removed, schedule another activation check for it
- (nm_policy_destroy): destroy pending activations and disconnect
all device signal handlers
* src/nm-manager.c
- (nm_manager_activate_device): if the device was already actived,
deactivate it
- (deactivate_old_device): remove
- (connection_added_default_handler, impl_manager_activate_device):
don't deactivate other devices when activating this one
* src/backends/NetworkManagerGentoo.c
src/backends/NetworkManagerFrugalware.c
src/backends/NetworkManagerPaldo.c
src/backends/NetworkManagerRedHat.c
src/backends/NetworkManagerSlackware.c
src/backends/NetworkManagerArch.c
src/backends/NetworkManagerSuSE.c
src/backends/NetworkManagerDebian.c
- (nm_system_get_mtu): remove; MTU should be provided through the
distro's system settings service plugin instead
- (nm_system_device_add_default_route_via_device): remove
- (nm_system_device_add_default_route_via_device_with_iface): remove
- (nm_system_device_replace_default_route): new function; call
generic implementation
* src/backends/NetworkManagerGeneric.c
src/backends/NetworkManagerGeneric.h
- (nm_generic_device_add_default_route_via_device,
nm_generic_device_add_default_route_via_device_with_iface): remove
- (nm_generic_device_replace_default_route): replace the default route
with the given route via some gateway
* src/NetworkManagerSystem.c
src/NetworkManagerSystem.h
- (nm_system_device_set_from_ip4_config): let the policy handle updates
to routing and DNS; but set the MTU here
- (nm_system_vpn_device_set_from_ip4_config): set the route with the
ip_iface of the active device; use the standard MTU setting function
- (nm_system_set_mtu): remove
- (nm_system_device_set_mtu): consolidate MTU setting code in one place
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3391 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-07 19:41:32 +00:00
|
|
|
|
2011-11-17 23:28:30 -06:00
|
|
|
gboolean (*get_enabled)(NMDevice *self);
|
|
|
|
|
|
2011-11-17 23:38:08 -06:00
|
|
|
void (*set_enabled)(NMDevice *self, gboolean enabled);
|
|
|
|
|
|
2019-07-28 15:59:20 +02:00
|
|
|
/* let the subclass return additional NMPlatformRoutingRule (in form of NMPObject
|
|
|
|
|
* pointers) that shall be added to the rules provided by this device.
|
|
|
|
|
* The returned GPtrArray will be g_ptr_array_unref()'ed. The subclass may or
|
|
|
|
|
* may not keep an additional reference and return this array again and again. */
|
|
|
|
|
GPtrArray *(*get_extra_rules)(NMDevice *self);
|
|
|
|
|
|
2017-02-14 12:45:38 +01:00
|
|
|
/* allow derived classes to override the result of nm_device_autoconnect_allowed().
|
|
|
|
|
* If the value changes, the class should call nm_device_emit_recheck_auto_activate(),
|
|
|
|
|
* which emits NM_DEVICE_RECHECK_AUTO_ACTIVATE signal. */
|
|
|
|
|
gboolean (*get_autoconnect_allowed)(NMDevice *self);
|
|
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*can_auto_connect)(NMDevice *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,
|
2021-11-09 13:28:54 +01:00
|
|
|
char **specific_object);
|
2007-09-09 17:58:44 +00:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
guint32 (*get_configured_mtu)(NMDevice *self,
|
2019-09-11 10:57:07 +02:00
|
|
|
NMDeviceMtuSource *out_source,
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean *out_force);
|
2017-01-14 17:04:17 +01:00
|
|
|
|
2019-04-30 15:49:07 +02:00
|
|
|
/* allow the subclass to overwrite the routing table. This is mainly useful
|
|
|
|
|
* to change from partial mode (route-table=0) to full-sync mode (route-table=254). */
|
|
|
|
|
guint32 (*coerce_route_table)(NMDevice *self,
|
|
|
|
|
int addr_family,
|
|
|
|
|
guint32 route_table,
|
|
|
|
|
gboolean is_user_config);
|
|
|
|
|
|
2018-12-12 17:11:34 +01:00
|
|
|
const char *(*get_auto_ip_config_method)(NMDevice *self, int addr_family);
|
2018-10-10 17:36:51 +02:00
|
|
|
|
2012-08-01 11:16:48 -06:00
|
|
|
/* Checks whether the connection is compatible with the device using
|
|
|
|
|
* only the devices type and characteristics. Does not use any live
|
2018-11-21 11:32:38 +01:00
|
|
|
* network information like Wi-Fi scan lists etc.
|
2012-08-01 11:16:48 -06:00
|
|
|
*/
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*check_connection_compatible)(NMDevice *self,
|
2018-06-27 17:00:55 +02:00
|
|
|
NMConnection *connection,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error);
|
2007-12-31 17:05:25 +00:00
|
|
|
|
2012-08-01 11:16:48 -06:00
|
|
|
/* Checks whether the connection is likely available to be activated,
|
2013-09-03 15:34:56 -05:00
|
|
|
* including any live network information like scan lists. The connection
|
|
|
|
|
* is checked against the object defined by @specific_object, if given.
|
|
|
|
|
* Returns TRUE if the connection is available; FALSE if not.
|
2014-12-08 12:39:45 +01:00
|
|
|
*
|
2015-01-16 14:54:11 +01:00
|
|
|
* The passed @flags affect whether a connection is considered
|
|
|
|
|
* available or not. Adding more flags, means the connection is
|
|
|
|
|
* *more* available.
|
|
|
|
|
*
|
|
|
|
|
* Specifying @specific_object can only reduce the availability of a connection.
|
2012-08-01 11:16:48 -06:00
|
|
|
*/
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*check_connection_available)(NMDevice *self,
|
|
|
|
|
NMConnection *connection,
|
2015-01-16 14:54:11 +01:00
|
|
|
NMDeviceCheckConAvailableFlags flags,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *specific_object,
|
|
|
|
|
GError **error);
|
2012-08-01 11:16:48 -06:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*complete_connection)(NMDevice *self,
|
|
|
|
|
NMConnection *connection,
|
|
|
|
|
const char *specific_object,
|
core: avoid clone of all-connections list for nm_utils_complete_generic()
NMSettings exposes a cached list of all connection. We don't need
to clone it. Note that this is not save against concurrent modification,
meaning, add/remove of connections in NMSettings will invalidate the
list.
However, it wasn't save against that previously either, because
altough we cloned the container (GSList), we didn't take an additional
reference to the elements.
This is purely a performance optimization, we don't need to clone the
list. Also, since the original list is of type "NMConnection *const*",
use that type insistently, instead of dependent API requiring GSList.
IMO, GSList is anyway not a very nice API for many use cases because
it requires an additional slice allocation for each element. It's
slower, and often less convenient to use.
2018-03-14 08:57:42 +01:00
|
|
|
NMConnection *const *existing_connections,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error);
|
2011-01-10 23:39:12 -06:00
|
|
|
|
2016-04-04 13:52:50 +02:00
|
|
|
NMActStageReturn (*act_stage1_prepare)(NMDevice *self, NMDeviceStateReason *out_failure_reason);
|
|
|
|
|
NMActStageReturn (*act_stage2_config)(NMDevice *self, NMDeviceStateReason *out_failure_reason);
|
2021-08-06 15:17:05 +02:00
|
|
|
void (*act_stage3_ip_config)(NMDevice *self, int addr_family);
|
2022-07-15 10:43:53 +02:00
|
|
|
gboolean (*ready_for_ip_config)(NMDevice *self, gboolean is_manual);
|
2011-10-09 22:50:04 -05:00
|
|
|
|
2021-08-06 15:17:05 +02:00
|
|
|
const char *(*get_ip_method_auto)(NMDevice *self, int addr_family);
|
2011-10-09 22:50:04 -05:00
|
|
|
|
2014-08-05 20:08:34 +02:00
|
|
|
/* Async deactivating (in the DEACTIVATING phase) */
|
2021-11-09 13:28:54 +01:00
|
|
|
void (*deactivate_async)(NMDevice *self,
|
|
|
|
|
GCancellable *cancellable,
|
2018-10-09 16:37:06 +02:00
|
|
|
NMDeviceDeactivateCallback callback,
|
2014-08-05 20:08:34 +02:00
|
|
|
gpointer user_data);
|
|
|
|
|
|
2016-06-30 11:42:28 +02:00
|
|
|
void (*deactivate_reset_hw_addr)(NMDevice *self);
|
|
|
|
|
|
2014-08-05 20:08:34 +02:00
|
|
|
/* Sync deactivating (in the DISCONNECTED phase) */
|
2016-04-04 13:52:50 +02:00
|
|
|
void (*deactivate)(NMDevice *self);
|
2006-01-03 22:11:35 +00:00
|
|
|
|
2015-05-15 15:00:07 +02:00
|
|
|
const char *(*get_type_description)(NMDevice *self);
|
|
|
|
|
|
core: refactor evaluation of device's match-spec
Previously, we would have different functions like
- nm_match_spec_device_type()
- nm_match_spec_hwaddr()
- nm_match_spec_s390_subchannels()
- nm_match_spec_interface_name()
which all would handle one type of match-spec.
So, to get the overall result whether the arguments
match or not, nm_device_spec_match_list() had to stich
them together and iterate the list multiple times.
Refactor the code to have one nm_match_spec_device()
function that gets all relevant paramters.
The upside is:
- the logic how to evaluate the match-spec is all at one place
(match_device_eval()) instead of spread over multiple
functions.
- It requires iterating the list at most twice. Twice, because
we do a fast pre-search for "*".
One downside could be, that we have to pass all 4 arguments
for the evaluation, even if the might no be needed. That is,
because "nm-core-utils.c" shall be independend from NMDevice, it
cannot receive a device instance to get the parameters as needed.
As we would add new match-types, the argument list would grow.
However, all arguments are cached and fetching them from the
device's private data is very cheap.
(cherry picked from commit b957403efd53ff7d826ac7a4f80487032c03824b)
2017-01-20 19:50:25 +01:00
|
|
|
const char *(*get_s390_subchannels)(NMDevice *self);
|
2009-08-03 17:15:03 -04:00
|
|
|
|
2013-11-02 10:40:58 -05:00
|
|
|
/* Update the connection with currently configured L2 settings */
|
2013-06-27 14:39:13 +02:00
|
|
|
void (*update_connection)(NMDevice *device, NMConnection *connection);
|
2012-02-12 13:54:09 -06:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*master_update_slave_connection)(NMDevice *self,
|
|
|
|
|
NMDevice *slave,
|
2014-06-18 20:17:57 +02:00
|
|
|
NMConnection *connection,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error);
|
2014-06-18 20:17:57 +02:00
|
|
|
|
2022-04-27 16:27:24 +02:00
|
|
|
/* Attachs a port asynchronously. Returns TRUE/FALSE on immediate
|
|
|
|
|
* success/error; in such cases, the callback is not invoked. If the
|
|
|
|
|
* action couldn't be completed immediately, DEFAULT is returned and
|
|
|
|
|
* the callback will always be invoked asynchronously. */
|
|
|
|
|
NMTernary (*attach_port)(NMDevice *self,
|
|
|
|
|
NMDevice *port,
|
|
|
|
|
NMConnection *connection,
|
|
|
|
|
gboolean configure,
|
|
|
|
|
GCancellable *cancellable,
|
|
|
|
|
NMDeviceAttachPortCallback callback,
|
|
|
|
|
gpointer user_data);
|
2022-05-02 13:58:04 +02:00
|
|
|
void (*detach_port)(NMDevice *self, NMDevice *port, gboolean configure);
|
2013-01-25 11:59:05 -06:00
|
|
|
|
2016-12-26 11:12:39 +01:00
|
|
|
void (*parent_changed_notify)(NMDevice *self,
|
|
|
|
|
int old_ifindex,
|
|
|
|
|
NMDevice *old_parent,
|
|
|
|
|
int new_ifindex,
|
|
|
|
|
NMDevice *new_parent);
|
|
|
|
|
|
2014-02-09 10:22:19 -06:00
|
|
|
gboolean (*owns_iface)(NMDevice *self, const char *iface);
|
2014-09-08 16:11:51 -05:00
|
|
|
|
|
|
|
|
NMConnection *(*new_default_connection)(NMDevice *self);
|
2016-06-21 11:04:38 +02:00
|
|
|
|
|
|
|
|
gboolean (*unmanaged_on_quit)(NMDevice *self);
|
2017-03-03 12:06:58 +01:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*can_reapply_change)(NMDevice *self,
|
2017-03-03 12:06:58 +01:00
|
|
|
const char *setting_name,
|
2021-11-09 13:28:54 +01:00
|
|
|
NMSetting *s_old,
|
|
|
|
|
NMSetting *s_new,
|
2017-03-03 12:06:58 +01:00
|
|
|
GHashTable *diffs,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error);
|
2017-03-03 12:06:58 +01:00
|
|
|
|
|
|
|
|
void (*reapply_connection)(NMDevice *self, NMConnection *con_old, NMConnection *con_new);
|
2017-09-11 10:43:48 +02:00
|
|
|
|
2020-02-12 15:13:29 +01:00
|
|
|
guint32 (*get_dhcp_timeout_for_device)(NMDevice *self, int addr_family);
|
2019-02-10 14:01:23 +01:00
|
|
|
|
2019-09-10 10:32:55 +02:00
|
|
|
gboolean (*get_guessed_metered)(NMDevice *self);
|
|
|
|
|
|
2020-02-14 17:46:31 +01:00
|
|
|
gboolean (*can_update_from_platform_link)(NMDevice *self, const NMPlatformLink *plink);
|
|
|
|
|
|
2020-03-16 10:53:06 +01:00
|
|
|
gboolean (*set_platform_mtu)(NMDevice *self, guint32 mtu);
|
|
|
|
|
|
2021-05-12 12:47:33 +02:00
|
|
|
const char *(*get_dhcp_anycast_address)(NMDevice *self);
|
2009-07-07 14:34:01 -04:00
|
|
|
} NMDeviceClass;
|
2005-12-31 08:21:24 +00:00
|
|
|
|
|
|
|
|
GType nm_device_get_type(void);
|
|
|
|
|
|
core: pass NMDedupMultiIndex instance to NMIP4Config and other
NMIP4Config, NMIP6Config, and NMPlatform shall share one
NMDedupMultiIndex instance.
For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns.
NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config.
So currently NMNetns is the access point to the shared NMDedupMultiIndex
instance, and it gets it from it's NMPlatform instance.
The NMDedupMultiIndex instance is really a singleton, we don't want
multiple instances of it. However, for testing, instead of adding a
singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
|
|
|
struct _NMDedupMultiIndex *nm_device_get_multi_index(NMDevice *self);
|
2021-11-09 13:28:54 +01:00
|
|
|
NMNetns *nm_device_get_netns(NMDevice *self);
|
|
|
|
|
NMPlatform *nm_device_get_platform(NMDevice *self);
|
2017-04-17 20:17:45 +02:00
|
|
|
|
2016-04-04 13:52:50 +02:00
|
|
|
const char *nm_device_get_udi(NMDevice *dev);
|
|
|
|
|
const char *nm_device_get_iface(NMDevice *dev);
|
2017-06-07 12:46:10 +02:00
|
|
|
|
|
|
|
|
static inline const char *
|
|
|
|
|
_nm_device_get_iface(NMDevice *device)
|
|
|
|
|
{
|
|
|
|
|
/* like nm_device_get_iface(), but gracefully accept NULL without
|
|
|
|
|
* asserting. */
|
|
|
|
|
return device ? nm_device_get_iface(device) : NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2016-04-04 13:52:50 +02:00
|
|
|
int nm_device_get_ifindex(NMDevice *dev);
|
|
|
|
|
gboolean nm_device_is_software(NMDevice *dev);
|
|
|
|
|
gboolean nm_device_is_real(NMDevice *dev);
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *nm_device_get_ip_iface(NMDevice *dev);
|
|
|
|
|
const char *nm_device_get_ip_iface_from_platform(NMDevice *dev);
|
2017-11-10 09:32:14 +01:00
|
|
|
int nm_device_get_ip_ifindex(const NMDevice *dev);
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *nm_device_get_driver(NMDevice *dev);
|
|
|
|
|
const char *nm_device_get_driver_version(NMDevice *dev);
|
|
|
|
|
const char *nm_device_get_type_desc(NMDevice *dev);
|
|
|
|
|
const char *nm_device_get_type_description(NMDevice *dev);
|
2016-04-04 13:52:50 +02:00
|
|
|
NMDeviceType nm_device_get_device_type(NMDevice *dev);
|
|
|
|
|
NMLinkType nm_device_get_link_type(NMDevice *dev);
|
|
|
|
|
NMMetered nm_device_get_metered(NMDevice *dev);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
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
|
|
|
void nm_device_activation_state_set_preserve_external_ports(NMDevice *self, gboolean flag);
|
|
|
|
|
|
2019-04-30 14:01:10 +02:00
|
|
|
guint32 nm_device_get_route_table(NMDevice *self, int addr_family);
|
2017-09-28 17:14:24 +02:00
|
|
|
guint32 nm_device_get_route_metric(NMDevice *dev, int addr_family);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-12-06 13:16:30 +01:00
|
|
|
guint32 nm_device_get_route_metric_default(NMDeviceType device_type);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-04-04 13:52:50 +02:00
|
|
|
const char *nm_device_get_hw_address(NMDevice *dev);
|
2016-10-13 18:52:12 +02:00
|
|
|
const char *nm_device_get_permanent_hw_address(NMDevice *self);
|
2016-10-13 15:56:13 +02:00
|
|
|
const char *nm_device_get_permanent_hw_address_full(NMDevice *self,
|
2016-10-24 12:50:17 +02:00
|
|
|
gboolean force_freeze,
|
2016-10-13 15:56:13 +02:00
|
|
|
gboolean *out_is_fake);
|
2016-04-04 13:52:50 +02:00
|
|
|
const char *nm_device_get_initial_hw_address(NMDevice *dev);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-02-20 15:06:47 +01:00
|
|
|
NMDhcpConfig *nm_device_get_dhcp_config(NMDevice *dev, int addr_family);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-08-06 15:17:05 +02:00
|
|
|
NML3Cfg *nm_device_get_l3cfg(NMDevice *self);
|
|
|
|
|
|
|
|
|
|
const NML3ConfigData *nm_device_get_l3cd(NMDevice *self, gboolean get_commited);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-08-06 15:17:05 +02:00
|
|
|
void nm_device_l3cfg_commit(NMDevice *self, NML3CfgCommitType commit_type, gboolean commit_sync);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-12-26 11:12:39 +01:00
|
|
|
int nm_device_parent_get_ifindex(NMDevice *dev);
|
|
|
|
|
NMDevice *nm_device_parent_get_device(NMDevice *dev);
|
|
|
|
|
void nm_device_parent_set_ifindex(NMDevice *self, int parent_ifindex);
|
|
|
|
|
gboolean nm_device_parent_notify_changed(NMDevice *self,
|
|
|
|
|
NMDevice *change_candidate,
|
|
|
|
|
gboolean device_removed);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *nm_device_parent_find_for_connection(NMDevice *self,
|
2018-08-17 22:18:17 +02:00
|
|
|
const char *current_setting_parent);
|
|
|
|
|
|
2012-11-14 14:05:30 -06:00
|
|
|
/* Master */
|
2016-04-04 13:52:50 +02:00
|
|
|
gboolean nm_device_is_master(NMDevice *dev);
|
2012-11-14 14:05:30 -06:00
|
|
|
|
2014-01-02 14:46:02 -05:00
|
|
|
/* Slave */
|
2016-04-04 13:52:50 +02:00
|
|
|
NMDevice *nm_device_get_master(NMDevice *dev);
|
2014-01-02 14:46:02 -05:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
NMActRequest *nm_device_get_act_request(NMDevice *dev);
|
|
|
|
|
NMSettingsConnection *nm_device_get_settings_connection(NMDevice *dev);
|
|
|
|
|
NMConnection *nm_device_get_settings_connection_get_connection(NMDevice *self);
|
|
|
|
|
NMConnection *nm_device_get_applied_connection(NMDevice *dev);
|
|
|
|
|
gboolean nm_device_has_unmodified_applied_connection(NMDevice *self,
|
2016-04-04 13:52:50 +02:00
|
|
|
NMSettingCompareFlags compare_flags);
|
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 nm_device_get_activation_state_flags(NMDevice *self);
|
2018-10-22 12:53:41 +02:00
|
|
|
|
|
|
|
|
gpointer /* (NMSetting *) */ nm_device_get_applied_setting(NMDevice *dev, GType setting_type);
|
2005-12-31 08:21:24 +00:00
|
|
|
|
2016-04-20 17:46:41 +02:00
|
|
|
void nm_device_removed(NMDevice *self, gboolean unconfigure_ip_config);
|
2014-11-16 16:07:22 +01:00
|
|
|
|
2017-06-01 22:38:51 +02:00
|
|
|
gboolean nm_device_ignore_carrier_by_default(NMDevice *self);
|
|
|
|
|
|
2016-04-04 13:52:50 +02:00
|
|
|
gboolean nm_device_is_available(NMDevice *dev, NMDeviceCheckDevAvailableFlags flags);
|
|
|
|
|
gboolean nm_device_has_carrier(NMDevice *dev);
|
2008-03-07 Dan Williams <dcbw@redhat.com>
First pass of multiple active device support. Expect bugs.
* src/nm-ip4-config.c
src/nm-ip4-config.h
- (nm_ip4_config_get_secondary, nm_ip4_config_set_secondary): remove;
there are better ways to do this in the named manager
* src/nm-device.c
src/nm-device.h
- (nm_device_can_activate): return whether the device can activate a
connection right now; taking into account things like carrier state
and rfkill state
- (nm_device_get_best_auto_connection): renamed from
nm_device_get_best_connection
- (real_act_stage4_get_ip4_config): MTU stuff is now handled in the
device subclasses themselves, so that each device can override the
MTU from it's NMSetting subclass if needed
- (nm_device_set_ip4_config): set MTU when setting up routes and stuff
in NetworkManagerSystem.c, not here
* src/named-manager/nm-named-manager.c
src/named-manager/nm-named-manager.h
- (nm_named_manager_name_owner_changed,
nm_named_manager_dbus_connection_changed): fix for changes to
rewrite_resolv_conf()
- (compute_nameservers): don't need the NMNamedManager at all, remove
from parameter list
- (merge_one_ip4_config): new function; merge ip4 configs together
- (rewrite_resolv_conf): write out resolv.conf from all the stored
ip4 configs; the VPN config takes precedence, then the best
device config, then the rest of the configs
- (get_domain_for_config): take the NMNamedManager as an argument
to check whether the config is the VPN config
- (add_ip4_config_to_named): fixups for removal of the 'secondary'
attribute from ip4 configs
- (add_all_ip4_configs_to_named): add all the configs in priority order
- (remove_ip4_config_from_named): fix for changes to
get_domain_for_config()
- (nm_named_manager_add_ip4_config): assign the config to the right slot
based on its type; callers must pass in the type now
- (get_last_default_domain): remove, unused
- (nm_named_manager_remove_ip4_config): handle config slots correctly
* src/nm-device-802-11-wireless.c
- (real_can_activate): new function
- (real_get_best_auto_connection): renamed from real_get_best_connection
- (real_act_stage4_get_ip4_config): handle MTU override
* src/nm-device-802-3-ethernet.c
- (real_can_activate): new function
- (real_get_best_auto_connection): renamed from real_get_best_connection
- (real_act_stage4_get_ip4_config): new function; handle MTU override
* src/vpn-manager/nm-vpn-connection.c
- (nm_vpn_connection_ip4_config_get): don't need to set the 'secondary'
attribute on the ip4 config
* src/NetworkManagerPolicy.c
- (nm_policy_auto_get_best_device): remove
- (nm_policy_device_change_check): remove
- (update_default_route): new function; set the default route via
the specified device
- (get_device_priority): new function; return the priority number of
a device type WRT which one should have the default route. Order is
(highest to lowest) wired, wireless, GSM, CDMA.
- (update_routing_and_dns): new function; determine which device should
have the default route, then update the routing table and DNS
- (maybe_auto_activate_device): new function; if a device is now
available for activation, find out what connection it would like to
activate and do it
- (schedule_activate_check): new function; if a device can be activated
now, schedule the activation. Each device may have only one
pending activation at a given time.
- (device_state_changed): if activation was canceled, try again,
possibly with another connection; if the device was activated,
update routing and DNS; if the device was deactivated, try again
with another connection
- (device_carrier_changed): if there is no carrier, deactivate the
device; otherwise schedule an activation check for the device
- (wireless_networks_changed): schedule an activation check for the
device
- (device_added): keep track of the signal handler IDs so they can
be removed when the device goes away
- (device_removed): remove any signal handlers that might be attached
to the device; update routing and DNS
- (schedule_activate_all): new function
- (connections_added, connection_added, connection_updated): when
connections change, schedule all devices for an activation check
- (connection_removed): when a device is deactivated because its
connection was removed, schedule another activation check for it
- (nm_policy_destroy): destroy pending activations and disconnect
all device signal handlers
* src/nm-manager.c
- (nm_manager_activate_device): if the device was already actived,
deactivate it
- (deactivate_old_device): remove
- (connection_added_default_handler, impl_manager_activate_device):
don't deactivate other devices when activating this one
* src/backends/NetworkManagerGentoo.c
src/backends/NetworkManagerFrugalware.c
src/backends/NetworkManagerPaldo.c
src/backends/NetworkManagerRedHat.c
src/backends/NetworkManagerSlackware.c
src/backends/NetworkManagerArch.c
src/backends/NetworkManagerSuSE.c
src/backends/NetworkManagerDebian.c
- (nm_system_get_mtu): remove; MTU should be provided through the
distro's system settings service plugin instead
- (nm_system_device_add_default_route_via_device): remove
- (nm_system_device_add_default_route_via_device_with_iface): remove
- (nm_system_device_replace_default_route): new function; call
generic implementation
* src/backends/NetworkManagerGeneric.c
src/backends/NetworkManagerGeneric.h
- (nm_generic_device_add_default_route_via_device,
nm_generic_device_add_default_route_via_device_with_iface): remove
- (nm_generic_device_replace_default_route): replace the default route
with the given route via some gateway
* src/NetworkManagerSystem.c
src/NetworkManagerSystem.h
- (nm_system_device_set_from_ip4_config): let the policy handle updates
to routing and DNS; but set the MTU here
- (nm_system_vpn_device_set_from_ip4_config): set the route with the
ip_iface of the active device; use the standard MTU setting function
- (nm_system_set_mtu): remove
- (nm_system_device_set_mtu): consolidate MTU setting code in one place
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3391 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-07 19:41:32 +00: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
|
|
|
NMConnection *nm_device_generate_connection(NMDevice *self,
|
|
|
|
|
NMDevice *master,
|
2017-06-07 17:04:33 +02:00
|
|
|
gboolean *out_maybe_later,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error);
|
2014-06-18 20:17:57 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_device_master_update_slave_connection(NMDevice *master,
|
|
|
|
|
NMDevice *slave,
|
2014-06-18 20:17:57 +02:00
|
|
|
NMConnection *connection,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error);
|
2013-06-27 14:39:13 +02:00
|
|
|
|
2014-08-26 15:10:38 +02:00
|
|
|
gboolean
|
|
|
|
|
nm_device_can_auto_connect(NMDevice *self, NMSettingsConnection *sett_conn, char **specific_object);
|
|
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_device_complete_connection(NMDevice *device,
|
|
|
|
|
NMConnection *connection,
|
|
|
|
|
const char *specific_object,
|
core: avoid clone of all-connections list for nm_utils_complete_generic()
NMSettings exposes a cached list of all connection. We don't need
to clone it. Note that this is not save against concurrent modification,
meaning, add/remove of connections in NMSettings will invalidate the
list.
However, it wasn't save against that previously either, because
altough we cloned the container (GSList), we didn't take an additional
reference to the elements.
This is purely a performance optimization, we don't need to clone the
list. Also, since the original list is of type "NMConnection *const*",
use that type insistently, instead of dependent API requiring GSList.
IMO, GSList is anyway not a very nice API for many use cases because
it requires an additional slice allocation for each element. It's
slower, and often less convenient to use.
2018-03-14 08:57:42 +01:00
|
|
|
NMConnection *const *existing_connections,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error);
|
2011-01-10 23:39:12 -06:00
|
|
|
|
2018-06-27 17:00:55 +02:00
|
|
|
gboolean
|
|
|
|
|
nm_device_check_connection_compatible(NMDevice *device, NMConnection *connection, GError **error);
|
|
|
|
|
|
2014-10-15 21:17:45 -05:00
|
|
|
gboolean nm_device_check_slave_connection_compatible(NMDevice *device, NMConnection *connection);
|
2011-11-17 23:04:47 -06:00
|
|
|
|
2021-06-07 16:31:18 +02:00
|
|
|
gboolean nm_device_can_assume_connections(NMDevice *self);
|
2016-06-21 11:04:38 +02:00
|
|
|
gboolean nm_device_unmanage_on_quit(NMDevice *self);
|
2011-11-17 23:04:47 -06:00
|
|
|
|
2011-11-17 23:16:50 -06:00
|
|
|
gboolean nm_device_spec_match_list(NMDevice *device, const GSList *specs);
|
2017-06-01 22:32:12 +02:00
|
|
|
int nm_device_spec_match_list_full(NMDevice *self, const GSList *specs, int no_match_value);
|
2011-11-17 23:16:50 -06:00
|
|
|
|
2016-04-04 13:52:50 +02:00
|
|
|
gboolean nm_device_is_activating(NMDevice *dev);
|
|
|
|
|
gboolean nm_device_autoconnect_allowed(NMDevice *self);
|
2006-01-22 22:40:14 +00:00
|
|
|
|
2007-02-05 12:14:09 +00:00
|
|
|
NMDeviceState nm_device_get_state(NMDevice *device);
|
|
|
|
|
|
2011-11-17 23:28:30 -06:00
|
|
|
gboolean nm_device_get_enabled(NMDevice *device);
|
|
|
|
|
|
2011-11-17 23:38:08 -06:00
|
|
|
void nm_device_set_enabled(NMDevice *device, gboolean enabled);
|
|
|
|
|
|
2022-02-01 20:21:34 +01:00
|
|
|
NMRfkillType nm_device_get_rfkill_type(NMDevice *device);
|
2011-11-18 12:02:58 -06:00
|
|
|
|
2016-11-03 12:05:12 +01:00
|
|
|
/* IPv6 prefix delegation */
|
|
|
|
|
|
2021-08-06 15:17:05 +02:00
|
|
|
void nm_device_request_ip6_prefixes(NMDevice *self, guint needed_prefixes);
|
2016-11-03 12:05:12 +01:00
|
|
|
|
|
|
|
|
gboolean nm_device_needs_ip6_subnet(NMDevice *self);
|
|
|
|
|
|
|
|
|
|
void nm_device_use_ip6_subnet(NMDevice *self, const NMPlatformIP6Address *subnet);
|
|
|
|
|
|
|
|
|
|
void nm_device_copy_ip6_dns_config(NMDevice *self, NMDevice *from_device);
|
|
|
|
|
|
2014-03-31 21:45:54 -05:00
|
|
|
/**
|
|
|
|
|
* NMUnmanagedFlags:
|
|
|
|
|
* @NM_UNMANAGED_NONE: placeholder value
|
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_UNMANAGED_SLEEPING: %TRUE when unmanaged because NM is sleeping.
|
|
|
|
|
* @NM_UNMANAGED_QUITTING: %TRUE when unmanaged because NM is shutting down.
|
2015-04-13 16:29:37 -05:00
|
|
|
* @NM_UNMANAGED_PLATFORM_INIT: %TRUE when unmanaged because platform link not
|
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
|
|
|
* yet initialized. Unrealized device are also unmanaged for this reason.
|
|
|
|
|
* @NM_UNMANAGED_USER_EXPLICIT: %TRUE when unmanaged by explicit user decision
|
|
|
|
|
* (e.g. via a D-Bus command)
|
2016-02-22 14:45:45 +01:00
|
|
|
* @NM_UNMANAGED_USER_SETTINGS: %TRUE when unmanaged by user decision via
|
|
|
|
|
* the settings plugin (for example keyfile.unmanaged-devices or ifcfg-rh's
|
2016-06-22 14:04:25 +02:00
|
|
|
* NM_CONTROLLED=no). Although this is user-configuration (provided from
|
|
|
|
|
* the settings plugins, such as NM_CONTROLLED=no in ifcfg-rh), it cannot
|
2018-09-14 23:49:20 -04:00
|
|
|
* be overruled and is authoritative. That is because users may depend on
|
2016-06-22 14:04:25 +02:00
|
|
|
* dropping a ifcfg-rh file to ensure the device is unmanaged.
|
2017-09-26 16:28:49 +02:00
|
|
|
* @NM_UNMANAGED_USER_CONF: %TRUE when unmanaged by user decision via
|
|
|
|
|
* the NetworkManager.conf ("unmanaged" in the [device] section).
|
|
|
|
|
* Contray to @NM_UNMANAGED_USER_SETTINGS, this can be overwritten via
|
|
|
|
|
* D-Bus.
|
2016-02-22 15:53:06 +01:00
|
|
|
* @NM_UNMANAGED_BY_DEFAULT: %TRUE for certain device types where we unmanage
|
|
|
|
|
* them by default
|
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_UNMANAGED_USER_UDEV: %TRUE when unmanaged by user decision (via UDev rule)
|
2015-10-02 20:24:30 +02:00
|
|
|
* @NM_UNMANAGED_EXTERNAL_DOWN: %TRUE when unmanaged because !IFF_UP and not created by NM
|
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_UNMANAGED_IS_SLAVE: indicates that the device is enslaved. Note that
|
|
|
|
|
* setting the NM_UNMANAGED_IS_SLAVE to %TRUE makes no sense, this flag has only
|
|
|
|
|
* meaning to set a slave device as managed if the parent is managed too.
|
2014-03-31 21:45:54 -05:00
|
|
|
*/
|
2021-05-11 14:42:31 +02:00
|
|
|
typedef enum {
|
|
|
|
|
NM_UNMANAGED_NONE = 0,
|
2015-10-02 20:24:30 +02:00
|
|
|
|
2021-05-11 14:42:31 +02:00
|
|
|
/* these flags are authoritative. If one of them is set,
|
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
|
|
|
* the device cannot be managed. */
|
2021-05-11 14:42:31 +02:00
|
|
|
NM_UNMANAGED_SLEEPING = (1LL << 0),
|
|
|
|
|
NM_UNMANAGED_QUITTING = (1LL << 1),
|
2022-06-12 19:50:09 -04:00
|
|
|
NM_UNMANAGED_PLATFORM_INIT = (1LL << 2),
|
|
|
|
|
NM_UNMANAGED_USER_EXPLICIT = (1LL << 3),
|
|
|
|
|
NM_UNMANAGED_USER_SETTINGS = (1LL << 4),
|
2021-05-11 14:42:31 +02:00
|
|
|
|
|
|
|
|
/* These flags can be non-effective and be overwritten
|
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
|
|
|
* by other flags. */
|
2022-06-12 19:50:09 -04:00
|
|
|
NM_UNMANAGED_BY_DEFAULT = (1LL << 5),
|
|
|
|
|
NM_UNMANAGED_USER_CONF = (1LL << 6),
|
|
|
|
|
NM_UNMANAGED_USER_UDEV = (1LL << 7),
|
|
|
|
|
NM_UNMANAGED_EXTERNAL_DOWN = (1LL << 8),
|
|
|
|
|
NM_UNMANAGED_IS_SLAVE = (1LL << 9),
|
2014-03-31 21:45:54 -05:00
|
|
|
|
2022-06-12 19:50:09 -04:00
|
|
|
NM_UNMANAGED_ALL = ((1LL << 10) - 1),
|
2014-03-31 21:45:54 -05:00
|
|
|
} NMUnmanagedFlags;
|
|
|
|
|
|
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
|
|
|
typedef enum {
|
|
|
|
|
NM_UNMAN_FLAG_OP_SET_MANAGED = FALSE,
|
|
|
|
|
NM_UNMAN_FLAG_OP_SET_UNMANAGED = TRUE,
|
|
|
|
|
NM_UNMAN_FLAG_OP_FORGET = 2,
|
|
|
|
|
} NMUnmanFlagOp;
|
|
|
|
|
|
|
|
|
|
const char *nm_unmanaged_flags2str(NMUnmanagedFlags flags, char *buf, gsize len);
|
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
|
|
|
gboolean nm_device_get_managed(NMDevice *device, gboolean for_user_request);
|
2016-03-23 09:39:22 +01:00
|
|
|
NMUnmanagedFlags nm_device_get_unmanaged_mask(NMDevice *device, NMUnmanagedFlags flag);
|
2015-11-05 02:41:42 +01:00
|
|
|
NMUnmanagedFlags nm_device_get_unmanaged_flags(NMDevice *device, NMUnmanagedFlags flag);
|
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
|
|
|
void nm_device_set_unmanaged_flags(NMDevice *device, NMUnmanagedFlags flags, NMUnmanFlagOp set_op);
|
2021-11-09 13:28:54 +01:00
|
|
|
void nm_device_set_unmanaged_by_flags(NMDevice *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
|
|
|
NMUnmanagedFlags flags,
|
|
|
|
|
NMUnmanFlagOp set_op,
|
2016-01-13 12:03:47 +01:00
|
|
|
NMDeviceStateReason reason);
|
2021-11-09 13:28:54 +01:00
|
|
|
void nm_device_set_unmanaged_by_flags_queue(NMDevice *self,
|
2016-05-05 11:05:04 +02:00
|
|
|
NMUnmanagedFlags flags,
|
|
|
|
|
NMUnmanFlagOp set_op,
|
|
|
|
|
NMDeviceStateReason reason);
|
2022-02-02 09:39:23 +01:00
|
|
|
void nm_device_set_unmanaged_by_user_settings(NMDevice *self, gboolean now);
|
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
|
|
|
void nm_device_set_unmanaged_by_user_udev(NMDevice *self);
|
2017-09-26 16:28:49 +02:00
|
|
|
void nm_device_set_unmanaged_by_user_conf(NMDevice *self);
|
2016-01-13 12:03:47 +01:00
|
|
|
void nm_device_set_unmanaged_by_quitting(NMDevice *device);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-04-08 09:26:05 +02:00
|
|
|
gboolean nm_device_check_unrealized_device_managed(NMDevice *self);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-05-31 16:42:05 +02:00
|
|
|
gboolean nm_device_is_nm_owned(NMDevice *device);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-04-17 15:19:48 +02:00
|
|
|
gboolean nm_device_has_capability(NMDevice *self, NMDeviceCapabilities caps);
|
|
|
|
|
|
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
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
void nm_device_assume_state_get(NMDevice *self,
|
|
|
|
|
gboolean *out_assume_state_guess_assume,
|
manager: fix preserving assume state during activation
Originally 850c977 "device: track system interface state in NMDevice",
intended that a connection can only be assumed initially when seeing
a device for the first time. Assuming a connection later was to be
prevented by setting device's sys-iface-state to MANAGED.
That changed too much in behavior, because we used to assume external
connections also when they are activated later on. So this was attempted
to get fixed by
- acf1067 nm-manager: try assuming connections on managed devices
- b6b7d90 manager: avoid generating in memory connections during startup for managed devices
It's probably just wrong to prevent assuming connections based on the
sys-iface-state. So drop the check for sys-iface-state from
recheck_assume_connection(). Now, we can assume anytime on managed,
disconnected interfaces, like previously.
Btw, note that priv->startup is totally wrong to check there, because
priv->startup has the sole purpose of tracking startup-complete property.
Startup, as far as NMManager is concerned, is platform_query_devices().
However, the problem is that we only assume connections (contrary to
doing external activation) when we have a connection-uuid from the state
file or with guess-assume during startup.
When assuming a master device, it can fail with
(nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship)
thus, for internal reason the device cannot be assumed yet.
Fix that by attatching the assume-state to the device, so that on multiple
recheck_assume_connection() calls we still try to assume. Whenever we try
to assume the connection and it fails due to external reasons (like, the connection
no longer matching), we clear the assume state, so that we only try as
long as there are internal reasons why assuming fails.
https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
|
|
|
const char **out_assume_state_connection_uuid);
|
|
|
|
|
void nm_device_assume_state_reset(NMDevice *self);
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_device_realize_start(NMDevice *device,
|
2016-01-10 15:13:20 +01:00
|
|
|
const NMPlatformLink *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
|
|
|
gboolean assume_state_guess_assume,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *assume_state_connection_uuid,
|
2017-06-07 22:11:50 +02:00
|
|
|
gboolean set_nm_owned,
|
2016-09-26 14:45:35 +02:00
|
|
|
NMUnmanFlagOp unmanaged_user_explicit,
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean *out_compatible,
|
|
|
|
|
GError **error);
|
2016-01-10 14:56:05 +01:00
|
|
|
void nm_device_realize_finish(NMDevice *self, const NMPlatformLink *plink);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_device_create_and_realize(NMDevice *self,
|
2014-09-05 08:50:02 -05:00
|
|
|
NMConnection *connection,
|
2021-11-09 13:28:54 +01:00
|
|
|
NMDevice *parent,
|
|
|
|
|
GError **error);
|
2014-09-24 15:13:19 -05:00
|
|
|
gboolean nm_device_unrealize(NMDevice *device, gboolean remove_resources, GError **error);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-08-16 15:44:24 +02:00
|
|
|
void nm_device_update_from_platform_link(NMDevice *self, const NMPlatformLink *plink);
|
|
|
|
|
|
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum
The flags allow for more then two reasons. Currently the only reasons
for allowing or disallowing autoconnect are "user" and "intern".
It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative
meaning. So
nm_device_set_autoconnect_intern (device, FALSE);
gets replaced by
nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN);
and so on.
However, it's chosen this way, because autoconnect shall be allowed,
unless any blocked-reason is set. That is, to check whether autoconnect
is allowed, we do
if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL))
The alternative check would be
if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL)
which seems odd too.
So, add the inverse flags to block autoconnect.
Beside refactoring and inverting the meaning of the autoconnect
settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
|
|
|
typedef enum {
|
|
|
|
|
NM_DEVICE_AUTOCONNECT_BLOCKED_NONE = 0,
|
2017-11-07 12:36:17 +01:00
|
|
|
|
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum
The flags allow for more then two reasons. Currently the only reasons
for allowing or disallowing autoconnect are "user" and "intern".
It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative
meaning. So
nm_device_set_autoconnect_intern (device, FALSE);
gets replaced by
nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN);
and so on.
However, it's chosen this way, because autoconnect shall be allowed,
unless any blocked-reason is set. That is, to check whether autoconnect
is allowed, we do
if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL))
The alternative check would be
if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL)
which seems odd too.
So, add the inverse flags to block autoconnect.
Beside refactoring and inverting the meaning of the autoconnect
settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
|
|
|
NM_DEVICE_AUTOCONNECT_BLOCKED_USER = (1LL << 0),
|
2017-11-07 12:36:17 +01:00
|
|
|
|
|
|
|
|
NM_DEVICE_AUTOCONNECT_BLOCKED_WRONG_PIN = (1LL << 1),
|
|
|
|
|
NM_DEVICE_AUTOCONNECT_BLOCKED_MANUAL_DISCONNECT = (1LL << 2),
|
2018-12-11 15:50:41 +01:00
|
|
|
NM_DEVICE_AUTOCONNECT_BLOCKED_SIM_MISSING = (1LL << 3),
|
|
|
|
|
NM_DEVICE_AUTOCONNECT_BLOCKED_INIT_FAILED = (1LL << 4),
|
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum
The flags allow for more then two reasons. Currently the only reasons
for allowing or disallowing autoconnect are "user" and "intern".
It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative
meaning. So
nm_device_set_autoconnect_intern (device, FALSE);
gets replaced by
nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN);
and so on.
However, it's chosen this way, because autoconnect shall be allowed,
unless any blocked-reason is set. That is, to check whether autoconnect
is allowed, we do
if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL))
The alternative check would be
if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL)
which seems odd too.
So, add the inverse flags to block autoconnect.
Beside refactoring and inverting the meaning of the autoconnect
settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
|
|
|
|
|
|
|
|
_NM_DEVICE_AUTOCONNECT_BLOCKED_LAST,
|
2017-11-07 12:36:17 +01:00
|
|
|
|
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum
The flags allow for more then two reasons. Currently the only reasons
for allowing or disallowing autoconnect are "user" and "intern".
It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative
meaning. So
nm_device_set_autoconnect_intern (device, FALSE);
gets replaced by
nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN);
and so on.
However, it's chosen this way, because autoconnect shall be allowed,
unless any blocked-reason is set. That is, to check whether autoconnect
is allowed, we do
if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL))
The alternative check would be
if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL)
which seems odd too.
So, add the inverse flags to block autoconnect.
Beside refactoring and inverting the meaning of the autoconnect
settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
|
|
|
NM_DEVICE_AUTOCONNECT_BLOCKED_ALL = (((_NM_DEVICE_AUTOCONNECT_BLOCKED_LAST - 1) << 1) - 1),
|
2017-11-07 12:36:17 +01:00
|
|
|
|
|
|
|
|
NM_DEVICE_AUTOCONNECT_BLOCKED_INTERNAL =
|
|
|
|
|
NM_DEVICE_AUTOCONNECT_BLOCKED_ALL & ~NM_DEVICE_AUTOCONNECT_BLOCKED_USER,
|
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum
The flags allow for more then two reasons. Currently the only reasons
for allowing or disallowing autoconnect are "user" and "intern".
It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative
meaning. So
nm_device_set_autoconnect_intern (device, FALSE);
gets replaced by
nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN);
and so on.
However, it's chosen this way, because autoconnect shall be allowed,
unless any blocked-reason is set. That is, to check whether autoconnect
is allowed, we do
if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL))
The alternative check would be
if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL)
which seems odd too.
So, add the inverse flags to block autoconnect.
Beside refactoring and inverting the meaning of the autoconnect
settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
|
|
|
} NMDeviceAutoconnectBlockedFlags;
|
|
|
|
|
|
|
|
|
|
NMDeviceAutoconnectBlockedFlags
|
|
|
|
|
nm_device_autoconnect_blocked_get(NMDevice *device, NMDeviceAutoconnectBlockedFlags mask);
|
|
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
void nm_device_autoconnect_blocked_set_full(NMDevice *device,
|
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum
The flags allow for more then two reasons. Currently the only reasons
for allowing or disallowing autoconnect are "user" and "intern".
It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative
meaning. So
nm_device_set_autoconnect_intern (device, FALSE);
gets replaced by
nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN);
and so on.
However, it's chosen this way, because autoconnect shall be allowed,
unless any blocked-reason is set. That is, to check whether autoconnect
is allowed, we do
if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL))
The alternative check would be
if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL)
which seems odd too.
So, add the inverse flags to block autoconnect.
Beside refactoring and inverting the meaning of the autoconnect
settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
|
|
|
NMDeviceAutoconnectBlockedFlags mask,
|
|
|
|
|
NMDeviceAutoconnectBlockedFlags values);
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
nm_device_autoconnect_blocked_set(NMDevice *device, NMDeviceAutoconnectBlockedFlags mask)
|
|
|
|
|
{
|
|
|
|
|
nm_device_autoconnect_blocked_set_full(device, mask, mask);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
nm_device_autoconnect_blocked_unset(NMDevice *device, NMDeviceAutoconnectBlockedFlags mask)
|
|
|
|
|
{
|
|
|
|
|
nm_device_autoconnect_blocked_set_full(device, mask, NM_DEVICE_AUTOCONNECT_BLOCKED_NONE);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
void nm_device_emit_recheck_auto_activate(NMDevice *device);
|
2009-09-16 13:18:24 +02:00
|
|
|
|
2017-03-13 15:34:14 +01:00
|
|
|
NMDeviceSysIfaceState nm_device_sys_iface_state_get(NMDevice *device);
|
|
|
|
|
|
|
|
|
|
gboolean nm_device_sys_iface_state_is_external(NMDevice *self);
|
|
|
|
|
gboolean nm_device_sys_iface_state_is_external_or_assume(NMDevice *self);
|
|
|
|
|
|
|
|
|
|
void nm_device_sys_iface_state_set(NMDevice *device, NMDeviceSysIfaceState sys_iface_state);
|
|
|
|
|
|
2011-11-17 22:39:34 -06:00
|
|
|
void nm_device_state_changed(NMDevice *device, NMDeviceState state, NMDeviceStateReason reason);
|
|
|
|
|
|
2011-12-08 11:46:58 -06:00
|
|
|
void nm_device_queue_state(NMDevice *self, NMDeviceState state, NMDeviceStateReason reason);
|
|
|
|
|
|
2011-11-17 22:39:34 -06:00
|
|
|
gboolean nm_device_get_firmware_missing(NMDevice *self);
|
2011-01-05 16:23:00 -06:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
void nm_device_disconnect_active_connection(NMActiveConnection *active,
|
2018-11-20 14:25:42 +01:00
|
|
|
NMDeviceStateReason device_reason,
|
|
|
|
|
NMActiveConnectionStateReason active_reason);
|
2015-02-03 16:15:37 +01:00
|
|
|
|
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
|
|
|
void nm_device_queue_activation(NMDevice *device, NMActRequest *req);
|
2011-11-17 23:50:13 -06:00
|
|
|
|
2012-09-19 10:56:30 -04:00
|
|
|
gboolean nm_device_supports_vlans(NMDevice *device);
|
|
|
|
|
|
2014-04-28 11:18:05 +02:00
|
|
|
gboolean
|
|
|
|
|
nm_device_add_pending_action(NMDevice *device, const char *action, gboolean assert_not_yet_pending);
|
|
|
|
|
gboolean
|
|
|
|
|
nm_device_remove_pending_action(NMDevice *device, const char *action, gboolean assert_is_pending);
|
2018-09-19 17:22:50 +02:00
|
|
|
const char *nm_device_has_pending_action_reason(NMDevice *device);
|
|
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
nm_device_has_pending_action(NMDevice *device)
|
|
|
|
|
{
|
|
|
|
|
return !!nm_device_has_pending_action_reason(device);
|
|
|
|
|
}
|
2013-08-13 17:45:34 -04:00
|
|
|
|
2016-03-23 10:35:55 +01:00
|
|
|
NMSettingsConnection *
|
|
|
|
|
nm_device_get_best_connection(NMDevice *device, const char *specific_object, GError **error);
|
2013-09-03 15:34:56 -05:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_device_check_connection_available(NMDevice *device,
|
|
|
|
|
NMConnection *connection,
|
2015-01-16 16:43:48 +01:00
|
|
|
NMDeviceCheckConAvailableFlags flags,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *specific_object,
|
|
|
|
|
GError **error);
|
2013-11-04 19:51:28 -06:00
|
|
|
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
void nm_device_notify_availability_maybe_changed(NMDevice *self);
|
2014-02-09 10:22:19 -06:00
|
|
|
|
|
|
|
|
gboolean nm_device_owns_iface(NMDevice *device, const char *iface);
|
|
|
|
|
|
2014-09-08 16:11:51 -05:00
|
|
|
NMConnection *nm_device_new_default_connection(NMDevice *self);
|
|
|
|
|
|
core: rework handling of default-routes and drop NMDefaultRouteManager
Remove NMDefaultRouteManager. Instead, add the default-route to the
NMIP4Config/NMIP6Config instance.
This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797.
We added NMDefaultRouteManager because we used the corresponding to `ip
route replace` when configuring routes. That would replace default-routes
on other interfaces so we needed a central manager to coordinate routes.
Now, we use the corresponding of `ip route append` to configure routes,
and each interface can configure routes indepdentently.
In NMDevice, when creating the default-route, ignore @auto_method for
external devices. We shall not touch these devices.
Especially the code in NMPolicy regarding selection of the best-device
seems wrong. It probably needs further adjustments in the future.
Especially get_best_ip_config() should be replaced, because this
distinction VPN vs. devices seems wrong to me.
Thereby, remove the @ignore_never_default argument. It was added by
commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's
needed anymore.
This brings another change. Now that we track default-routes in
NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular
routes. I think that makes sense, but it is a change in behavior, as
previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
|
|
|
const NMPObject *nm_device_get_best_default_route(NMDevice *self, int addr_family);
|
2014-08-29 00:03:47 +02:00
|
|
|
|
2017-06-16 13:06:26 +02:00
|
|
|
gboolean nm_device_reapply(NMDevice *self, NMConnection *connection, GError **error);
|
2015-07-14 16:53:24 +02:00
|
|
|
void nm_device_reapply_settings_immediately(NMDevice *self);
|
|
|
|
|
|
|
|
|
|
void nm_device_update_firewall_zone(NMDevice *self);
|
2015-09-07 12:06:27 +02:00
|
|
|
void nm_device_update_metered(NMDevice *self);
|
2014-10-29 09:12:18 -05:00
|
|
|
|
2016-09-07 23:47:14 +02:00
|
|
|
gboolean nm_device_update_hw_address(NMDevice *self);
|
2015-12-13 22:09:59 +01:00
|
|
|
void nm_device_update_initial_hw_address(NMDevice *self);
|
2016-10-24 12:50:17 +02:00
|
|
|
void nm_device_update_permanent_hw_address(NMDevice *self, gboolean force_freeze);
|
2022-08-24 16:50:14 +02:00
|
|
|
void nm_device_update_dynamic_ip_setup(NMDevice *self, const char *reason);
|
2017-01-19 17:25:29 +01:00
|
|
|
guint nm_device_get_supplicant_timeout(NMDevice *self);
|
2017-10-24 11:11:18 +02:00
|
|
|
|
2017-11-02 10:56:30 +01:00
|
|
|
gboolean nm_device_auth_retries_try_next(NMDevice *self);
|
2017-10-24 11:11:18 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_device_hw_addr_get_cloned(NMDevice *self,
|
2017-02-21 15:54:01 +01:00
|
|
|
NMConnection *connection,
|
|
|
|
|
gboolean is_wifi,
|
2021-11-09 13:28:54 +01:00
|
|
|
char **hwaddr,
|
|
|
|
|
gboolean *preserve,
|
|
|
|
|
GError **error);
|
2015-12-13 22:09:59 +01: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
|
|
|
typedef struct _NMDeviceConnectivityHandle NMDeviceConnectivityHandle;
|
|
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
typedef void (*NMDeviceConnectivityCallback)(NMDevice *self,
|
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,
|
2017-03-20 13:36:00 +00:00
|
|
|
NMConnectivityState state,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError *error,
|
2017-03-20 13:36:00 +00:00
|
|
|
gpointer user_data);
|
connectivity: rework async connectivity check requests
An asynchronous request should either be cancellable or not keep
the target object alive. Preferably both.
Otherwise, it is impossible to do a controlled shutdown when terminating
NetworkManager. Currently, when NetworkManager is about to terminate,
it just quits the mainloop and essentially leaks everything. That is a
bug. If we ever want to fix that, every asynchronous request must be
cancellable in a controlled way (or it must not prevent objects from
getting disposed, where disposing the object automatically cancels the
callback).
Rework the asynchronous request for connectivity check to
- return a handle that can be used to cancel the operation.
Cancelling is optional. The caller may choose to ignore the handle
because the asynchronous operation does not keep the target object
alive. That means, it is still possible to shutdown, by everybody
giving up their reference to the target object. In which case the
callback will be invoked during dispose() of the target object.
- also, the callback will always be invoked exactly once, and never
synchronously from within the asynchronous start call. But during
cancel(), the callback is invoked synchronously from within cancel().
Note that it's only allowed to cancel an action at most once, and
never after the callback is invoked (also not from within the callback
itself).
- also, NMConnectivity already supports a fake handler, in case
connectivity check is disabled via configuration. Hence, reuse
the same code paths also when compiling without --enable-concheck.
That means, instead of having #if WITH_CONCHECK at various callers,
move them into NMConnectivity. The downside is, that if you build
without concheck, there is a small overhead compared to before. The
upside is, we reuse the same code paths when compiling with or without
concheck.
- also, the patch synchronizes the connecitivty states. For example,
previously `nmcli networking connectivity check` would schedule
requests in parallel, and return the accumulated result of the individual
requests.
However, the global connectivity state of the manager might have have
been the same as the answer to the explicit connecitivity check,
because while the answer for the manual check is waiting for all
pending checks to complete, the global connectivity state could
already change. That is just wrong. There are not multiple global
connectivity states at the same time, there is just one. A manual
connectivity check should have the meaning of ensure that the global
state is up to date, but it still should return the global
connectivity state -- not the answers for several connectivity checks
issued in parallel.
This is related to commit b799de281bc01073c31dd2c86171b29c8132441c
(libnm: update property in the manager after connectivity check),
which tries to address a similar problem client side.
Similarly, each device has a connectivity state. While there might
be several connectivity checks per device pending, whenever a check
completes, it can update the per-device state (and return that device
state as result), but the immediate answer of the individual check
might not matter. This is especially the case, when a later request
returns earlier and obsoletes all earlier requests. In that case,
earlier requests return with the result of the currend devices
connectivity state.
This patch cleans up the internal API and gives a better defined behavior
to the user (thus, the simple API which simplifies implementation for the
caller). However, the implementation of getting this API right and properly
handle cancel and destruction of the target object is more complicated and
complex. But this but is not just for the sake of a nicer API. This fixes
actual issues explained above.
Also, get rid of GAsyncResult to track information about the pending request.
Instead, allocate our own handle structure, which ends up to be nicer
because it's strongly typed and has exactly the properties that are
useful to track the request. Also, it gets rid of the awkward
_finish() API by passing the relevant arguments to the callback
directly.
2018-01-05 17:46:49 +01:00
|
|
|
|
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
|
|
|
void nm_device_check_connectivity_update_interval(NMDevice *self);
|
|
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
NMDeviceConnectivityHandle *nm_device_check_connectivity(NMDevice *self,
|
2018-07-03 19:20:45 +02:00
|
|
|
int addr_family,
|
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
|
|
|
NMDeviceConnectivityCallback callback,
|
|
|
|
|
gpointer user_data);
|
|
|
|
|
|
|
|
|
|
void nm_device_check_connectivity_cancel(NMDeviceConnectivityHandle *handle);
|
|
|
|
|
|
2018-12-03 11:09:39 +01:00
|
|
|
NMConnectivityState nm_device_get_connectivity_state(NMDevice *self, int addr_family);
|
2017-03-20 13:36:00 +00:00
|
|
|
|
2017-05-23 13:06:50 +02:00
|
|
|
typedef struct _NMBtVTableNetworkServer NMBtVTableNetworkServer;
|
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
|
|
|
|
|
|
|
|
typedef void (*NMBtVTableRegisterCallback)(GError *error, gpointer user_data);
|
|
|
|
|
|
2017-05-23 13:06:50 +02:00
|
|
|
struct _NMBtVTableNetworkServer {
|
|
|
|
|
gboolean (*is_available)(const NMBtVTableNetworkServer *vtable,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *addr,
|
|
|
|
|
NMDevice *device_accept_busy);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-05-23 13:06:50 +02:00
|
|
|
gboolean (*register_bridge)(const NMBtVTableNetworkServer *vtable,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *addr,
|
|
|
|
|
NMDevice *device,
|
|
|
|
|
GCancellable *cancellable,
|
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
|
|
|
NMBtVTableRegisterCallback callback,
|
|
|
|
|
gpointer callback_user_data,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error);
|
2017-05-23 13:06:50 +02:00
|
|
|
gboolean (*unregister_bridge)(const NMBtVTableNetworkServer *vtable, NMDevice *device);
|
|
|
|
|
};
|
|
|
|
|
|
2020-02-12 11:05:24 +01:00
|
|
|
gboolean nm_device_is_vpn(NMDevice *self);
|
|
|
|
|
|
2020-11-12 08:47:25 +01:00
|
|
|
const char *
|
|
|
|
|
nm_device_get_hostname_from_dns_lookup(NMDevice *self, int addr_family, gboolean *out_pending);
|
|
|
|
|
|
2020-12-17 14:13:45 +01:00
|
|
|
void nm_device_clear_dns_lookup_data(NMDevice *self);
|
|
|
|
|
|
2022-07-22 10:28:30 -04:00
|
|
|
gboolean nm_device_get_allow_autoconnect_on_external(NMDevice *self);
|
|
|
|
|
|
2016-08-17 18:19:00 +02:00
|
|
|
#endif /* __NETWORKMANAGER_DEVICE_H__ */
|