2020-12-23 22:21:36 +01:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2019-09-25 13:13:40 +02:00
|
|
|
/*
|
2018-05-24 15:03:40 +02:00
|
|
|
* Copyright (C) 2009 - 2018 Red Hat, Inc.
|
2013-03-27 22:23:24 +01: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_PLATFORM_H__
|
|
|
|
|
#define __NETWORKMANAGER_PLATFORM_H__
|
2013-03-27 22:23:24 +01:00
|
|
|
|
2021-02-18 08:13:35 +01:00
|
|
|
#include "libnm-platform/nmp-base.h"
|
2021-02-18 08:13:35 +01:00
|
|
|
#include "libnm-base/nm-base.h"
|
2022-09-20 12:46:06 +02:00
|
|
|
#include "nmp-plobj.h"
|
2020-12-25 17:54:46 +01:00
|
|
|
|
2013-03-27 22:23:24 +01:00
|
|
|
#define NM_TYPE_PLATFORM (nm_platform_get_type())
|
2022-12-14 16:21:48 +01:00
|
|
|
#define NM_PLATFORM(obj) (_NM_G_TYPE_CHECK_INSTANCE_CAST((obj), NM_TYPE_PLATFORM, NMPlatform))
|
2013-03-27 22:23:24 +01:00
|
|
|
#define NM_PLATFORM_CLASS(klass) \
|
|
|
|
|
(G_TYPE_CHECK_CLASS_CAST((klass), NM_TYPE_PLATFORM, NMPlatformClass))
|
|
|
|
|
#define NM_IS_PLATFORM(obj) (G_TYPE_CHECK_INSTANCE_TYPE((obj), NM_TYPE_PLATFORM))
|
|
|
|
|
#define NM_IS_PLATFORM_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE((klass), NM_TYPE_PLATFORM))
|
|
|
|
|
#define NM_PLATFORM_GET_CLASS(obj) \
|
|
|
|
|
(G_TYPE_INSTANCE_GET_CLASS((obj), NM_TYPE_PLATFORM, NMPlatformClass))
|
|
|
|
|
|
2016-04-07 12:22:44 +02:00
|
|
|
#define NM_PLATFORM_NETNS_SUPPORT_DEFAULT FALSE
|
|
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2013-03-27 22:23:24 +01:00
|
|
|
|
2022-12-16 18:07:07 +01:00
|
|
|
#define NM_PLATFORM_CACHE_TC "cache-tc"
|
|
|
|
|
#define NM_PLATFORM_LOG_WITH_PTR "log-with-ptr"
|
|
|
|
|
#define NM_PLATFORM_MULTI_IDX "multi-idx"
|
2016-02-19 01:06:28 +01:00
|
|
|
#define NM_PLATFORM_NETNS_SUPPORT "netns-support"
|
2017-06-29 10:51:38 +02:00
|
|
|
#define NM_PLATFORM_USE_UDEV "use-udev"
|
2015-05-12 07:34:56 +02:00
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2015-05-12 07:34:56 +02:00
|
|
|
|
2018-12-25 18:41:28 +01:00
|
|
|
struct _NMPWireGuardPeer;
|
|
|
|
|
|
2017-03-12 15:54:02 +01:00
|
|
|
struct udev_device;
|
|
|
|
|
|
2017-08-14 14:52:55 +02:00
|
|
|
typedef gboolean (*NMPObjectPredicateFunc)(const NMPObject *obj, gpointer user_data);
|
|
|
|
|
|
platform: add non-exclusive routes and drop route-manager
Previously, we would add exclusive routes via netlink message flags
NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`.
Using that form of RTM_NEWROUTE message, we could only add a certain
route with a certain network/plen,metric triple once. That was already
hugely inconvenient, because
- when configuring routes, multiple (managed) interfaces may get
conflicting routes (multihoming). Only one of the routes can be actually
configured using `ip route replace`, so we need to track routes that are
currently shadowed.
- when configuring routes, we might replace externally configured
routes on unmanaged interfaces. We should not interfere with such
routes.
That was worked around by having NMRouteManager (and NMDefaultRouteManager).
NMRouteManager would keep a list of the routes which NetworkManager would like
to configure, even if momentarily being unable to do so due to conflicting routes.
This worked mostly well but was complicated. It involved bumping metrics to
avoid conflicts for device routes, as we might require them for gateway routes.
Drop that now. Instead, use the corresponding of `ip route append` to configure
routes. This allows NetworkManager to confiure (almost) all routes that we care.
Especially, it can configure all routes on a managed interface, without
replacing/interfering with routes on other interfaces. Hence, NMRouteManager
becomes obsolete.
It practice it is a bit more complicated because:
- when adding an IPv4 address, kernel will automatically create a device route
for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for
IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4
addresses yet (and we don't require such a kernel yet), we still need functionality
similar to nm_route_manager_ip4_route_register_device_route_purge_list().
This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set().
- trying to configure an IPv6 route with a source address will be rejected
by kernel as long as the address is tentative (see related bug rh#1457196).
Preferably, NMDevice would keep the list of routes which should be configured,
while kernel would have the list of what actually is configured. There is a
feed-back loop where both affect each other (for example, when externally deleting
a route, NMDevice must forget about it too). Previously, NMRouteManager would have
the task of remembering all routes which we currently want to configure, but cannot
due to conflicting routes.
We get rid of that, because now we configure non-exclusive routes. We however still
will need to remember IPv6 routes with a source address, that currently cannot be
configured yet. Hence, we will need to keep track of routes that
currently cannot be configured, but later may be.
That is still not done yet, as NMRouteManager didn't handle this
correctly either.
2017-08-14 14:18:53 +02:00
|
|
|
#define NM_RT_SCOPE_LINK 253 /* RT_SCOPE_LINK */
|
|
|
|
|
|
2015-09-15 15:07:37 +02:00
|
|
|
#define NM_IFF_MULTI_QUEUE 0x0100 /* IFF_MULTI_QUEUE */
|
|
|
|
|
|
2022-07-13 16:24:05 +02:00
|
|
|
#define NM_MPTCP_PM_ADDR_FLAG_SIGNAL ((guint32) (1 << 0))
|
|
|
|
|
#define NM_MPTCP_PM_ADDR_FLAG_SUBFLOW ((guint32) (1 << 1))
|
|
|
|
|
#define NM_MPTCP_PM_ADDR_FLAG_BACKUP ((guint32) (1 << 2))
|
|
|
|
|
#define NM_MPTCP_PM_ADDR_FLAG_FULLMESH ((guint32) (1 << 3))
|
|
|
|
|
#define NM_MPTCP_PM_ADDR_FLAG_IMPLICIT ((guint32) (1 << 4))
|
2025-11-13 19:19:07 +01:00
|
|
|
#define NM_MPTCP_PM_ADDR_FLAG_LAMINAR ((guint32) (1 << 5))
|
2022-07-13 16:24:05 +02:00
|
|
|
|
2015-09-01 22:11:47 +02:00
|
|
|
/* Redefine this in host's endianness */
|
|
|
|
|
#define NM_GRE_KEY 0x2000
|
|
|
|
|
|
2017-08-02 10:27:32 +02:00
|
|
|
typedef enum {
|
2020-05-22 15:26:43 +02:00
|
|
|
NMP_NLM_FLAG_F_ECHO = 0x08, /* NLM_F_ECHO, Echo this request */
|
|
|
|
|
|
2017-08-02 10:27:32 +02:00
|
|
|
/* use our own platform enum for the nlmsg-flags. Otherwise, we'd have
|
|
|
|
|
* to include <linux/netlink.h> */
|
|
|
|
|
NMP_NLM_FLAG_F_REPLACE = 0x100, /* NLM_F_REPLACE, Override existing */
|
|
|
|
|
NMP_NLM_FLAG_F_EXCL = 0x200, /* NLM_F_EXCL, Do not touch, if it exists */
|
|
|
|
|
NMP_NLM_FLAG_F_CREATE = 0x400, /* NLM_F_CREATE, Create, if it does not exist */
|
|
|
|
|
NMP_NLM_FLAG_F_APPEND = 0x800, /* NLM_F_APPEND, Add to end of list */
|
|
|
|
|
|
2017-08-21 18:02:08 +02:00
|
|
|
NMP_NLM_FLAG_FMASK = 0xFFFF, /* a mask for all NMP_NLM_FLAG_F_* flags */
|
|
|
|
|
|
|
|
|
|
/* instructs NM to suppress logging an error message for any failures
|
|
|
|
|
* received from kernel.
|
|
|
|
|
*
|
|
|
|
|
* It will still log with debug-level, and it will still log
|
|
|
|
|
* other failures aside the kernel response. */
|
|
|
|
|
NMP_NLM_FLAG_SUPPRESS_NETLINK_FAILURE = 0x10000,
|
|
|
|
|
|
2017-08-02 10:27:32 +02:00
|
|
|
/* the following aliases correspond to iproute2's `ip route CMD` for
|
|
|
|
|
* RTM_NEWROUTE, with CMD being one of add, change, replace, prepend,
|
|
|
|
|
* append and test. */
|
|
|
|
|
NMP_NLM_FLAG_ADD = NMP_NLM_FLAG_F_CREATE | NMP_NLM_FLAG_F_EXCL,
|
|
|
|
|
NMP_NLM_FLAG_CHANGE = NMP_NLM_FLAG_F_REPLACE,
|
|
|
|
|
NMP_NLM_FLAG_REPLACE = NMP_NLM_FLAG_F_CREATE | NMP_NLM_FLAG_F_REPLACE,
|
|
|
|
|
NMP_NLM_FLAG_PREPEND = NMP_NLM_FLAG_F_CREATE,
|
|
|
|
|
NMP_NLM_FLAG_APPEND = NMP_NLM_FLAG_F_CREATE | NMP_NLM_FLAG_F_APPEND,
|
|
|
|
|
NMP_NLM_FLAG_TEST = NMP_NLM_FLAG_F_EXCL,
|
|
|
|
|
} NMPNlmFlags;
|
|
|
|
|
|
2017-07-26 10:50:23 +02:00
|
|
|
typedef enum {
|
|
|
|
|
/* compare fields which kernel considers as similar routes.
|
|
|
|
|
* It is a looser comparisong then NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID
|
|
|
|
|
* and means that `ip route add` would fail to add two routes
|
|
|
|
|
* that have the same NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID.
|
|
|
|
|
* On the other hand, `ip route append` would allow that, as
|
|
|
|
|
* long as NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID differs. */
|
|
|
|
|
NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID,
|
|
|
|
|
|
2025-02-28 18:37:15 +01:00
|
|
|
/* compare two routes as kernel would allow one to add them with
|
2017-07-26 10:50:23 +02:00
|
|
|
* `ip route append`. In other words, kernel does not allow you to
|
|
|
|
|
* add two routes (at the same time) which compare equal according
|
|
|
|
|
* to NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID.
|
|
|
|
|
*
|
|
|
|
|
* For the ID we can only recognize route fields that we actually implement.
|
|
|
|
|
* However, kernel supports more routing options, some of them also part of
|
|
|
|
|
* the ID. NetworkManager is oblivious to these options and will wrongly think
|
2020-07-04 11:37:01 +03:00
|
|
|
* that two routes are identical, while they are not. That can lead to an
|
2017-07-26 10:50:23 +02:00
|
|
|
* inconsistent platform cache. Not much what we can do about that, except
|
|
|
|
|
* implementing all options that kernel supports *sigh*. See rh#1337860.
|
|
|
|
|
*/
|
|
|
|
|
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID,
|
|
|
|
|
|
2022-11-08 15:56:56 +01:00
|
|
|
/* IPv4 route can have multiple hops. This is the ID, by which multiple
|
|
|
|
|
* routes are merged according to the next hop. This is basically NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID
|
|
|
|
|
* which ignores the next hops. */
|
|
|
|
|
NM_PLATFORM_IP_ROUTE_CMP_TYPE_ECMP_ID,
|
|
|
|
|
|
2017-07-26 10:50:23 +02:00
|
|
|
/* compare all fields as they make sense for kernel. For example,
|
|
|
|
|
* a route destination 192.168.1.5/24 is not accepted by kernel and
|
|
|
|
|
* we treat it identical to 192.168.1.0/24. Semantically these
|
|
|
|
|
* routes are identical, but NM_PLATFORM_IP_ROUTE_CMP_TYPE_FULL will
|
2017-09-02 16:56:27 +02:00
|
|
|
* report them as different.
|
|
|
|
|
*
|
|
|
|
|
* The result shall be identical to call first nm_platform_ip_route_normalize()
|
|
|
|
|
* on both routes and then doing a full comparison. */
|
2017-07-26 10:50:23 +02:00
|
|
|
NM_PLATFORM_IP_ROUTE_CMP_TYPE_SEMANTICALLY,
|
|
|
|
|
|
|
|
|
|
/* compare all fields. This should have the same effect as memcmp(),
|
|
|
|
|
* except allowing for undefined data in holes between field alignment.
|
|
|
|
|
*/
|
|
|
|
|
NM_PLATFORM_IP_ROUTE_CMP_TYPE_FULL,
|
|
|
|
|
|
|
|
|
|
} NMPlatformIPRouteCmpType;
|
|
|
|
|
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
typedef enum {
|
|
|
|
|
NM_PLATFORM_ROUTING_RULE_CMP_TYPE_ID,
|
|
|
|
|
|
|
|
|
|
NM_PLATFORM_ROUTING_RULE_CMP_TYPE_SEMANTICALLY,
|
|
|
|
|
|
|
|
|
|
NM_PLATFORM_ROUTING_RULE_CMP_TYPE_FULL,
|
|
|
|
|
} NMPlatformRoutingRuleCmpType;
|
|
|
|
|
|
2019-05-30 07:54:11 +02:00
|
|
|
typedef struct {
|
2020-09-24 12:55:37 +02:00
|
|
|
union {
|
2021-03-03 20:57:01 +01:00
|
|
|
guint8 data[20 /* _NM_UTILS_HWADDR_LEN_MAX */];
|
2020-09-24 12:55:37 +02:00
|
|
|
NMEtherAddr ether_addr;
|
|
|
|
|
};
|
2019-05-30 07:54:11 +02:00
|
|
|
guint8 len;
|
|
|
|
|
} NMPLinkAddress;
|
|
|
|
|
|
2020-09-24 12:55:37 +02:00
|
|
|
/* assert that NMEtherAddr does not affect the alignment of NMPLinkAddress struct. */
|
|
|
|
|
G_STATIC_ASSERT(_nm_alignof(NMEtherAddr) == 1);
|
|
|
|
|
G_STATIC_ASSERT(_nm_alignof(NMPLinkAddress) == 1);
|
|
|
|
|
|
2019-05-30 07:54:11 +02:00
|
|
|
gconstpointer nmp_link_address_get(const NMPLinkAddress *addr, size_t *length);
|
2021-11-09 13:28:54 +01:00
|
|
|
GBytes *nmp_link_address_get_as_bytes(const NMPLinkAddress *addr);
|
2019-05-30 07:54:11 +02:00
|
|
|
|
2015-08-17 17:48:37 +02:00
|
|
|
#define NM_PLATFORM_LINK_OTHER_NETNS (-1)
|
|
|
|
|
|
2023-02-16 16:37:54 +01:00
|
|
|
typedef struct {
|
|
|
|
|
guint32 tx_queue_length;
|
|
|
|
|
guint32 gso_max_size;
|
|
|
|
|
guint32 gso_max_segments;
|
|
|
|
|
guint32 gro_max_size;
|
|
|
|
|
} NMPlatformLinkProps;
|
|
|
|
|
|
|
|
|
|
typedef enum {
|
|
|
|
|
NM_PLATFORM_LINK_CHANGE_NONE = 0,
|
|
|
|
|
NM_PLATFORM_LINK_CHANGE_TX_QUEUE_LENGTH = (1 << 0),
|
|
|
|
|
NM_PLATFORM_LINK_CHANGE_GSO_MAX_SIZE = (1 << 1),
|
|
|
|
|
NM_PLATFORM_LINK_CHANGE_GSO_MAX_SEGMENTS = (1 << 2),
|
|
|
|
|
NM_PLATFORM_LINK_CHANGE_GRO_MAX_SIZE = (1 << 3),
|
|
|
|
|
} NMPlatformLinkChangeFlags;
|
|
|
|
|
|
2019-03-04 13:01:21 +01:00
|
|
|
struct _NMPlatformObjWithIfindex {
|
|
|
|
|
__NMPlatformObjWithIfindex_COMMON;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject);
|
2019-03-04 13:01:21 +01:00
|
|
|
|
2023-03-03 16:36:23 +01:00
|
|
|
typedef struct {
|
2023-03-09 12:18:14 +01:00
|
|
|
gint32 prio;
|
2023-03-03 16:36:23 +01:00
|
|
|
guint16 queue_id;
|
2023-03-09 12:18:14 +01:00
|
|
|
bool prio_has : 1;
|
2023-03-03 16:36:23 +01:00
|
|
|
} NMPlatformLinkBondPort;
|
|
|
|
|
|
2023-06-06 17:32:22 +02:00
|
|
|
typedef struct {
|
|
|
|
|
guint32 path_cost;
|
|
|
|
|
guint16 priority;
|
|
|
|
|
bool hairpin;
|
|
|
|
|
} NMPlatformLinkBridgePort;
|
|
|
|
|
|
2023-03-03 16:36:23 +01:00
|
|
|
typedef union {
|
2023-06-06 17:32:22 +02:00
|
|
|
NMPlatformLinkBondPort bond;
|
|
|
|
|
NMPlatformLinkBridgePort bridge;
|
2023-03-03 16:36:23 +01:00
|
|
|
} NMPlatformLinkPortData;
|
|
|
|
|
|
2014-07-17 17:06:44 -04:00
|
|
|
struct _NMPlatformLink {
|
2019-03-04 13:01:21 +01:00
|
|
|
__NMPlatformObjWithIfindex_COMMON;
|
2023-05-25 15:05:29 +02:00
|
|
|
char name[NM_IFNAMSIZ];
|
2013-03-27 22:23:24 +01:00
|
|
|
NMLinkType type;
|
2015-04-28 10:11:04 +02:00
|
|
|
|
2015-04-29 09:19:15 +02:00
|
|
|
/* rtnl_link_get_type(), IFLA_INFO_KIND. */
|
|
|
|
|
/* NMPlatform initializes this field with a static string. */
|
2015-04-28 10:11:04 +02:00
|
|
|
const char *kind;
|
|
|
|
|
|
2015-04-29 09:19:15 +02:00
|
|
|
/* NMPlatform initializes this field with a static string. */
|
2013-05-29 12:00:50 -03:00
|
|
|
const char *driver;
|
2015-04-29 09:19:15 +02:00
|
|
|
|
2024-05-27 17:58:08 +02:00
|
|
|
int controller;
|
2015-08-17 17:48:37 +02:00
|
|
|
|
|
|
|
|
/* rtnl_link_get_link(), IFLA_LINK.
|
|
|
|
|
* If IFLA_LINK_NETNSID indicates that the parent is in another namespace,
|
|
|
|
|
* this field be set to (negative) NM_PLATFORM_LINK_OTHER_NETNS. */
|
2013-06-03 11:49:55 -03:00
|
|
|
int parent;
|
2015-04-25 16:42:26 +02:00
|
|
|
|
2016-02-29 15:57:37 +01:00
|
|
|
/* IFF_* flags. Note that the flags in 'struct ifinfomsg' are declared as 'unsigned'. */
|
|
|
|
|
guint n_ifi_flags;
|
|
|
|
|
|
|
|
|
|
guint mtu;
|
|
|
|
|
|
2015-04-27 18:45:23 +02:00
|
|
|
/* rtnl_link_get_arptype(), ifinfomsg.ifi_type. */
|
|
|
|
|
guint32 arptype;
|
|
|
|
|
|
2019-05-30 07:54:11 +02:00
|
|
|
/* IFLA_ADDRESS */
|
|
|
|
|
NMPLinkAddress l_address;
|
|
|
|
|
|
2021-07-26 10:57:30 -04:00
|
|
|
/* IFLA_PERM_ADDRESS */
|
|
|
|
|
NMPLinkAddress l_perm_address;
|
|
|
|
|
|
2019-05-30 07:54:11 +02:00
|
|
|
/* IFLA_BROADCAST */
|
|
|
|
|
NMPLinkAddress l_broadcast;
|
2015-04-27 18:06:59 +02:00
|
|
|
|
2016-04-29 21:25:43 +02:00
|
|
|
/* rtnl_link_inet6_get_token(), IFLA_INET6_TOKEN */
|
|
|
|
|
NMUtilsIPv6IfaceId inet6_token;
|
2015-04-27 21:05:13 +02:00
|
|
|
|
2015-04-27 18:32:43 +02:00
|
|
|
/* The bitwise inverse of rtnl_link_inet6_get_addr_gen_mode(). It is inverse
|
|
|
|
|
* to have a default of 0 -- meaning: unspecified. That way, a struct
|
|
|
|
|
* initialized with memset(0) has and unset value.*/
|
|
|
|
|
guint8 inet6_addr_gen_mode_inv;
|
|
|
|
|
|
2016-08-10 11:54:30 +02:00
|
|
|
/* Statistics */
|
|
|
|
|
guint64 rx_packets;
|
|
|
|
|
guint64 rx_bytes;
|
|
|
|
|
guint64 tx_packets;
|
|
|
|
|
guint64 tx_bytes;
|
|
|
|
|
|
2023-02-16 16:37:54 +01:00
|
|
|
NMPlatformLinkProps link_props;
|
|
|
|
|
|
2023-03-03 16:36:23 +01:00
|
|
|
/* an interface can only hold IFLA_INFO_SLAVE_DATA for one link type */
|
|
|
|
|
NMPlatformLinkPortData port_data;
|
|
|
|
|
|
2024-07-04 12:45:42 +02:00
|
|
|
/* IFLA_INFO_PORT_KIND */
|
2023-03-09 12:18:14 +01:00
|
|
|
NMPortKind port_kind;
|
|
|
|
|
|
2024-05-27 17:58:08 +02:00
|
|
|
/* @connected is mostly identical to (@n_ifi_flags & IFF_UP). Except for bridge/bond controllers,
|
2024-07-04 12:45:42 +02:00
|
|
|
* where we coerce the link as disconnect if it has no ports. */
|
2016-02-29 15:57:37 +01:00
|
|
|
bool connected : 1;
|
2015-04-25 16:42:26 +02:00
|
|
|
|
2016-02-29 15:57:37 +01:00
|
|
|
bool initialized : 1;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject);
|
2013-03-27 22:23:24 +01:00
|
|
|
|
2022-02-02 12:12:12 +01:00
|
|
|
typedef enum {
|
|
|
|
|
NM_PLATFORM_SIGNAL_ID_NONE,
|
|
|
|
|
NM_PLATFORM_SIGNAL_ID_LINK,
|
|
|
|
|
NM_PLATFORM_SIGNAL_ID_IP4_ADDRESS,
|
|
|
|
|
NM_PLATFORM_SIGNAL_ID_IP6_ADDRESS,
|
|
|
|
|
NM_PLATFORM_SIGNAL_ID_IP4_ROUTE,
|
|
|
|
|
NM_PLATFORM_SIGNAL_ID_IP6_ROUTE,
|
|
|
|
|
NM_PLATFORM_SIGNAL_ID_ROUTING_RULE,
|
|
|
|
|
NM_PLATFORM_SIGNAL_ID_QDISC,
|
|
|
|
|
NM_PLATFORM_SIGNAL_ID_TFILTER,
|
|
|
|
|
_NM_PLATFORM_SIGNAL_ID_LAST,
|
2015-11-27 12:54:31 +01:00
|
|
|
} NMPlatformSignalIdType;
|
|
|
|
|
|
|
|
|
|
guint _nm_platform_signal_id_get(NMPlatformSignalIdType signal_type);
|
|
|
|
|
|
2014-11-26 20:47:44 +01:00
|
|
|
/* Default value for adding an IPv4 route. This is also what iproute2 does.
|
|
|
|
|
* Note that contrary to IPv6, you can add routes with metric 0 and it is even
|
|
|
|
|
* the default.
|
|
|
|
|
*/
|
platform: add flags to NMPlatformIP[46]Route to allow overriding the route table and metric
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
2020-09-23 13:38:39 +02:00
|
|
|
#define NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP4 ((guint32) 0u)
|
2014-11-26 20:47:44 +01:00
|
|
|
|
|
|
|
|
/* Default value for adding an IPv6 route. This is also what iproute2 does.
|
2020-07-03 15:25:51 +02:00
|
|
|
* Adding an IPv6 route with metric 0, kernel translates to IP6_RT_PRIO_USER (1024).
|
|
|
|
|
*
|
|
|
|
|
* Note that kernel doesn't allow adding IPv6 routes with metric zero via netlink.
|
|
|
|
|
* It however can itself add routes with metric zero. */
|
platform: add flags to NMPlatformIP[46]Route to allow overriding the route table and metric
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
2020-09-23 13:38:39 +02:00
|
|
|
#define NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP6 ((guint32) 1024u)
|
2014-01-06 15:15:55 -06:00
|
|
|
|
2014-11-11 14:55:07 +01:00
|
|
|
/* For IPv4, kernel adds a device route (subnet routes) with metric 0 when user
|
|
|
|
|
* configures addresses. */
|
platform: add flags to NMPlatformIP[46]Route to allow overriding the route table and metric
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
2020-09-23 13:38:39 +02:00
|
|
|
#define NM_PLATFORM_ROUTE_METRIC_IP4_DEVICE_ROUTE ((guint32) 0u)
|
2014-11-11 14:55:07 +01:00
|
|
|
|
2020-10-22 10:29:03 +02:00
|
|
|
#define __NMPlatformIPRoute_COMMON \
|
|
|
|
|
__NMPlatformObjWithIfindex_COMMON; \
|
|
|
|
|
\
|
2026-02-24 11:51:50 +01:00
|
|
|
/* rtm_flags and rtnh_flags
|
2022-05-09 15:22:45 +02:00
|
|
|
*
|
|
|
|
|
* Routes with rtm_flags RTM_F_CLONED are hidden by platform and
|
|
|
|
|
* do not exist from the point-of-view of platform users.
|
|
|
|
|
* Such a route is not alive, according to nmp_object_is_alive().
|
|
|
|
|
*
|
|
|
|
|
* NOTE: currently we ignore all flags except RTM_F_CLONED
|
|
|
|
|
* and RTNH_F_ONLINK.
|
2026-02-24 11:51:50 +01:00
|
|
|
*
|
|
|
|
|
* For IPv4 routes, the RTNH_F_ONLINK flag here applies to the
|
|
|
|
|
* first nexthop (which is embedded in the route struct). Extra
|
|
|
|
|
* nexthops (NMPlatformIP4RtNextHop) each have their own
|
|
|
|
|
* rtnh_flags field.
|
|
|
|
|
*
|
|
|
|
|
* For single-hop routes, this field comes directly from
|
|
|
|
|
* rtm_flags. For multi-hop routes from kernel, the first
|
|
|
|
|
* nexthop's RTNH_F_ONLINK from rtnh_flags is merged here. */ \
|
2022-05-09 15:22:45 +02:00
|
|
|
unsigned r_rtm_flags; \
|
|
|
|
|
\
|
|
|
|
|
/* RTA_METRICS.RTAX_ADVMSS (iproute2: advmss) */ \
|
|
|
|
|
guint32 mss; \
|
|
|
|
|
\
|
|
|
|
|
/* RTA_METRICS.RTAX_WINDOW (iproute2: window) */ \
|
|
|
|
|
guint32 window; \
|
|
|
|
|
\
|
|
|
|
|
/* RTA_METRICS.RTAX_CWND (iproute2: cwnd) */ \
|
|
|
|
|
guint32 cwnd; \
|
|
|
|
|
\
|
|
|
|
|
/* RTA_METRICS.RTAX_INITCWND (iproute2: initcwnd) */ \
|
|
|
|
|
guint32 initcwnd; \
|
|
|
|
|
\
|
|
|
|
|
/* RTA_METRICS.RTAX_INITRWND (iproute2: initrwnd) */ \
|
|
|
|
|
guint32 initrwnd; \
|
|
|
|
|
\
|
2022-06-23 21:59:40 +02:00
|
|
|
/* RTA_METRICS.RTAX_RTO_MIN (iproute2: rto_min) */ \
|
2025-04-03 16:04:09 +02:00
|
|
|
/* Valid only when 'rto_min_set' is true. */ \
|
2022-06-23 21:59:40 +02:00
|
|
|
guint32 rto_min; \
|
|
|
|
|
\
|
2022-05-09 15:22:45 +02:00
|
|
|
/* RTA_METRICS.RTAX_MTU (iproute2: mtu) */ \
|
|
|
|
|
guint32 mtu; \
|
|
|
|
|
\
|
|
|
|
|
/* RTA_PRIORITY (iproute2: metric)
|
|
|
|
|
* If "metric_any" is %TRUE, then this is interpreted as an offset that will be
|
|
|
|
|
* added to a default base metric. In such cases, the offset is usually zero. */ \
|
|
|
|
|
guint32 metric; \
|
|
|
|
|
\
|
|
|
|
|
/* rtm_table, RTA_TABLE.
|
|
|
|
|
*
|
|
|
|
|
* This is not the original table ID. Instead, 254 (RT_TABLE_MAIN) and
|
|
|
|
|
* zero (RT_TABLE_UNSPEC) are swapped, so that the default is the main
|
|
|
|
|
* table. Use nm_platform_route_table_coerce()/nm_platform_route_table_uncoerce(). */ \
|
|
|
|
|
guint32 table_coerced; \
|
platform: extend NMIPConfigSource to preserve the rtm_protocol field
For addresses (NMPlatformIPAddress) the @addr_source field is ignored
on a platform level. That is, all addresses inside the platform cache
have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason,
the source should not be a part of the NMPlatformIPAddress structure, but
it is convenient for users to piggy back the source inside the platform
address structure.
For routes, the source is stored in NMPlatformIPRoute's @rt_source
field. When adding a route to kernel, we set the @rtm_protocol of the
route depending on the source. However, we want to map different source
values to the same protocol value.
On the other hand, when kernel sends us a route that gets put inside
the cache, we must preserve the protocol value and must not map
different protocol values to the same source.
The reason is, that a user can add two routes that only differ by
@rtm_protocol. In that sense, the @rtm_protocol fields is part of the
unique ID of a kernel route, and thus different values must map to
different sources.
Fix this, by extending the range of NMIPConfigSource to contain
a range of protocol fields.
2016-04-11 17:35:29 +02:00
|
|
|
/* The NMIPConfigSource. For routes that we receive from cache this corresponds
|
|
|
|
|
* to the rtm_protocol field (and is one of the NM_IP_CONFIG_SOURCE_RTPROT_* values).
|
|
|
|
|
* When adding a route, the source will be coerced to the protocol using
|
2017-07-19 12:51:22 +02:00
|
|
|
* nmp_utils_ip_config_source_coerce_to_rtprot().
|
|
|
|
|
*
|
|
|
|
|
* rtm_protocol is part of the primary key of an IPv4 route (meaning, you can add
|
|
|
|
|
* two IPv4 routes that only differ in their rtm_protocol. For IPv6, that is not
|
|
|
|
|
* the case.
|
|
|
|
|
*
|
|
|
|
|
* When deleting an IPv4/IPv6 route, the rtm_protocol field must match (even
|
|
|
|
|
* if it is not part of the primary key for IPv6) -- unless rtm_protocol is set
|
2020-10-22 10:29:03 +02:00
|
|
|
* to zero, in which case the first matching route (with proto ignored) is deleted. */ \
|
|
|
|
|
NMIPConfigSource rt_source; \
|
|
|
|
|
\
|
2017-07-27 06:47:11 +02:00
|
|
|
/* RTA_METRICS:
|
|
|
|
|
*
|
|
|
|
|
* For IPv4 routes, these properties are part of their
|
2020-07-04 11:37:01 +03:00
|
|
|
* ID (meaning: you can add otherwise identical IPv4 routes that
|
2017-07-27 06:47:11 +02:00
|
|
|
* only differ by the metric property).
|
|
|
|
|
* On the other hand, for IPv6 you cannot add two IPv6 routes that only differ
|
|
|
|
|
* by an RTA_METRICS property.
|
2017-07-26 07:26:18 +02:00
|
|
|
*
|
2018-09-14 23:49:20 -04:00
|
|
|
* When deleting a route, kernel seems to ignore the RTA_METRICS properties.
|
2017-07-27 06:47:11 +02:00
|
|
|
* That is a problem/bug for IPv4 because you cannot explicitly select which
|
2020-10-22 10:29:03 +02:00
|
|
|
* route to delete. Kernel just picks the first. See rh#1475642. */ \
|
|
|
|
|
\
|
|
|
|
|
/* RTA_METRICS.RTAX_LOCK (iproute2: "lock" arguments) */ \
|
|
|
|
|
bool lock_window : 1; \
|
|
|
|
|
bool lock_cwnd : 1; \
|
|
|
|
|
bool lock_initcwnd : 1; \
|
|
|
|
|
bool lock_initrwnd : 1; \
|
|
|
|
|
bool lock_mtu : 1; \
|
2022-06-23 21:59:40 +02:00
|
|
|
bool lock_mss : 1; \
|
|
|
|
|
\
|
|
|
|
|
/* RTA_METRICS.RTAX_QUICKACK (iproute2: quickack) */ \
|
|
|
|
|
bool quickack : 1; \
|
2020-10-22 10:29:03 +02:00
|
|
|
\
|
2025-04-03 15:39:37 +02:00
|
|
|
/* RTA_METRICS.RTAX_RTO_MIN (iproute2: rto_min) */ \
|
2025-04-03 16:04:09 +02:00
|
|
|
/* If true, the 'rto_min' value is valid. */ \
|
2025-04-03 15:39:37 +02:00
|
|
|
bool rto_min_set : 1; \
|
|
|
|
|
\
|
2020-10-22 10:29:03 +02:00
|
|
|
/* if TRUE, the "metric" field is interpreted as an offset that is added to a default
|
|
|
|
|
* metric. For example, form a DHCP lease we don't know the actually used metric, because
|
|
|
|
|
* that is determined by upper layers (the configuration). However, we have a default
|
|
|
|
|
* metric that should be used. So we set "metric_any" to %TRUE, which means to use
|
|
|
|
|
* the default metric. However, we still treat the "metric" field as an offset that
|
|
|
|
|
* will be added to the default metric. In most case, you want that "metric" is zero
|
|
|
|
|
* when setting "metric_any". */ \
|
|
|
|
|
bool metric_any : 1; \
|
|
|
|
|
\
|
platform: add flags to NMPlatformIP[46]Route to allow overriding the route table and metric
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
2020-09-23 13:38:39 +02:00
|
|
|
/* like "metric_any", the table is determined by other layers of the code.
|
2020-10-22 10:29:03 +02:00
|
|
|
* This field overrides "table_coerced" field. If "table_any" is true, then
|
|
|
|
|
* the "table_coerced" field is ignored (unlike for the metric). */ \
|
|
|
|
|
bool table_any : 1; \
|
2021-11-11 22:16:14 +01:00
|
|
|
/* Meta flags not honored by NMPlatform (netlink code). Instead, they can be
|
|
|
|
|
* used by the upper layers which use NMPlatformIPRoute to track routes that
|
2022-04-28 13:38:39 +02:00
|
|
|
* should be configured. */ \
|
2021-11-11 22:16:14 +01:00
|
|
|
/* Whether the route should be committed even if it was removed externally. */ \
|
|
|
|
|
bool r_force_commit : 1; \
|
2021-09-06 13:58:59 +02:00
|
|
|
\
|
2020-05-29 17:53:02 +02:00
|
|
|
/* rtm_type.
|
|
|
|
|
*
|
|
|
|
|
* This is not the original type, if type_coerced is 0 then
|
|
|
|
|
* it means RTN_UNSPEC otherwise the type value is preserved.
|
2022-05-09 15:05:12 +02:00
|
|
|
*/ \
|
2022-05-09 15:22:45 +02:00
|
|
|
guint8 type_coerced; \
|
|
|
|
|
\
|
2022-09-20 12:46:06 +02:00
|
|
|
/* Don't have a bitfield as last field in __NMPlatformIPRoute_COMMON. It would then
|
2022-05-09 15:05:12 +02:00
|
|
|
* be unclear how the following fields get merged. We could also use a zero bitfield,
|
2022-09-20 12:46:06 +02:00
|
|
|
* but instead we just have there the uint8 field. */ \
|
2022-05-09 15:22:45 +02:00
|
|
|
guint8 plen; \
|
2021-09-10 13:43:34 +02:00
|
|
|
;
|
2017-07-27 07:21:01 +02:00
|
|
|
|
2014-04-03 11:02:48 +02:00
|
|
|
typedef struct {
|
|
|
|
|
__NMPlatformIPRoute_COMMON;
|
2022-05-09 15:05:12 +02:00
|
|
|
_nm_alignas(NMIPAddr) guint8 network_ptr[];
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformIPRoute;
|
2014-04-03 11:02:48 +02:00
|
|
|
|
2017-11-07 19:58:35 +01:00
|
|
|
#define NM_PLATFORM_IP_ROUTE_CAST(route) \
|
|
|
|
|
NM_CONSTCAST(NMPlatformIPRoute, \
|
|
|
|
|
(route), \
|
|
|
|
|
NMPlatformIPXRoute, \
|
|
|
|
|
NMPlatformIP4Route, \
|
|
|
|
|
NMPlatformIP6Route)
|
|
|
|
|
|
2014-07-29 19:10:08 +02:00
|
|
|
#define NM_PLATFORM_IP_ROUTE_IS_DEFAULT(route) (NM_PLATFORM_IP_ROUTE_CAST(route)->plen <= 0)
|
|
|
|
|
|
2014-07-17 17:06:44 -04:00
|
|
|
struct _NMPlatformIP4Route {
|
2014-04-03 11:02:48 +02:00
|
|
|
__NMPlatformIPRoute_COMMON;
|
2022-09-15 14:03:51 +02:00
|
|
|
|
2013-03-27 22:23:24 +01:00
|
|
|
in_addr_t network;
|
2017-07-19 13:03:28 +02:00
|
|
|
|
2022-09-15 14:03:51 +02:00
|
|
|
/* If n_nexthops is zero, the the address has no next hops. That applies
|
|
|
|
|
* to certain route types like blackhole.
|
|
|
|
|
* If n_nexthops is 1, then the fields "ifindex", "gateway" and "weight"
|
|
|
|
|
* are the first next-hop. There are no further nexthops.
|
|
|
|
|
* If n_nexthops is greater than 1, the first next hop is in the fields
|
|
|
|
|
* "ifindex", "gateway", "weight", and the (n_nexthops-1) hops are in
|
|
|
|
|
* NMPObjectIP4Route.extra_nexthops field (outside the NMPlatformIP4Route
|
|
|
|
|
* struct).
|
|
|
|
|
*
|
|
|
|
|
* For convenience, if ifindex > 0 and n_nexthops == 0, we assume that n_nexthops
|
|
|
|
|
* is in fact 1. If ifindex is <= 0, n_nexthops must be zero.
|
|
|
|
|
* See nm_platform_ip4_route_get_n_nexthops(). */
|
|
|
|
|
guint n_nexthops;
|
|
|
|
|
|
|
|
|
|
/* RTA_GATEWAY. The gateway is part of the primary key for a route.
|
|
|
|
|
* If n_nexthops is zero, this value is undefined (should be zero).
|
|
|
|
|
* If n_nexthops is greater or equal to one, this is the gateway of
|
|
|
|
|
* the first hop. */
|
2013-03-27 22:23:24 +01:00
|
|
|
in_addr_t gateway;
|
2015-05-03 10:47:41 +02:00
|
|
|
|
2025-01-30 15:54:18 -05:00
|
|
|
/* RTA_VIA. Part of the primary key for a route. Allows a gateway for a
|
|
|
|
|
* route to exist in a different address family.
|
2025-06-16 13:52:47 +02:00
|
|
|
* Only valid if: n_nexthops == 1, gateway == 0, via.family != AF_UNSPEC
|
2025-01-30 15:54:18 -05:00
|
|
|
*/
|
|
|
|
|
NMIPAddrTyped via;
|
|
|
|
|
|
2017-07-26 09:25:21 +02:00
|
|
|
/* RTA_PREFSRC (called "src" by iproute2).
|
|
|
|
|
*
|
|
|
|
|
* pref_src is part of the ID of an IPv4 route. When deleting a route,
|
|
|
|
|
* pref_src must match, unless set to 0.0.0.0 to match any. */
|
2015-10-29 09:26:10 +01:00
|
|
|
in_addr_t pref_src;
|
2017-07-19 13:03:28 +02:00
|
|
|
|
platform: fix handling "weight" for IPv4 routes
The hash/cmp functions were wrong with respect to IPv4 routes. Fix that.
- the weight was cast to a guint8, which is too small to hold all
values.
- NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID comparison would normalize a zero
weight to one
NM_CMP_DIRECT(NM_MAX(a->weight, 1u), NM_MAX(b->weight, 1u));
That was very wrong.
- the handling of the weight depends on the n_nexthops parameter.
See _ip4_route_weight_normalize().
The remarkable thing is that upper layers find it useful to track IPv4
single-hop routes with a non-zero weight. Consequently, this is honored
by NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID to treat single-hop routes
different, when their weight differs. However, adding such a route in
kernel will not work. To kernel, single-hop routes have no weight. While
the route exists as distinct in our hash tables, according to the
implemented identity, it never exists in kernel (or NMPlatform cache).
Well, you can call nm_platform_ip_route_add() with such a route, but the
result will have a weight of zero (making it a different route). See also
nm_platform_ip_route_normalize().
This works all mostly fine. The only thing to take care is that you
cannot look into the NMPlatform cache and ever find a IPv4 single-hop
route with a non-zero weight. If you preform such a lookup, realize that
such routes don't exist in platform. You can however normalize the
weight to zero first (nm_platform_ip_route_normalize()) and look for a
similar route with a zero weight.
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2023-11-28 12:37:01 +01:00
|
|
|
/* This is the weight of for the first next-hop.
|
libnm,platform: fix range for "weight" property of next hops for routes
In kernel, the valid range for the weight is 1-256 (on netlink this is
expressed as u8 in rtnh_hops, ranging 0-255).
We need an additional value, to represent
- unset weight, for non-ECMP routes in kernel.
- in libnm API, to express routes that should not be merged as ECMP
routes (the default).
Extend the type in NMPlatformIP4Route.weight to u16, and fix the code
for the special handling of the numeric range.
Also the libnm API needs to change. Modify the type of the attribute on
D-Bus from "b" to "u", to use a 32 bit integer. We use 32 bit, because
we already have common code to handle 32 bit unsigned integers, despite
only requiring 257 values. It seems better to stick to a few data types
(u32) instead of introducing more, only because the range is limited.
Co-Authored-By: Fernando Fernandez Mancera <ffmancera@riseup.net>
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2022-12-24 21:50:38 +01:00
|
|
|
*
|
platform: fix handling "weight" for IPv4 routes
The hash/cmp functions were wrong with respect to IPv4 routes. Fix that.
- the weight was cast to a guint8, which is too small to hold all
values.
- NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID comparison would normalize a zero
weight to one
NM_CMP_DIRECT(NM_MAX(a->weight, 1u), NM_MAX(b->weight, 1u));
That was very wrong.
- the handling of the weight depends on the n_nexthops parameter.
See _ip4_route_weight_normalize().
The remarkable thing is that upper layers find it useful to track IPv4
single-hop routes with a non-zero weight. Consequently, this is honored
by NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID to treat single-hop routes
different, when their weight differs. However, adding such a route in
kernel will not work. To kernel, single-hop routes have no weight. While
the route exists as distinct in our hash tables, according to the
implemented identity, it never exists in kernel (or NMPlatform cache).
Well, you can call nm_platform_ip_route_add() with such a route, but the
result will have a weight of zero (making it a different route). See also
nm_platform_ip_route_normalize().
This works all mostly fine. The only thing to take care is that you
cannot look into the NMPlatform cache and ever find a IPv4 single-hop
route with a non-zero weight. If you preform such a lookup, realize that
such routes don't exist in platform. You can however normalize the
weight to zero first (nm_platform_ip_route_normalize()) and look for a
similar route with a zero weight.
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2023-11-28 12:37:01 +01:00
|
|
|
* For multi-hop routes (n_nexthops > 1) this is the weight of the first
|
|
|
|
|
* hop. Note that the valid range is from 1-256. Zero is treated the same
|
|
|
|
|
* as 1 (for NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID comparison).
|
libnm,platform: fix range for "weight" property of next hops for routes
In kernel, the valid range for the weight is 1-256 (on netlink this is
expressed as u8 in rtnh_hops, ranging 0-255).
We need an additional value, to represent
- unset weight, for non-ECMP routes in kernel.
- in libnm API, to express routes that should not be merged as ECMP
routes (the default).
Extend the type in NMPlatformIP4Route.weight to u16, and fix the code
for the special handling of the numeric range.
Also the libnm API needs to change. Modify the type of the attribute on
D-Bus from "b" to "u", to use a 32 bit integer. We use 32 bit, because
we already have common code to handle 32 bit unsigned integers, despite
only requiring 257 values. It seems better to stick to a few data types
(u32) instead of introducing more, only because the range is limited.
Co-Authored-By: Fernando Fernandez Mancera <ffmancera@riseup.net>
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2022-12-24 21:50:38 +01:00
|
|
|
*
|
platform: fix handling "weight" for IPv4 routes
The hash/cmp functions were wrong with respect to IPv4 routes. Fix that.
- the weight was cast to a guint8, which is too small to hold all
values.
- NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID comparison would normalize a zero
weight to one
NM_CMP_DIRECT(NM_MAX(a->weight, 1u), NM_MAX(b->weight, 1u));
That was very wrong.
- the handling of the weight depends on the n_nexthops parameter.
See _ip4_route_weight_normalize().
The remarkable thing is that upper layers find it useful to track IPv4
single-hop routes with a non-zero weight. Consequently, this is honored
by NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID to treat single-hop routes
different, when their weight differs. However, adding such a route in
kernel will not work. To kernel, single-hop routes have no weight. While
the route exists as distinct in our hash tables, according to the
implemented identity, it never exists in kernel (or NMPlatform cache).
Well, you can call nm_platform_ip_route_add() with such a route, but the
result will have a weight of zero (making it a different route). See also
nm_platform_ip_route_normalize().
This works all mostly fine. The only thing to take care is that you
cannot look into the NMPlatform cache and ever find a IPv4 single-hop
route with a non-zero weight. If you preform such a lookup, realize that
such routes don't exist in platform. You can however normalize the
weight to zero first (nm_platform_ip_route_normalize()) and look for a
similar route with a zero weight.
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2023-11-28 12:37:01 +01:00
|
|
|
* For routes without next-hop (e.g. blackhole type), the weight is
|
|
|
|
|
* meaningless. It should be set to zero. NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID
|
|
|
|
|
* will treat it as zero.
|
libnm,platform: fix range for "weight" property of next hops for routes
In kernel, the valid range for the weight is 1-256 (on netlink this is
expressed as u8 in rtnh_hops, ranging 0-255).
We need an additional value, to represent
- unset weight, for non-ECMP routes in kernel.
- in libnm API, to express routes that should not be merged as ECMP
routes (the default).
Extend the type in NMPlatformIP4Route.weight to u16, and fix the code
for the special handling of the numeric range.
Also the libnm API needs to change. Modify the type of the attribute on
D-Bus from "b" to "u", to use a 32 bit integer. We use 32 bit, because
we already have common code to handle 32 bit unsigned integers, despite
only requiring 257 values. It seems better to stick to a few data types
(u32) instead of introducing more, only because the range is limited.
Co-Authored-By: Fernando Fernandez Mancera <ffmancera@riseup.net>
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2022-12-24 21:50:38 +01:00
|
|
|
*
|
platform: fix handling "weight" for IPv4 routes
The hash/cmp functions were wrong with respect to IPv4 routes. Fix that.
- the weight was cast to a guint8, which is too small to hold all
values.
- NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID comparison would normalize a zero
weight to one
NM_CMP_DIRECT(NM_MAX(a->weight, 1u), NM_MAX(b->weight, 1u));
That was very wrong.
- the handling of the weight depends on the n_nexthops parameter.
See _ip4_route_weight_normalize().
The remarkable thing is that upper layers find it useful to track IPv4
single-hop routes with a non-zero weight. Consequently, this is honored
by NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID to treat single-hop routes
different, when their weight differs. However, adding such a route in
kernel will not work. To kernel, single-hop routes have no weight. While
the route exists as distinct in our hash tables, according to the
implemented identity, it never exists in kernel (or NMPlatform cache).
Well, you can call nm_platform_ip_route_add() with such a route, but the
result will have a weight of zero (making it a different route). See also
nm_platform_ip_route_normalize().
This works all mostly fine. The only thing to take care is that you
cannot look into the NMPlatform cache and ever find a IPv4 single-hop
route with a non-zero weight. If you preform such a lookup, realize that
such routes don't exist in platform. You can however normalize the
weight to zero first (nm_platform_ip_route_normalize()) and look for a
similar route with a zero weight.
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2023-11-28 12:37:01 +01:00
|
|
|
* For single-hop routes, in kernel they don't have a weight. That means,
|
|
|
|
|
* all routes in the platform cache have a weight of zero. For tracking
|
|
|
|
|
* purposes, we find it useful that upper layers have single-hop routes
|
|
|
|
|
* with a positive weight. Such routes can never exist in kernel. Trying
|
|
|
|
|
* to add such a route will somewhat work, because
|
|
|
|
|
* nm_platform_ip_route_normalize() normalizes the weight to zero
|
|
|
|
|
* (effectively adding another route, according to
|
|
|
|
|
* NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID). A lookup in the platform cache with
|
|
|
|
|
* such a route will not yield a result. It does not exist there. If you
|
|
|
|
|
* want to find such a route, normalize it first.
|
|
|
|
|
*/
|
libnm,platform: fix range for "weight" property of next hops for routes
In kernel, the valid range for the weight is 1-256 (on netlink this is
expressed as u8 in rtnh_hops, ranging 0-255).
We need an additional value, to represent
- unset weight, for non-ECMP routes in kernel.
- in libnm API, to express routes that should not be merged as ECMP
routes (the default).
Extend the type in NMPlatformIP4Route.weight to u16, and fix the code
for the special handling of the numeric range.
Also the libnm API needs to change. Modify the type of the attribute on
D-Bus from "b" to "u", to use a 32 bit integer. We use 32 bit, because
we already have common code to handle 32 bit unsigned integers, despite
only requiring 257 values. It seems better to stick to a few data types
(u32) instead of introducing more, only because the range is limited.
Co-Authored-By: Fernando Fernandez Mancera <ffmancera@riseup.net>
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2022-12-24 21:50:38 +01:00
|
|
|
guint16 weight;
|
|
|
|
|
|
2017-08-02 07:16:35 +02:00
|
|
|
/* rtm_tos (iproute2: tos)
|
|
|
|
|
*
|
|
|
|
|
* For IPv4, tos is part of the weak-id (like metric).
|
|
|
|
|
*
|
|
|
|
|
* For IPv6, tos is ignored by kernel. */
|
|
|
|
|
guint8 tos;
|
|
|
|
|
|
2017-07-19 13:03:28 +02:00
|
|
|
/* The bitwise inverse of the route scope rtm_scope. It is inverted so that the
|
|
|
|
|
* default value (RT_SCOPE_NOWHERE) is zero. Use nm_platform_route_scope_inv()
|
all: add support for "scope" attribute for IPv4 routes
- systemd-networkd and initscripts both support it.
- it seems suggested to configure routes with scope "link" on AWS.
- the scope is only supported for IPv4 routes. Kernel ignores the
attribute for IPv6 routes.
- we don't support the aliases like "link" or "global". Instead
only the numeric value is supported. This is different from
systemd-networkd, which accepts names like "global" and "link",
but no numerical values. I think restricting ourself only to
the aliases unnecessarily limits what is possible on netlink.
The alternative would be to allow aliases and numbers both,
but that causes multiple ways to define something and has
thus downsides. So, only numeric values.
- when setting rtm_scope to RT_SCOPE_NOWHERE (0, the default), kernel
will coerce that to RT_SCOPE_LINK. This ambiguity of nowhere vs. link
is a problem, but we don't do anything about it.
- The other problem is, that when deleting a route with scope RT_SCOPE_NOWHERE,
this acts as a wild care and removes the first route that matches (given the
other route attributes). That means, NetworkManager has no meaningful
way to delete a route with scope zero, there is always the danger that
we might delete the wrong route. But this is nothing new to this
patch. The problem existed already previously, except that
NetworkManager could only add routes with scope nowhere (i.e. link).
2019-11-27 13:18:52 +01:00
|
|
|
* to convert back and forth between the inverse representation and the
|
2017-07-19 13:03:28 +02:00
|
|
|
* real value.
|
|
|
|
|
*
|
|
|
|
|
* rtm_scope is part of the primary key for IPv4 routes. When deleting a route,
|
|
|
|
|
* the scope must match, unless it is left at RT_SCOPE_NOWHERE, in which case the first
|
|
|
|
|
* matching route is deleted.
|
|
|
|
|
*
|
|
|
|
|
* For IPv6 routes, the scope is ignored and kernel always assumes global scope.
|
|
|
|
|
* Hence, this field is only in NMPlatformIP4Route. */
|
|
|
|
|
guint8 scope_inv;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject);
|
2013-03-27 22:23:24 +01:00
|
|
|
|
2014-07-17 17:06:44 -04:00
|
|
|
struct _NMPlatformIP6Route {
|
2014-04-03 11:02:48 +02:00
|
|
|
__NMPlatformIPRoute_COMMON;
|
2013-03-27 22:23:24 +01:00
|
|
|
struct in6_addr network;
|
2017-07-19 13:03:28 +02:00
|
|
|
|
|
|
|
|
/* RTA_GATEWAY. The gateway is part of the primary key for a route */
|
2013-03-27 22:23:24 +01:00
|
|
|
struct in6_addr gateway;
|
2017-07-19 13:03:28 +02:00
|
|
|
|
2017-07-26 09:25:21 +02:00
|
|
|
/* RTA_PREFSRC (called "src" by iproute2).
|
|
|
|
|
*
|
|
|
|
|
* pref_src is not part of the ID for an IPv6 route. You cannot add two
|
|
|
|
|
* routes that only differ by pref_src.
|
|
|
|
|
*
|
|
|
|
|
* When deleting a route, pref_src is ignored by kernel. */
|
2017-02-09 17:26:04 +01:00
|
|
|
struct in6_addr pref_src;
|
2017-07-26 09:25:21 +02:00
|
|
|
|
2017-07-26 09:25:21 +02:00
|
|
|
/* RTA_SRC and rtm_src_len (called "from" by iproute2).
|
|
|
|
|
*
|
|
|
|
|
* Kernel clears the host part of src/src_plen.
|
|
|
|
|
*
|
|
|
|
|
* src/src_plen is part of the ID of a route just like network/plen. That is,
|
2025-02-28 17:56:00 +01:00
|
|
|
* Not only `ip route append`, but also `ip route add` allows one to add routes that only
|
2017-07-26 09:25:21 +02:00
|
|
|
* differ in their src/src_plen.
|
|
|
|
|
*/
|
2017-02-15 14:00:44 +01:00
|
|
|
struct in6_addr src;
|
|
|
|
|
guint8 src_plen;
|
2017-10-09 11:09:16 +02:00
|
|
|
|
|
|
|
|
/* RTA_PREF router preference.
|
|
|
|
|
*
|
|
|
|
|
* The type is guint8 to keep the struct size small. But the values are compatible with
|
|
|
|
|
* the NMIcmpv6RouterPref enum. */
|
|
|
|
|
guint8 rt_pref;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject);
|
2014-04-03 11:02:48 +02:00
|
|
|
|
2014-11-10 14:23:44 +01:00
|
|
|
typedef union {
|
|
|
|
|
NMPlatformIPRoute rx;
|
|
|
|
|
NMPlatformIP4Route r4;
|
|
|
|
|
NMPlatformIP6Route r6;
|
|
|
|
|
} NMPlatformIPXRoute;
|
|
|
|
|
|
2014-04-03 11:02:48 +02:00
|
|
|
#undef __NMPlatformIPRoute_COMMON
|
|
|
|
|
|
2024-10-04 10:45:56 +02:00
|
|
|
#define NM_PLATFORM_IP4_ROUTE_INIT(...) (&((const NMPlatformIP4Route) {__VA_ARGS__}))
|
2021-08-27 08:38:19 +02:00
|
|
|
|
2024-10-04 10:45:56 +02:00
|
|
|
#define NM_PLATFORM_IP6_ROUTE_INIT(...) (&((const NMPlatformIP6Route) {__VA_ARGS__}))
|
2021-08-27 08:38:19 +02:00
|
|
|
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
typedef struct {
|
|
|
|
|
/* struct fib_rule_uid_range */
|
|
|
|
|
guint32 start;
|
|
|
|
|
guint32 end;
|
|
|
|
|
} NMFibRuleUidRange;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
/* struct fib_rule_port_range */
|
|
|
|
|
guint16 start;
|
|
|
|
|
guint16 end;
|
|
|
|
|
} NMFibRulePortRange;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
NMIPAddr src; /* FRA_SRC */
|
|
|
|
|
NMIPAddr dst; /* FRA_DST */
|
|
|
|
|
guint64 tun_id; /* betoh64(FRA_TUN_ID) */
|
|
|
|
|
guint32 table; /* (struct fib_rule_hdr).table, FRA_TABLE */
|
|
|
|
|
guint32 flags; /* (struct fib_rule_hdr).flags */
|
|
|
|
|
guint32 priority; /* RA_PRIORITY */
|
|
|
|
|
guint32 fwmark; /* FRA_FWMARK */
|
|
|
|
|
guint32 fwmask; /* FRA_FWMASK */
|
|
|
|
|
guint32 goto_target; /* FRA_GOTO */
|
|
|
|
|
guint32 flow; /* FRA_FLOW */
|
|
|
|
|
guint32 suppress_prefixlen_inverse; /* ~(FRA_SUPPRESS_PREFIXLEN) */
|
|
|
|
|
guint32 suppress_ifgroup_inverse; /* ~(FRA_SUPPRESS_IFGROUP) */
|
|
|
|
|
NMFibRuleUidRange uid_range; /* FRA_UID_RANGE */
|
|
|
|
|
NMFibRulePortRange sport_range; /* FRA_SPORT_RANGE */
|
|
|
|
|
NMFibRulePortRange dport_range; /* FRA_DPORT_RANGE */
|
2023-05-25 15:05:29 +02:00
|
|
|
char iifname[NM_IFNAMSIZ]; /* FRA_IIFNAME */
|
|
|
|
|
char oifname[NM_IFNAMSIZ]; /* FRA_OIFNAME */
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
guint8 addr_family; /* (struct fib_rule_hdr).family */
|
|
|
|
|
guint8 action; /* (struct fib_rule_hdr).action */
|
|
|
|
|
guint8 tos; /* (struct fib_rule_hdr).tos */
|
|
|
|
|
guint8 src_len; /* (struct fib_rule_hdr).src_len */
|
|
|
|
|
guint8 dst_len; /* (struct fib_rule_hdr).dst_len */
|
|
|
|
|
guint8 l3mdev; /* FRA_L3MDEV */
|
|
|
|
|
guint8 protocol; /* FRA_PROTOCOL */
|
|
|
|
|
guint8 ip_proto; /* FRA_IP_PROTO */
|
2020-09-28 16:03:33 +02:00
|
|
|
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
bool uid_range_has : 1; /* has(FRA_UID_RANGE) */
|
2022-12-14 17:01:48 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformRoutingRule;
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
|
2019-05-01 08:43:31 +02:00
|
|
|
#define NM_PLATFORM_FQ_CODEL_MEMORY_LIMIT_UNSET (~((guint32) 0))
|
|
|
|
|
|
platform: fix handling of default value for TCA_FQ_CODEL_CE_THRESHOLD
iproute2 uses the special value ~0u to indicate not to set
TCA_FQ_CODEL_CE_THRESHOLD in RTM_NEWQDISC. When not explicitly
setting the value, kernel treats the threshold as disabled.
However note that 0xFFFFFFFFu is not an invalid threshold (as far as
kernel is concerned). Thus, we should not use that as value to indicate
that the value is unset. Note that iproute2 uses the special value ~0u
only internally thereby making it impossible to set the threshold to
0xFFFFFFFFu). But kernel does not have this limitation.
Maybe the cleanest way would be to add another field to NMPlatformQDisc:
guint32 ce_threshold;
bool ce_threshold_set:1;
that indicates whether the threshold is enable or not.
But note that kernel does:
static void codel_params_init(struct codel_params *params)
{
...
params->ce_threshold = CODEL_DISABLED_THRESHOLD;
static int fq_codel_change(struct Qdisc *sch, struct nlattr *opt,
struct netlink_ext_ack *extack)
{
...
if (tb[TCA_FQ_CODEL_CE_THRESHOLD]) {
u64 val = nla_get_u32(tb[TCA_FQ_CODEL_CE_THRESHOLD]);
q->cparams.ce_threshold = (val * NSEC_PER_USEC) >> CODEL_SHIFT;
}
static int fq_codel_dump(struct Qdisc *sch, struct sk_buff *skb)
{
...
if (q->cparams.ce_threshold != CODEL_DISABLED_THRESHOLD &&
nla_put_u32(skb, TCA_FQ_CODEL_CE_THRESHOLD,
codel_time_to_us(q->cparams.ce_threshold)))
goto nla_put_failure;
This means, kernel internally uses the special value 0x83126E97u to indicate
that the threshold is disabled (WTF). That is because
(((guint64) 0x83126E97u) * NSEC_PER_USEC) >> CODEL_SHIFT == CODEL_DISABLED_THRESHOLD
So in kernel API this value is reserved (and has a special meaning
to indicate that the threshold is disabled). So, instead of adding a
ce_threshold_set flag, use the same value that kernel anyway uses.
2019-05-01 09:19:59 +02:00
|
|
|
#define NM_PLATFORM_FQ_CODEL_CE_THRESHOLD_DISABLED ((guint32) 0x83126E97u)
|
|
|
|
|
|
|
|
|
|
G_STATIC_ASSERT(((((guint64) NM_PLATFORM_FQ_CODEL_CE_THRESHOLD_DISABLED) * 1000u) >> 10)
|
|
|
|
|
== (guint64) INT_MAX);
|
|
|
|
|
|
2019-04-09 13:42:52 +02:00
|
|
|
typedef struct {
|
|
|
|
|
guint32 limit;
|
|
|
|
|
guint32 flows;
|
|
|
|
|
guint32 target;
|
|
|
|
|
guint32 interval;
|
|
|
|
|
guint32 quantum;
|
2020-09-29 09:02:29 +02:00
|
|
|
|
|
|
|
|
/* TCA_FQ_CODEL_CE_THRESHOLD: kernel internally stores this value as
|
|
|
|
|
* ((val64 * NSEC_PER_USEC) >> CODEL_SHIFT). The default value (in
|
|
|
|
|
* the domain with this coercion) is CODEL_DISABLED_THRESHOLD (INT_MAX).
|
|
|
|
|
* That means, "disabled" is expressed on RTM_NEWQDISC netlink API by absence of the
|
|
|
|
|
* netlink attribute but also as the special value 0x83126E97u
|
|
|
|
|
* (NM_PLATFORM_FQ_CODEL_CE_THRESHOLD_DISABLED).
|
|
|
|
|
* Beware: zero is not the default you must always explicitly set this value. */
|
|
|
|
|
guint32 ce_threshold;
|
|
|
|
|
|
|
|
|
|
/* TCA_FQ_CODEL_MEMORY_LIMIT: note that only values <= 2^31 are accepted by kernel
|
|
|
|
|
* and kernel defaults to 32MB.
|
|
|
|
|
* Note that we use the special value NM_PLATFORM_FQ_CODEL_MEMORY_LIMIT_UNSET
|
|
|
|
|
* to indicate that no explicit limit is set (when we send a RTM_NEWQDISC request).
|
|
|
|
|
* This will cause kernel to choose the default (32MB).
|
|
|
|
|
* Beware: zero is not the default you must always explicitly set this value. */
|
|
|
|
|
guint32 memory_limit;
|
|
|
|
|
|
2019-04-09 13:42:52 +02:00
|
|
|
bool ecn : 1;
|
|
|
|
|
} NMPlatformQdiscFqCodel;
|
|
|
|
|
|
2020-04-30 09:19:55 +02:00
|
|
|
typedef struct {
|
|
|
|
|
unsigned quantum;
|
|
|
|
|
int perturb_period;
|
|
|
|
|
guint32 limit;
|
|
|
|
|
unsigned divisor;
|
|
|
|
|
unsigned flows;
|
|
|
|
|
unsigned depth;
|
|
|
|
|
} NMPlatformQdiscSfq;
|
|
|
|
|
|
2020-05-08 19:11:44 +02:00
|
|
|
typedef struct {
|
|
|
|
|
guint64 rate;
|
|
|
|
|
guint32 burst;
|
|
|
|
|
guint32 limit;
|
|
|
|
|
guint32 latency;
|
|
|
|
|
} NMPlatformQdiscTbf;
|
|
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
typedef struct {
|
2019-03-04 13:01:21 +01:00
|
|
|
__NMPlatformObjWithIfindex_COMMON;
|
2019-05-01 16:35:29 +02:00
|
|
|
|
|
|
|
|
/* beware, kind is embedded in an NMPObject, hence you must
|
|
|
|
|
* take care of the lifetime of the string. */
|
2017-11-15 20:36:35 +01:00
|
|
|
const char *kind;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
int addr_family;
|
|
|
|
|
guint32 handle;
|
|
|
|
|
guint32 parent;
|
|
|
|
|
guint32 info;
|
2019-04-09 13:42:52 +02:00
|
|
|
union {
|
|
|
|
|
NMPlatformQdiscFqCodel fq_codel;
|
2020-04-30 09:19:55 +02:00
|
|
|
NMPlatformQdiscSfq sfq;
|
2020-05-08 19:11:44 +02:00
|
|
|
NMPlatformQdiscTbf tbf;
|
2019-04-09 13:42:52 +02:00
|
|
|
};
|
2022-12-14 17:01:48 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformQdisc;
|
2014-04-03 11:02:48 +02:00
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
typedef struct {
|
|
|
|
|
char sdata[32];
|
|
|
|
|
} NMPlatformActionSimple;
|
|
|
|
|
|
2019-04-09 16:23:39 +02:00
|
|
|
typedef struct {
|
|
|
|
|
int ifindex;
|
2019-05-01 12:58:37 +02:00
|
|
|
bool egress : 1;
|
|
|
|
|
bool ingress : 1;
|
|
|
|
|
bool mirror : 1;
|
|
|
|
|
bool redirect : 1;
|
2019-04-09 16:23:39 +02:00
|
|
|
} NMPlatformActionMirred;
|
|
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
typedef struct {
|
2019-05-01 16:35:29 +02:00
|
|
|
/* beware, kind is embedded in an NMPObject, hence you must
|
|
|
|
|
* take care of the lifetime of the string. */
|
2017-11-15 20:36:35 +01:00
|
|
|
const char *kind;
|
2019-05-01 16:35:29 +02:00
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
union {
|
|
|
|
|
NMPlatformActionSimple simple;
|
2019-04-09 16:23:39 +02:00
|
|
|
NMPlatformActionMirred mirred;
|
2017-11-15 20:36:35 +01:00
|
|
|
};
|
|
|
|
|
} NMPlatformAction;
|
|
|
|
|
|
2017-12-10 12:52:41 +01:00
|
|
|
#define NM_PLATFORM_ACTION_KIND_SIMPLE "simple"
|
2019-04-09 16:23:39 +02:00
|
|
|
#define NM_PLATFORM_ACTION_KIND_MIRRED "mirred"
|
2017-12-10 12:52:41 +01:00
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
typedef struct {
|
2019-03-04 13:01:21 +01:00
|
|
|
__NMPlatformObjWithIfindex_COMMON;
|
2019-05-01 16:35:29 +02:00
|
|
|
|
|
|
|
|
/* beware, kind is embedded in an NMPObject, hence you must
|
|
|
|
|
* take care of the lifetime of the string. */
|
2017-11-15 20:36:35 +01:00
|
|
|
const char *kind;
|
2019-05-01 16:35:29 +02:00
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
int addr_family;
|
|
|
|
|
guint32 handle;
|
|
|
|
|
guint32 parent;
|
|
|
|
|
guint32 info;
|
|
|
|
|
NMPlatformAction action;
|
2022-12-14 17:01:48 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformTfilter;
|
2017-11-15 20:36:35 +01:00
|
|
|
|
2015-03-25 11:28:19 +01:00
|
|
|
typedef struct {
|
2022-03-29 18:21:49 +02:00
|
|
|
bool is_ip4;
|
|
|
|
|
gint8 addr_family;
|
|
|
|
|
guint8 sizeof_route;
|
2017-06-29 15:19:35 +02:00
|
|
|
NMPObjectType obj_type;
|
2017-07-26 10:50:23 +02:00
|
|
|
int (*route_cmp)(const NMPlatformIPXRoute *a,
|
|
|
|
|
const NMPlatformIPXRoute *b,
|
|
|
|
|
NMPlatformIPRouteCmpType cmp_type);
|
2015-10-12 10:27:33 +02:00
|
|
|
const char *(*route_to_string)(const NMPlatformIPXRoute *route, char *buf, gsize len);
|
2015-03-25 11:28:19 +01:00
|
|
|
} NMPlatformVTableRoute;
|
|
|
|
|
|
2019-03-04 12:51:07 +01:00
|
|
|
typedef union {
|
|
|
|
|
struct {
|
|
|
|
|
NMPlatformVTableRoute v6;
|
|
|
|
|
NMPlatformVTableRoute v4;
|
|
|
|
|
};
|
|
|
|
|
NMPlatformVTableRoute vx[2];
|
|
|
|
|
} _NMPlatformVTableRouteUnion;
|
|
|
|
|
|
|
|
|
|
extern const _NMPlatformVTableRouteUnion nm_platform_vtable_route;
|
2015-03-25 11:28:19 +01:00
|
|
|
|
2018-05-23 14:33:24 +02:00
|
|
|
typedef struct {
|
|
|
|
|
guint16 id;
|
|
|
|
|
guint32 qos;
|
|
|
|
|
bool proto_ad : 1;
|
|
|
|
|
} NMPlatformVFVlan;
|
|
|
|
|
|
2022-09-15 14:03:51 +02:00
|
|
|
typedef struct {
|
|
|
|
|
int ifindex;
|
|
|
|
|
in_addr_t gateway;
|
platform: fix handling "weight" for IPv4 routes
The hash/cmp functions were wrong with respect to IPv4 routes. Fix that.
- the weight was cast to a guint8, which is too small to hold all
values.
- NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID comparison would normalize a zero
weight to one
NM_CMP_DIRECT(NM_MAX(a->weight, 1u), NM_MAX(b->weight, 1u));
That was very wrong.
- the handling of the weight depends on the n_nexthops parameter.
See _ip4_route_weight_normalize().
The remarkable thing is that upper layers find it useful to track IPv4
single-hop routes with a non-zero weight. Consequently, this is honored
by NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID to treat single-hop routes
different, when their weight differs. However, adding such a route in
kernel will not work. To kernel, single-hop routes have no weight. While
the route exists as distinct in our hash tables, according to the
implemented identity, it never exists in kernel (or NMPlatform cache).
Well, you can call nm_platform_ip_route_add() with such a route, but the
result will have a weight of zero (making it a different route). See also
nm_platform_ip_route_normalize().
This works all mostly fine. The only thing to take care is that you
cannot look into the NMPlatform cache and ever find a IPv4 single-hop
route with a non-zero weight. If you preform such a lookup, realize that
such routes don't exist in platform. You can however normalize the
weight to zero first (nm_platform_ip_route_normalize()) and look for a
similar route with a zero weight.
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2023-11-28 12:37:01 +01:00
|
|
|
|
|
|
|
|
/* The weight of the next hop. The valid range for weight is 1-256.
|
libnm,platform: fix range for "weight" property of next hops for routes
In kernel, the valid range for the weight is 1-256 (on netlink this is
expressed as u8 in rtnh_hops, ranging 0-255).
We need an additional value, to represent
- unset weight, for non-ECMP routes in kernel.
- in libnm API, to express routes that should not be merged as ECMP
routes (the default).
Extend the type in NMPlatformIP4Route.weight to u16, and fix the code
for the special handling of the numeric range.
Also the libnm API needs to change. Modify the type of the attribute on
D-Bus from "b" to "u", to use a 32 bit integer. We use 32 bit, because
we already have common code to handle 32 bit unsigned integers, despite
only requiring 257 values. It seems better to stick to a few data types
(u32) instead of introducing more, only because the range is limited.
Co-Authored-By: Fernando Fernandez Mancera <ffmancera@riseup.net>
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2022-12-24 21:50:38 +01:00
|
|
|
*
|
platform: fix handling "weight" for IPv4 routes
The hash/cmp functions were wrong with respect to IPv4 routes. Fix that.
- the weight was cast to a guint8, which is too small to hold all
values.
- NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID comparison would normalize a zero
weight to one
NM_CMP_DIRECT(NM_MAX(a->weight, 1u), NM_MAX(b->weight, 1u));
That was very wrong.
- the handling of the weight depends on the n_nexthops parameter.
See _ip4_route_weight_normalize().
The remarkable thing is that upper layers find it useful to track IPv4
single-hop routes with a non-zero weight. Consequently, this is honored
by NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID to treat single-hop routes
different, when their weight differs. However, adding such a route in
kernel will not work. To kernel, single-hop routes have no weight. While
the route exists as distinct in our hash tables, according to the
implemented identity, it never exists in kernel (or NMPlatform cache).
Well, you can call nm_platform_ip_route_add() with such a route, but the
result will have a weight of zero (making it a different route). See also
nm_platform_ip_route_normalize().
This works all mostly fine. The only thing to take care is that you
cannot look into the NMPlatform cache and ever find a IPv4 single-hop
route with a non-zero weight. If you preform such a lookup, realize that
such routes don't exist in platform. You can however normalize the
weight to zero first (nm_platform_ip_route_normalize()) and look for a
similar route with a zero weight.
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2023-11-28 12:37:01 +01:00
|
|
|
* Zero is allowed too, but treated as 1 (by
|
|
|
|
|
* NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID comparison).
|
libnm,platform: fix range for "weight" property of next hops for routes
In kernel, the valid range for the weight is 1-256 (on netlink this is
expressed as u8 in rtnh_hops, ranging 0-255).
We need an additional value, to represent
- unset weight, for non-ECMP routes in kernel.
- in libnm API, to express routes that should not be merged as ECMP
routes (the default).
Extend the type in NMPlatformIP4Route.weight to u16, and fix the code
for the special handling of the numeric range.
Also the libnm API needs to change. Modify the type of the attribute on
D-Bus from "b" to "u", to use a 32 bit integer. We use 32 bit, because
we already have common code to handle 32 bit unsigned integers, despite
only requiring 257 values. It seems better to stick to a few data types
(u32) instead of introducing more, only because the range is limited.
Co-Authored-By: Fernando Fernandez Mancera <ffmancera@riseup.net>
Fixes: 1bbdecf5e125 ('platform: manage ECMP routes')
2022-12-24 21:50:38 +01:00
|
|
|
*/
|
|
|
|
|
guint16 weight;
|
2023-02-01 08:58:15 +01:00
|
|
|
|
2026-02-24 11:51:50 +01:00
|
|
|
/* Each next hop in kernel has its own rtnh_flags (for example to
|
|
|
|
|
* set RTNH_F_ONLINK). The flags are part of the identifier of a
|
|
|
|
|
* route. */
|
|
|
|
|
unsigned rtnh_flags;
|
2022-09-15 14:03:51 +02:00
|
|
|
} NMPlatformIP4RtNextHop;
|
|
|
|
|
|
2018-05-23 14:33:24 +02:00
|
|
|
typedef struct {
|
2022-04-28 16:33:11 +02:00
|
|
|
guint num_vlans;
|
2018-05-23 14:33:24 +02:00
|
|
|
guint32 index;
|
|
|
|
|
guint32 min_tx_rate;
|
|
|
|
|
guint32 max_tx_rate;
|
|
|
|
|
NMPlatformVFVlan *vlans;
|
|
|
|
|
struct {
|
2021-03-03 20:57:01 +01:00
|
|
|
guint8 data[20]; /* _NM_UTILS_HWADDR_LEN_MAX */
|
2018-05-23 14:33:24 +02:00
|
|
|
guint8 len;
|
|
|
|
|
} mac;
|
|
|
|
|
gint8 spoofchk;
|
|
|
|
|
gint8 trust;
|
|
|
|
|
} NMPlatformVF;
|
|
|
|
|
|
2023-01-22 21:37:46 +07:00
|
|
|
typedef struct {
|
|
|
|
|
guint16 vlan_default_pvid_val;
|
|
|
|
|
bool vlan_filtering_val : 1;
|
|
|
|
|
bool vlan_default_pvid_has : 1;
|
|
|
|
|
bool vlan_filtering_has : 1;
|
|
|
|
|
} NMPlatformLinkSetBridgeInfoData;
|
|
|
|
|
|
2020-08-05 13:46:28 -04:00
|
|
|
typedef struct {
|
2020-08-06 16:52:16 -04:00
|
|
|
guint64 mcast_last_member_interval;
|
|
|
|
|
guint64 mcast_membership_interval;
|
|
|
|
|
guint64 mcast_querier_interval;
|
|
|
|
|
guint64 mcast_query_interval;
|
|
|
|
|
guint64 mcast_query_response_interval;
|
|
|
|
|
guint64 mcast_startup_query_interval;
|
2022-04-28 16:33:11 +02:00
|
|
|
guint32 ageing_time;
|
|
|
|
|
guint32 forward_delay;
|
|
|
|
|
guint32 hello_time;
|
|
|
|
|
guint32 max_age;
|
|
|
|
|
guint32 mcast_hash_max;
|
|
|
|
|
guint32 mcast_last_member_count;
|
|
|
|
|
guint32 mcast_startup_query_count;
|
|
|
|
|
guint16 group_fwd_mask;
|
|
|
|
|
guint16 priority;
|
|
|
|
|
guint16 vlan_protocol;
|
|
|
|
|
NMEtherAddr group_addr;
|
2020-08-20 09:40:17 -04:00
|
|
|
guint8 mcast_router;
|
2022-04-28 16:33:11 +02:00
|
|
|
bool mcast_querier : 1;
|
|
|
|
|
bool mcast_query_use_ifaddr : 1;
|
|
|
|
|
bool mcast_snooping : 1;
|
|
|
|
|
bool stp_state : 1;
|
|
|
|
|
bool vlan_stats_enabled : 1;
|
2024-02-08 23:36:34 +08:00
|
|
|
bool vlan_filtering;
|
|
|
|
|
guint16 default_pvid;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkBridge;
|
2020-08-05 13:46:28 -04:00
|
|
|
|
|
|
|
|
extern const NMPlatformLnkBridge nm_platform_lnk_bridge_default;
|
|
|
|
|
|
2022-07-25 16:01:35 +02:00
|
|
|
/* Defined in net/bonding.h. */
|
|
|
|
|
#define NM_BOND_MAX_ARP_TARGETS 16
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
2023-03-02 15:07:07 +01:00
|
|
|
struct in6_addr ns_ip6_target[NM_BOND_MAX_ARP_TARGETS];
|
|
|
|
|
int primary;
|
|
|
|
|
in_addr_t arp_ip_target[NM_BOND_MAX_ARP_TARGETS];
|
|
|
|
|
guint32 arp_all_targets;
|
|
|
|
|
guint32 arp_interval;
|
|
|
|
|
guint32 arp_validate;
|
|
|
|
|
guint32 downdelay;
|
|
|
|
|
guint32 lp_interval;
|
|
|
|
|
guint32 miimon;
|
|
|
|
|
guint32 min_links;
|
|
|
|
|
guint32 packets_per_port;
|
|
|
|
|
guint32 peer_notif_delay;
|
|
|
|
|
guint32 resend_igmp;
|
|
|
|
|
guint32 updelay;
|
|
|
|
|
guint16 ad_actor_sys_prio;
|
|
|
|
|
guint16 ad_user_port_key;
|
|
|
|
|
NMEtherAddr ad_actor_system;
|
|
|
|
|
guint8 ad_select;
|
|
|
|
|
guint8 all_ports_active;
|
|
|
|
|
guint8 arp_missed_max;
|
|
|
|
|
guint8 arp_ip_targets_num;
|
|
|
|
|
guint8 fail_over_mac;
|
|
|
|
|
guint8 lacp_active;
|
|
|
|
|
guint8 lacp_rate;
|
|
|
|
|
guint8 ns_ip6_targets_num;
|
|
|
|
|
guint8 num_grat_arp;
|
|
|
|
|
guint8 mode;
|
|
|
|
|
guint8 primary_reselect;
|
|
|
|
|
guint8 xmit_hash_policy;
|
|
|
|
|
bool downdelay_has : 1;
|
|
|
|
|
bool lacp_active_has : 1;
|
|
|
|
|
bool lp_interval_has : 1;
|
|
|
|
|
bool miimon_has : 1;
|
|
|
|
|
bool peer_notif_delay_has : 1;
|
|
|
|
|
bool resend_igmp_has : 1;
|
|
|
|
|
bool tlb_dynamic_lb : 1;
|
|
|
|
|
bool tlb_dynamic_lb_has : 1;
|
|
|
|
|
bool updelay_has : 1;
|
|
|
|
|
bool use_carrier : 1;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkBond;
|
2022-07-25 16:01:35 +02:00
|
|
|
|
2015-10-15 15:47:14 +02:00
|
|
|
typedef struct {
|
2022-04-28 16:33:11 +02:00
|
|
|
int parent_ifindex;
|
2016-02-29 15:57:37 +01:00
|
|
|
in_addr_t local;
|
|
|
|
|
in_addr_t remote;
|
2015-10-16 18:26:38 +02:00
|
|
|
guint32 input_key;
|
|
|
|
|
guint32 output_key;
|
2022-04-28 16:33:11 +02:00
|
|
|
guint16 input_flags;
|
|
|
|
|
guint16 output_flags;
|
2015-10-16 18:26:38 +02:00
|
|
|
guint8 ttl;
|
|
|
|
|
guint8 tos;
|
2016-02-29 15:57:37 +01:00
|
|
|
bool path_mtu_discovery : 1;
|
2018-06-26 10:45:35 +02:00
|
|
|
bool is_tap : 1;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkGre;
|
2015-10-12 13:44:44 +02:00
|
|
|
|
2023-10-27 14:01:13 +02:00
|
|
|
typedef struct {
|
|
|
|
|
int port1;
|
|
|
|
|
int port2;
|
2025-09-16 17:54:22 +02:00
|
|
|
int interlink;
|
2023-10-27 14:01:13 +02:00
|
|
|
NMEtherAddr supervision_address;
|
2025-09-09 01:20:19 +02:00
|
|
|
gint8 protocol_version;
|
2023-10-27 14:01:13 +02:00
|
|
|
guint8 multicast_spec;
|
|
|
|
|
bool prp : 1;
|
|
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkHsr;
|
|
|
|
|
|
2013-04-25 15:46:39 -04:00
|
|
|
typedef struct {
|
2015-10-16 18:26:38 +02:00
|
|
|
int p_key;
|
2013-04-25 15:46:39 -04:00
|
|
|
const char *mode;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkInfiniband;
|
2013-04-25 15:46:39 -04:00
|
|
|
|
2015-11-27 22:22:25 +01:00
|
|
|
typedef struct {
|
|
|
|
|
struct in6_addr local;
|
|
|
|
|
struct in6_addr remote;
|
2016-02-29 15:57:37 +01:00
|
|
|
int parent_ifindex;
|
2022-04-28 16:33:11 +02:00
|
|
|
guint flow_label;
|
|
|
|
|
guint32 flags;
|
2015-11-27 22:22:25 +01:00
|
|
|
guint8 ttl;
|
|
|
|
|
guint8 tclass;
|
|
|
|
|
guint8 encap_limit;
|
|
|
|
|
guint8 proto;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-06-26 12:06:43 +02:00
|
|
|
/* IP6GRE only */
|
|
|
|
|
guint32 input_key;
|
|
|
|
|
guint32 output_key;
|
|
|
|
|
guint16 input_flags;
|
|
|
|
|
guint16 output_flags;
|
|
|
|
|
bool is_tap : 1;
|
|
|
|
|
bool is_gre : 1;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkIp6Tnl;
|
2015-11-27 22:22:25 +01:00
|
|
|
|
2015-11-27 14:01:56 +01:00
|
|
|
typedef struct {
|
2022-04-28 16:33:11 +02:00
|
|
|
int parent_ifindex;
|
2015-11-27 14:01:56 +01:00
|
|
|
in_addr_t local;
|
|
|
|
|
in_addr_t remote;
|
|
|
|
|
guint8 ttl;
|
|
|
|
|
guint8 tos;
|
2016-02-29 15:57:37 +01:00
|
|
|
bool path_mtu_discovery : 1;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkIpIp;
|
2015-11-27 14:01:56 +01:00
|
|
|
|
2024-09-06 14:14:24 +02:00
|
|
|
typedef struct {
|
|
|
|
|
guint16 mode;
|
|
|
|
|
bool private_flag : 1;
|
|
|
|
|
bool vepa : 1;
|
|
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkIpvlan;
|
|
|
|
|
|
2016-06-30 18:20:09 +02:00
|
|
|
typedef struct {
|
2022-10-24 10:17:09 +02:00
|
|
|
int parent_ifindex;
|
|
|
|
|
in_addr_t local;
|
|
|
|
|
in_addr_t remote;
|
|
|
|
|
guint32 ikey;
|
|
|
|
|
guint32 okey;
|
|
|
|
|
guint32 fwmark;
|
|
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkVti;
|
|
|
|
|
|
2022-10-25 08:31:47 +02:00
|
|
|
typedef struct {
|
|
|
|
|
int parent_ifindex;
|
|
|
|
|
struct in6_addr local;
|
|
|
|
|
struct in6_addr remote;
|
|
|
|
|
guint32 ikey;
|
|
|
|
|
guint32 okey;
|
|
|
|
|
guint32 fwmark;
|
|
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkVti6;
|
|
|
|
|
|
2022-10-24 10:17:09 +02:00
|
|
|
typedef struct {
|
|
|
|
|
int parent_ifindex;
|
2017-06-27 19:08:05 +02:00
|
|
|
guint64 sci; /* host byte order */
|
2016-06-30 18:20:09 +02:00
|
|
|
guint64 cipher_suite;
|
|
|
|
|
guint32 window;
|
|
|
|
|
guint8 icv_length;
|
|
|
|
|
guint8 encoding_sa;
|
|
|
|
|
guint8 validation;
|
|
|
|
|
bool encrypt : 1;
|
|
|
|
|
bool protect : 1;
|
|
|
|
|
bool include_sci : 1;
|
|
|
|
|
bool es : 1;
|
|
|
|
|
bool scb : 1;
|
|
|
|
|
bool replay_protect : 1;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkMacsec;
|
2016-06-30 18:20:09 +02:00
|
|
|
|
2013-05-06 09:16:17 -04:00
|
|
|
typedef struct {
|
2015-12-03 15:44:33 +01:00
|
|
|
guint mode;
|
2016-02-29 15:57:37 +01:00
|
|
|
bool no_promisc : 1;
|
|
|
|
|
bool tap : 1;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkMacvlan;
|
2013-05-06 09:16:17 -04:00
|
|
|
|
2015-11-11 18:41:48 +01:00
|
|
|
typedef struct {
|
2022-04-28 16:33:11 +02:00
|
|
|
int parent_ifindex;
|
2015-11-11 18:41:48 +01:00
|
|
|
in_addr_t local;
|
|
|
|
|
in_addr_t remote;
|
2017-10-17 13:28:25 +02:00
|
|
|
guint16 flags;
|
2015-11-11 18:41:48 +01:00
|
|
|
guint8 ttl;
|
|
|
|
|
guint8 tos;
|
|
|
|
|
guint8 proto;
|
2016-02-29 15:57:37 +01:00
|
|
|
bool path_mtu_discovery : 1;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkSit;
|
2015-11-11 18:41:48 +01:00
|
|
|
|
core/platform: add support for TUN/TAP netlink support and various cleanup
Kernel recently got support for exposing TUN/TAP information on netlink
[1], [2], [3]. Add support for it to the platform cache.
The advantage of using netlink is that querying sysctl bypasses the
order of events of the netlink socket. It is out of sync and racy. For
example, platform cache might still think that a tun device exists, but
a subsequent lookup at sysfs might fail because the device was deleted
in the meantime. Another point is, that we don't get change
notifications via sysctl and that it requires various extra syscalls
to read the device information. If the tun information is present on
netlink, put it into the cache. This bypasses checking sysctl while
we keep looking at sysctl for backward compatibility until we require
support from kernel.
Notes:
- we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This
deviates from the model of how kernel treats TUN/TAP devices, which
makes it more complicated. The link type of a NMPlatformLink instance
should match what kernel thinks about the device. Point in case,
when parsing RTM_NETLINK messages, we very early need to determine
the link type (_linktype_get_type()). However, to determine the
type of a TUN/TAP at that point, we need to look into nested
netlink attributes which in turn depend on the type (IFLA_INFO_KIND
and IFLA_INFO_DATA), or even worse, we would need to look into
sysctl for older kernel vesions. Now, the TUN/TAP type is a property
of the link type NM_LINK_TYPE_TUN, instead of determining two
different link types.
- various parts of the API (both kernel's sysctl vs. netlink) and
NMDeviceTun vs. NMSettingTun disagree whether the PI is positive
(NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted
(NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way,
but prefer the positive form for internal API at NMPlatformLnkTun.pi.
- previously NMDeviceTun.mode could not change after initializing
the object. Allow for that to happen, because forcing some properties
that are reported by kernel to not change is wrong, in case they
might change. Of course, in practice kernel doesn't allow the device
to ever change its type, but the type property of the NMDeviceTun
should not make that assumption, because, if it actually changes, what
would it mean?
- note that as of now, new netlink API is not yet merged to mainline Linus
tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API
for now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457
[2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818
https://bugzilla.redhat.com/show_bug.cgi?id=1547213
https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
|
|
|
typedef struct {
|
|
|
|
|
guint32 owner;
|
|
|
|
|
guint32 group;
|
|
|
|
|
|
|
|
|
|
guint8 type;
|
|
|
|
|
|
|
|
|
|
bool owner_valid : 1;
|
|
|
|
|
bool group_valid : 1;
|
|
|
|
|
|
|
|
|
|
bool pi : 1;
|
|
|
|
|
bool vnet_hdr : 1;
|
|
|
|
|
bool multi_queue : 1;
|
|
|
|
|
bool persist : 1;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkTun;
|
core/platform: add support for TUN/TAP netlink support and various cleanup
Kernel recently got support for exposing TUN/TAP information on netlink
[1], [2], [3]. Add support for it to the platform cache.
The advantage of using netlink is that querying sysctl bypasses the
order of events of the netlink socket. It is out of sync and racy. For
example, platform cache might still think that a tun device exists, but
a subsequent lookup at sysfs might fail because the device was deleted
in the meantime. Another point is, that we don't get change
notifications via sysctl and that it requires various extra syscalls
to read the device information. If the tun information is present on
netlink, put it into the cache. This bypasses checking sysctl while
we keep looking at sysctl for backward compatibility until we require
support from kernel.
Notes:
- we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This
deviates from the model of how kernel treats TUN/TAP devices, which
makes it more complicated. The link type of a NMPlatformLink instance
should match what kernel thinks about the device. Point in case,
when parsing RTM_NETLINK messages, we very early need to determine
the link type (_linktype_get_type()). However, to determine the
type of a TUN/TAP at that point, we need to look into nested
netlink attributes which in turn depend on the type (IFLA_INFO_KIND
and IFLA_INFO_DATA), or even worse, we would need to look into
sysctl for older kernel vesions. Now, the TUN/TAP type is a property
of the link type NM_LINK_TYPE_TUN, instead of determining two
different link types.
- various parts of the API (both kernel's sysctl vs. netlink) and
NMDeviceTun vs. NMSettingTun disagree whether the PI is positive
(NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted
(NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way,
but prefer the positive form for internal API at NMPlatformLnkTun.pi.
- previously NMDeviceTun.mode could not change after initializing
the object. Allow for that to happen, because forcing some properties
that are reported by kernel to not change is wrong, in case they
might change. Of course, in practice kernel doesn't allow the device
to ever change its type, but the type property of the NMDeviceTun
should not make that assumption, because, if it actually changes, what
would it mean?
- note that as of now, new netlink API is not yet merged to mainline Linus
tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API
for now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457
[2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818
https://bugzilla.redhat.com/show_bug.cgi?id=1547213
https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
|
|
|
|
2015-10-16 18:26:38 +02:00
|
|
|
typedef struct {
|
2021-03-03 20:57:01 +01:00
|
|
|
guint16 id;
|
2022-12-02 10:47:14 +01:00
|
|
|
guint16 protocol;
|
2021-03-03 20:57:01 +01:00
|
|
|
_NMVlanFlags flags;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkVlan;
|
2015-10-16 18:26:38 +02:00
|
|
|
|
2019-12-05 10:35:25 +01:00
|
|
|
typedef struct {
|
|
|
|
|
guint32 table;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkVrf;
|
2019-12-05 10:35:25 +01:00
|
|
|
|
2013-06-04 10:31:22 -03:00
|
|
|
typedef struct {
|
|
|
|
|
struct in6_addr group6;
|
|
|
|
|
struct in6_addr local6;
|
2022-04-28 16:33:11 +02:00
|
|
|
int parent_ifindex;
|
2016-02-29 15:57:37 +01:00
|
|
|
in_addr_t group;
|
|
|
|
|
in_addr_t local;
|
|
|
|
|
guint32 id;
|
2013-06-04 10:31:22 -03:00
|
|
|
guint32 ageing;
|
|
|
|
|
guint32 limit;
|
|
|
|
|
guint16 dst_port;
|
|
|
|
|
guint16 src_port_min;
|
|
|
|
|
guint16 src_port_max;
|
2016-02-29 15:57:37 +01:00
|
|
|
guint8 tos;
|
|
|
|
|
guint8 ttl;
|
|
|
|
|
bool learning : 1;
|
|
|
|
|
bool proxy : 1;
|
|
|
|
|
bool rsc : 1;
|
|
|
|
|
bool l2miss : 1;
|
|
|
|
|
bool l3miss : 1;
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkVxlan;
|
2013-06-04 10:31:22 -03:00
|
|
|
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
#define NMP_WIREGUARD_PUBLIC_KEY_LEN 32
|
|
|
|
|
#define NMP_WIREGUARD_SYMMETRIC_KEY_LEN 32
|
|
|
|
|
|
2018-03-13 13:35:35 +00:00
|
|
|
typedef struct {
|
|
|
|
|
guint32 fwmark;
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
guint16 listen_port;
|
|
|
|
|
guint8 private_key[NMP_WIREGUARD_PUBLIC_KEY_LEN];
|
|
|
|
|
guint8 public_key[NMP_WIREGUARD_PUBLIC_KEY_LEN];
|
2022-12-01 18:18:10 +01:00
|
|
|
} _nm_alignas(NMPlatformObject) NMPlatformLnkWireGuard;
|
2018-03-13 13:35:35 +00:00
|
|
|
|
2024-02-14 11:30:03 +01:00
|
|
|
typedef struct {
|
|
|
|
|
guint num_vfs;
|
|
|
|
|
NMOptionBool autoprobe;
|
|
|
|
|
_NMSriovEswitchMode eswitch_mode;
|
|
|
|
|
_NMSriovEswitchInlineMode eswitch_inline_mode;
|
|
|
|
|
_NMSriovEswitchEncapMode eswitch_encap_mode;
|
|
|
|
|
} NMPlatformSriovParams;
|
|
|
|
|
|
2019-02-10 15:22:26 +01:00
|
|
|
typedef enum {
|
2019-02-11 11:07:06 +01:00
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_FLAG_NONE = 0,
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_FLAG_REPLACE_PEERS = (1LL << 0),
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_FLAG_HAS_PRIVATE_KEY = (1LL << 1),
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_FLAG_HAS_LISTEN_PORT = (1LL << 2),
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_FLAG_HAS_FWMARK = (1LL << 3),
|
2019-02-10 15:22:26 +01:00
|
|
|
} NMPlatformWireGuardChangeFlags;
|
|
|
|
|
|
2019-02-11 11:07:06 +01:00
|
|
|
typedef enum {
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_NONE = 0,
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_REMOVE_ME = (1LL << 0),
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_PRESHARED_KEY = (1LL << 1),
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_KEEPALIVE_INTERVAL = (1LL << 2),
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_ENDPOINT = (1LL << 3),
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_ALLOWEDIPS = (1LL << 4),
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_REPLACE_ALLOWEDIPS = (1LL << 5),
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-02-11 11:07:06 +01:00
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_DEFAULT =
|
|
|
|
|
NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_PRESHARED_KEY
|
|
|
|
|
| NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_KEEPALIVE_INTERVAL
|
|
|
|
|
| NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_ENDPOINT
|
|
|
|
|
| NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_ALLOWEDIPS,
|
|
|
|
|
|
|
|
|
|
} NMPlatformWireGuardChangePeerFlags;
|
|
|
|
|
|
2019-03-05 10:20:25 +01:00
|
|
|
typedef void (*NMPlatformAsyncCallback)(GError *error, gpointer user_data);
|
|
|
|
|
|
2022-07-13 16:24:05 +02:00
|
|
|
typedef struct {
|
|
|
|
|
__NMPlatformObjWithIfindex_COMMON;
|
|
|
|
|
guint32 id;
|
|
|
|
|
guint32 flags;
|
|
|
|
|
guint16 port;
|
|
|
|
|
NMIPAddr addr;
|
|
|
|
|
gint8 addr_family;
|
|
|
|
|
} NMPlatformMptcpAddr;
|
|
|
|
|
|
|
|
|
|
#undef __NMPlatformObjWithIfindex_COMMON
|
|
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2013-03-27 22:23:24 +01:00
|
|
|
|
2019-04-17 07:57:29 +02:00
|
|
|
typedef enum {
|
2019-04-17 11:43:00 +02:00
|
|
|
NM_PLATFORM_KERNEL_SUPPORT_TYPE_FRA_L3MDEV,
|
2019-04-17 10:43:42 +02:00
|
|
|
NM_PLATFORM_KERNEL_SUPPORT_TYPE_FRA_UID_RANGE,
|
2019-04-17 09:07:00 +02:00
|
|
|
NM_PLATFORM_KERNEL_SUPPORT_TYPE_FRA_PROTOCOL,
|
2020-08-21 13:35:36 +02:00
|
|
|
NM_PLATFORM_KERNEL_SUPPORT_TYPE_IFLA_BR_VLAN_STATS_ENABLED,
|
2021-08-18 20:58:52 -04:00
|
|
|
NM_PLATFORM_KERNEL_SUPPORT_TYPE_IFLA_PERM_ADDRESS,
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-04-17 10:23:03 +02:00
|
|
|
/* this also includes FRA_SPORT_RANGE and FRA_DPORT_RANGE which
|
|
|
|
|
* were added at the same time. */
|
|
|
|
|
NM_PLATFORM_KERNEL_SUPPORT_TYPE_FRA_IP_PROTO,
|
|
|
|
|
|
2024-07-04 12:45:42 +02:00
|
|
|
NM_PLATFORM_KERNEL_SUPPORT_TYPE_IFLA_BOND_PORT_PRIO,
|
2023-03-09 12:18:14 +01:00
|
|
|
|
2019-04-17 07:57:29 +02:00
|
|
|
_NM_PLATFORM_KERNEL_SUPPORT_NUM,
|
|
|
|
|
} NMPlatformKernelSupportType;
|
|
|
|
|
|
|
|
|
|
extern volatile int _nm_platform_kernel_support_state[_NM_PLATFORM_KERNEL_SUPPORT_NUM];
|
|
|
|
|
|
|
|
|
|
int _nm_platform_kernel_support_init(NMPlatformKernelSupportType type, int value);
|
|
|
|
|
|
2019-05-28 14:56:50 +02:00
|
|
|
static inline gboolean
|
|
|
|
|
_nm_platform_kernel_support_detected(NMPlatformKernelSupportType type)
|
|
|
|
|
{
|
|
|
|
|
nm_assert(_NM_INT_NOT_NEGATIVE(type) && type < G_N_ELEMENTS(_nm_platform_kernel_support_state));
|
|
|
|
|
|
2020-08-21 13:33:35 +02:00
|
|
|
return G_LIKELY(g_atomic_int_get(&_nm_platform_kernel_support_state[type]) != 0);
|
2019-05-28 14:56:50 +02:00
|
|
|
}
|
|
|
|
|
|
2021-01-10 16:51:37 +01:00
|
|
|
static inline NMOptionBool
|
2020-08-21 13:33:35 +02:00
|
|
|
nm_platform_kernel_support_get_full(NMPlatformKernelSupportType type, gboolean init_if_not_set)
|
2019-05-28 14:56:50 +02:00
|
|
|
{
|
|
|
|
|
int v;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-05-28 14:56:50 +02:00
|
|
|
nm_assert(_NM_INT_NOT_NEGATIVE(type) && type < G_N_ELEMENTS(_nm_platform_kernel_support_state));
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-08-21 13:33:35 +02:00
|
|
|
v = g_atomic_int_get(&_nm_platform_kernel_support_state[type]);
|
|
|
|
|
if (G_UNLIKELY(v == 0)) {
|
|
|
|
|
if (!init_if_not_set)
|
2021-01-10 16:51:37 +01:00
|
|
|
return NM_OPTION_BOOL_DEFAULT;
|
2019-05-28 14:56:50 +02:00
|
|
|
v = _nm_platform_kernel_support_init(type, 0);
|
2020-08-21 13:33:35 +02:00
|
|
|
}
|
2019-05-28 14:56:50 +02:00
|
|
|
return (v >= 0);
|
|
|
|
|
}
|
2019-04-17 07:57:29 +02:00
|
|
|
|
2020-08-21 13:33:35 +02:00
|
|
|
static inline gboolean
|
|
|
|
|
nm_platform_kernel_support_get(NMPlatformKernelSupportType type)
|
|
|
|
|
{
|
2021-01-10 16:51:37 +01:00
|
|
|
return nm_platform_kernel_support_get_full(type, TRUE) != NM_OPTION_BOOL_FALSE;
|
2020-08-21 13:33:35 +02:00
|
|
|
}
|
|
|
|
|
|
2022-07-07 12:55:50 +02:00
|
|
|
typedef enum {
|
2024-01-15 12:08:07 +01:00
|
|
|
NMP_GENL_FAMILY_TYPE_DEVLINK,
|
2022-07-07 12:55:50 +02:00
|
|
|
NMP_GENL_FAMILY_TYPE_ETHTOOL,
|
|
|
|
|
NMP_GENL_FAMILY_TYPE_MPTCP_PM,
|
|
|
|
|
NMP_GENL_FAMILY_TYPE_NL80211,
|
|
|
|
|
NMP_GENL_FAMILY_TYPE_NL802154,
|
|
|
|
|
NMP_GENL_FAMILY_TYPE_WIREGUARD,
|
|
|
|
|
|
|
|
|
|
_NMP_GENL_FAMILY_TYPE_NUM,
|
|
|
|
|
_NMP_GENL_FAMILY_TYPE_NONE = _NMP_GENL_FAMILY_TYPE_NUM,
|
|
|
|
|
} NMPGenlFamilyType;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
const char *name;
|
|
|
|
|
} NMPGenlFamilyInfo;
|
|
|
|
|
|
|
|
|
|
extern const NMPGenlFamilyInfo nmp_genl_family_infos[_NMP_GENL_FAMILY_TYPE_NUM];
|
|
|
|
|
|
|
|
|
|
NMPGenlFamilyType nmp_genl_family_type_from_name(const char *name);
|
|
|
|
|
|
2019-04-17 07:57:29 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2016-09-28 15:58:24 +02:00
|
|
|
struct _NMPlatformPrivate;
|
|
|
|
|
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
struct _NMPlatform {
|
2013-03-27 22:23:24 +01:00
|
|
|
GObject parent;
|
2021-11-09 13:28:54 +01:00
|
|
|
NMPNetns *_netns;
|
2016-09-28 15:58:24 +02:00
|
|
|
struct _NMPlatformPrivate *_priv;
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
};
|
2013-03-27 22:23:24 +01:00
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
GObjectClass parent;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean (*sysctl_set)(NMPlatform *self,
|
|
|
|
|
const char *pathid,
|
|
|
|
|
int dirfd,
|
|
|
|
|
const char *path,
|
|
|
|
|
const char *value);
|
2021-11-09 13:28:54 +01:00
|
|
|
void (*sysctl_set_async)(NMPlatform *self,
|
|
|
|
|
const char *pathid,
|
2019-03-05 10:20:25 +01:00
|
|
|
int dirfd,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *path,
|
|
|
|
|
const char *const *values,
|
2019-03-05 10:20:25 +01:00
|
|
|
NMPlatformAsyncCallback callback,
|
|
|
|
|
gpointer data,
|
2021-11-09 13:28:54 +01:00
|
|
|
GCancellable *cancellable);
|
2019-01-02 11:28:53 +01:00
|
|
|
char *(*sysctl_get)(NMPlatform *self, const char *pathid, int dirfd, const char *path);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
void (*refresh_all)(NMPlatform *self, NMPObjectType obj_type);
|
|
|
|
|
void (*process_events)(NMPlatform *self);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int (*link_add)(NMPlatform *self,
|
2018-11-05 12:35:40 +01:00
|
|
|
NMLinkType type,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *name,
|
2019-12-31 11:47:33 +01:00
|
|
|
int parent,
|
2021-11-09 13:28:54 +01:00
|
|
|
const void *address,
|
2018-11-05 12:35:40 +01:00
|
|
|
size_t address_len,
|
2020-10-23 09:41:01 +02:00
|
|
|
guint32 mtu,
|
2019-12-31 02:38:06 +01:00
|
|
|
gconstpointer extra_data,
|
2018-11-05 12:35:40 +01:00
|
|
|
const NMPlatformLink **out_link);
|
2023-02-27 10:55:29 +01:00
|
|
|
int (*link_change_extra)(NMPlatform *self,
|
|
|
|
|
NMLinkType type,
|
|
|
|
|
int ifindex,
|
|
|
|
|
gconstpointer extra_data);
|
2023-03-03 16:36:23 +01:00
|
|
|
gboolean (*link_change)(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
NMPlatformLinkProps *props,
|
|
|
|
|
NMPortKind port_kind,
|
|
|
|
|
const NMPlatformLinkPortData *port_data,
|
|
|
|
|
NMPlatformLinkChangeFlags flags);
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean (*link_delete)(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean (*link_refresh)(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean (*link_set_netns)(NMPlatform *self, int ifindex, int netns_fd);
|
2021-04-15 09:50:48 +02:00
|
|
|
int (*link_change_flags)(NMPlatform *platform,
|
|
|
|
|
int ifindex,
|
|
|
|
|
unsigned flags_mask,
|
|
|
|
|
unsigned flags_set);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-08-23 22:31:51 +02:00
|
|
|
int (*link_set_inet6_addr_gen_mode)(NMPlatform *self, int ifindex, guint8 enabled);
|
2021-08-25 14:53:40 +02:00
|
|
|
gboolean (*link_set_token)(NMPlatform *self, int ifindex, const NMUtilsIPv6IfaceId *iid);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*link_get_permanent_address_ethtool)(NMPlatform *self,
|
2021-08-14 14:53:58 -04:00
|
|
|
int ifindex,
|
|
|
|
|
NMPLinkAddress *out_address);
|
2019-01-02 11:28:53 +01:00
|
|
|
int (*link_set_address)(NMPlatform *self, int ifindex, gconstpointer address, size_t length);
|
|
|
|
|
int (*link_set_mtu)(NMPlatform *self, int ifindex, guint32 mtu);
|
|
|
|
|
gboolean (*link_set_name)(NMPlatform *self, int ifindex, const char *name);
|
2021-11-09 13:28:54 +01:00
|
|
|
void (*link_set_sriov_params_async)(NMPlatform *self,
|
2019-03-05 14:39:29 +01:00
|
|
|
int ifindex,
|
2024-02-14 11:30:03 +01:00
|
|
|
NMPlatformSriovParams sriov_params,
|
2019-03-05 14:39:29 +01:00
|
|
|
NMPlatformAsyncCallback callback,
|
|
|
|
|
gpointer callback_data,
|
2021-11-09 13:28:54 +01:00
|
|
|
GCancellable *cancellable);
|
2018-05-23 14:33:24 +02:00
|
|
|
gboolean (*link_set_sriov_vfs)(NMPlatform *self, int ifindex, const NMPlatformVF *const *vfs);
|
2024-07-25 09:49:18 +02:00
|
|
|
gboolean (*link_set_bridge_vlans)(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
gboolean on_controller,
|
|
|
|
|
const NMPlatformBridgeVlan *vlans,
|
|
|
|
|
guint num_vlans);
|
2024-07-11 09:03:05 +02:00
|
|
|
gboolean (*link_get_bridge_vlans)(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
NMPlatformBridgeVlan **out_vlans,
|
|
|
|
|
guint *out_num_vlans);
|
2023-01-22 21:37:46 +07:00
|
|
|
gboolean (*link_set_bridge_info)(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const NMPlatformLinkSetBridgeInfoData *bridge_info);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
char *(*link_get_physical_port_id)(NMPlatform *self, int ifindex);
|
|
|
|
|
guint (*link_get_dev_id)(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean (*link_get_wake_on_lan)(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean (*link_get_driver_info)(NMPlatform *self,
|
2014-10-03 13:41:49 -05:00
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
char **out_driver_name,
|
|
|
|
|
char **out_driver_version,
|
|
|
|
|
char **out_fw_version);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean (*link_supports_carrier_detect)(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean (*link_supports_vlans)(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean (*link_supports_sriov)(NMPlatform *self, int ifindex);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2024-07-04 12:45:42 +02:00
|
|
|
gboolean (*link_attach_port)(NMPlatform *self, int controller, int port);
|
|
|
|
|
gboolean (*link_release_port)(NMPlatform *self, int controller, int port);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean (*link_can_assume)(NMPlatform *self, int ifindex);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int (*link_wireguard_change)(NMPlatform *self,
|
2018-12-25 18:41:28 +01:00
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLnkWireGuard *lnk_wireguard,
|
|
|
|
|
const struct _NMPWireGuardPeer *peers,
|
2019-02-11 11:07:06 +01:00
|
|
|
const NMPlatformWireGuardChangePeerFlags *peer_flags,
|
2019-01-13 14:21:59 +01:00
|
|
|
guint peers_len,
|
2019-02-10 15:22:26 +01:00
|
|
|
NMPlatformWireGuardChangeFlags change_flags);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*link_vlan_change)(NMPlatform *self,
|
2015-10-27 16:14:54 +01:00
|
|
|
int ifindex,
|
2021-03-03 20:57:01 +01:00
|
|
|
_NMVlanFlags flags_mask,
|
|
|
|
|
_NMVlanFlags flags_set,
|
2015-10-27 16:14:54 +01:00
|
|
|
gboolean ingress_reset_all,
|
|
|
|
|
const NMVlanQosMapping *ingress_map,
|
|
|
|
|
gsize n_ingress_map,
|
|
|
|
|
gboolean egress_reset_all,
|
|
|
|
|
const NMVlanQosMapping *egress_map,
|
|
|
|
|
gsize n_egress_map);
|
2022-07-25 16:01:35 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*link_tun_add)(NMPlatform *self,
|
|
|
|
|
const char *name,
|
core/platform: add support for TUN/TAP netlink support and various cleanup
Kernel recently got support for exposing TUN/TAP information on netlink
[1], [2], [3]. Add support for it to the platform cache.
The advantage of using netlink is that querying sysctl bypasses the
order of events of the netlink socket. It is out of sync and racy. For
example, platform cache might still think that a tun device exists, but
a subsequent lookup at sysfs might fail because the device was deleted
in the meantime. Another point is, that we don't get change
notifications via sysctl and that it requires various extra syscalls
to read the device information. If the tun information is present on
netlink, put it into the cache. This bypasses checking sysctl while
we keep looking at sysctl for backward compatibility until we require
support from kernel.
Notes:
- we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This
deviates from the model of how kernel treats TUN/TAP devices, which
makes it more complicated. The link type of a NMPlatformLink instance
should match what kernel thinks about the device. Point in case,
when parsing RTM_NETLINK messages, we very early need to determine
the link type (_linktype_get_type()). However, to determine the
type of a TUN/TAP at that point, we need to look into nested
netlink attributes which in turn depend on the type (IFLA_INFO_KIND
and IFLA_INFO_DATA), or even worse, we would need to look into
sysctl for older kernel vesions. Now, the TUN/TAP type is a property
of the link type NM_LINK_TYPE_TUN, instead of determining two
different link types.
- various parts of the API (both kernel's sysctl vs. netlink) and
NMDeviceTun vs. NMSettingTun disagree whether the PI is positive
(NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted
(NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way,
but prefer the positive form for internal API at NMPlatformLnkTun.pi.
- previously NMDeviceTun.mode could not change after initializing
the object. Allow for that to happen, because forcing some properties
that are reported by kernel to not change is wrong, in case they
might change. Of course, in practice kernel doesn't allow the device
to ever change its type, but the type property of the NMDeviceTun
should not make that assumption, because, if it actually changes, what
would it mean?
- note that as of now, new netlink API is not yet merged to mainline Linus
tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API
for now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457
[2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818
https://bugzilla.redhat.com/show_bug.cgi?id=1547213
https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
|
|
|
const NMPlatformLnkTun *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link,
|
|
|
|
|
int *out_fd);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*infiniband_partition_add)(NMPlatform *self,
|
2019-01-02 11:28:53 +01:00
|
|
|
int parent,
|
|
|
|
|
int p_key,
|
|
|
|
|
const NMPlatformLink **out_link);
|
|
|
|
|
gboolean (*infiniband_partition_delete)(NMPlatform *self, int parent, int p_key);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*wifi_get_capabilities)(NMPlatform *self,
|
2021-03-03 17:32:50 +01:00
|
|
|
int ifindex,
|
|
|
|
|
_NMDeviceWifiCapabilities *caps);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*wifi_get_station)(NMPlatform *self,
|
2020-11-19 11:00:08 +01:00
|
|
|
int ifindex,
|
|
|
|
|
NMEtherAddr *out_bssid,
|
2021-11-09 13:28:54 +01:00
|
|
|
int *out_quality,
|
|
|
|
|
guint32 *out_rate);
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean (*wifi_get_bssid)(NMPlatform *self, int ifindex, guint8 *bssid);
|
|
|
|
|
guint32 (*wifi_get_frequency)(NMPlatform *self, int ifindex);
|
|
|
|
|
int (*wifi_get_quality)(NMPlatform *self, int ifindex);
|
|
|
|
|
guint32 (*wifi_get_rate)(NMPlatform *self, int ifindex);
|
2021-03-03 20:57:01 +01:00
|
|
|
_NM80211Mode (*wifi_get_mode)(NMPlatform *self, int ifindex);
|
|
|
|
|
void (*wifi_set_mode)(NMPlatform *self, int ifindex, _NM80211Mode mode);
|
2019-01-02 11:28:53 +01:00
|
|
|
void (*wifi_set_powersave)(NMPlatform *self, int ifindex, guint32 powersave);
|
2023-03-21 18:05:03 +01:00
|
|
|
guint32 (*wifi_find_frequency)(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const guint32 *freqs,
|
|
|
|
|
gboolean ap);
|
2019-01-02 11:28:53 +01:00
|
|
|
void (*wifi_indicate_addressing_running)(NMPlatform *self, int ifindex, gboolean running);
|
2021-03-03 08:51:38 +01:00
|
|
|
_NMSettingWirelessWakeOnWLan (*wifi_get_wake_on_wlan)(NMPlatform *self, int ifindex);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*wifi_set_wake_on_wlan)(NMPlatform *self,
|
2021-03-03 08:51:38 +01:00
|
|
|
int ifindex,
|
|
|
|
|
_NMSettingWirelessWakeOnWLan wowl);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
guint32 (*mesh_get_channel)(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean (*mesh_set_channel)(NMPlatform *self, int ifindex, guint32 channel);
|
|
|
|
|
gboolean (*mesh_set_ssid)(NMPlatform *self, int ifindex, const guint8 *ssid, gsize len);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
guint16 (*wpan_get_pan_id)(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean (*wpan_set_pan_id)(NMPlatform *self, int ifindex, guint16 pan_id);
|
|
|
|
|
guint16 (*wpan_get_short_addr)(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean (*wpan_set_short_addr)(NMPlatform *self, int ifindex, guint16 short_addr);
|
|
|
|
|
gboolean (*wpan_set_channel)(NMPlatform *self, int ifindex, guint8 page, guint8 channel);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean (*object_delete)(NMPlatform *self, const NMPObject *obj);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean (*ip4_address_add)(NMPlatform *self,
|
2015-10-10 19:58:59 +02:00
|
|
|
int ifindex,
|
|
|
|
|
in_addr_t address,
|
2016-04-06 18:04:26 +02:00
|
|
|
guint8 plen,
|
2015-10-10 19:58:59 +02:00
|
|
|
in_addr_t peer_address,
|
platform: track IFA_BROADCAST address in NMPlatformIP4Address
- track the broadcast address in NMPlatformIP4Address. For addresses
that we receive from kernel and that we cache in NMPlatform, this
allows us to show the additional information. For example, we
can see it in debug logging.
- when setting the address, we still mostly generate our default
broadcast address. This is done in the only relevant caller
nm_platform_ip4_address_sync(). Basically, we merely moved setting
the broadcast address to the caller.
That is, because no callers explicitly set the "use_ip4_broadcast_address"
flag (yet). However, in the future some caller might want to set an explicit
broadcast address.
In practice, we currently don't support configuring special broadcast
addresses in NetworkManager. Instead, we always add the default one with
"address|~netmask" (for plen < 31).
Note that a main point of IFA_BROADCAST is to add a broadcast route to
the local table. Also note that kernel anyway will add such a
"address|~netmask" route, that is regardless whether IFA_BROADCAST is
set or not. Hence, setting it or not makes very little difference for
normal broadcast addresses -- because kernel tends to add this route either
way. It would make a difference if NetworkManager configured an unusual
IFA_BROADCAST address or an address for prefixes >= 31 (in which cases
kernel wouldn't add them automatically). But we don't do that at the
moment.
So, while what NM does has little effect in practice, it still seems
more correct to add the broadcast address, only so that you see it in
`ip addr show`.
2020-01-10 08:11:37 +01:00
|
|
|
in_addr_t broadcast_address,
|
2015-10-10 19:58:59 +02:00
|
|
|
guint32 lifetime,
|
|
|
|
|
guint32 preferred_lft,
|
2016-02-29 17:06:21 +01:00
|
|
|
guint32 flags,
|
2023-02-17 12:07:05 +01:00
|
|
|
const char *label,
|
|
|
|
|
char **out_extack_msg);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*ip6_address_add)(NMPlatform *self,
|
2015-10-10 19:58:59 +02:00
|
|
|
int ifindex,
|
|
|
|
|
struct in6_addr address,
|
2016-04-06 18:04:26 +02:00
|
|
|
guint8 plen,
|
2015-10-10 19:58:59 +02:00
|
|
|
struct in6_addr peer_address,
|
|
|
|
|
guint32 lifetime,
|
|
|
|
|
guint32 preferred_lft,
|
2023-02-17 12:07:05 +01:00
|
|
|
guint32 flags,
|
|
|
|
|
char **out_extack_msg);
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean (*ip4_address_delete)(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
in_addr_t address,
|
|
|
|
|
guint8 plen,
|
|
|
|
|
in_addr_t peer_address);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*ip6_address_delete)(NMPlatform *self,
|
2019-01-02 11:28:53 +01:00
|
|
|
int ifindex,
|
|
|
|
|
struct in6_addr address,
|
|
|
|
|
guint8 plen);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2023-02-17 12:07:05 +01:00
|
|
|
int (*ip_route_add)(NMPlatform *self,
|
|
|
|
|
NMPNlmFlags flags,
|
|
|
|
|
NMPObject *obj_stack,
|
|
|
|
|
char **out_extack_msg);
|
|
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int (*ip_route_get)(NMPlatform *self,
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int addr_family,
|
|
|
|
|
gconstpointer address,
|
2024-09-03 14:47:58 +02:00
|
|
|
guint32 fwmark,
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int oif_ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
NMPObject **out_route);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int (*routing_rule_add)(NMPlatform *self,
|
2019-03-05 12:13:04 +01:00
|
|
|
NMPNlmFlags flags,
|
|
|
|
|
const NMPlatformRoutingRule *routing_rule);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int (*qdisc_add)(NMPlatform *self, NMPNlmFlags flags, const NMPlatformQdisc *qdisc);
|
2021-09-14 17:46:02 +02:00
|
|
|
int (*qdisc_delete)(NMPlatform *self, int ifindex, guint32 parent, gboolean log_error);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int (*tfilter_add)(NMPlatform *self, NMPNlmFlags flags, const NMPlatformTfilter *tfilter);
|
2021-09-14 17:46:02 +02:00
|
|
|
int (*tfilter_delete)(NMPlatform *self, int ifindex, guint32 parent, gboolean log_error);
|
platform: add genl socket support for events and genl family
For generic netlink, the family-id is important. It changes when
loading/unloading a module, so we should not cache it indefinitely.
To get this right, takes some effort. For "nl80211", "nl802154"
and "wireguard", we only cache the family ID in relation to an
interface. If the module gets unloaded, the family ID also becomes
irrelevant and we need to re-fetch it the next time.
For generic families like "mptcp_pm" or "ethtool", they are commonly not
kernel modules and cannot be unloaded. So caching them would be
(probably) fine.
Still. Some generic netlink families emit notifications, and it will
be interesting to be able to handle them. Since that will be useful later,
start by doing something simple: let the generic netlink family also be
cached this way. Generic netlink will send notifications when a family gets
added/deleted, and we can use that to reliably cache the family ID.
We only care about a well-known set of generic families. Unlike libnl
(which has "struct genl_family" object to handle any family), we can hard
code the few we care about (NMPGenlFamilyType).
This adds the necessary infrastructure of NMLinuxPlatform to listen to
events on the generic netlink socket.
2022-06-21 22:01:28 +02:00
|
|
|
|
|
|
|
|
guint16 (*genl_get_family_id)(NMPlatform *platform, NMPGenlFamilyType family_type);
|
|
|
|
|
|
2022-07-14 22:19:47 +02:00
|
|
|
int (*mptcp_addr_update)(NMPlatform *self, NMOptionBool add, const NMPlatformMptcpAddr *addr);
|
|
|
|
|
|
|
|
|
|
GPtrArray *(*mptcp_addrs_dump)(NMPlatform *self);
|
|
|
|
|
|
2025-03-24 20:57:58 +01:00
|
|
|
gboolean (*ethtool_get_pause)(NMPlatform *self, int ifindex, NMEthtoolPauseState *pause);
|
|
|
|
|
gboolean (*ethtool_set_pause)(NMPlatform *self, int ifindex, const NMEthtoolPauseState *pause);
|
2025-03-24 21:16:47 +01:00
|
|
|
gboolean (*ethtool_get_eee)(NMPlatform *self, int ifindex, NMEthtoolEEEState *eee);
|
|
|
|
|
gboolean (*ethtool_set_eee)(NMPlatform *self, int ifindex, const NMEthtoolEEEState *eee);
|
2025-03-24 21:36:22 +01:00
|
|
|
gboolean (*ethtool_get_ring)(NMPlatform *self, int ifindex, NMEthtoolRingState *ring);
|
|
|
|
|
gboolean (*ethtool_set_ring)(NMPlatform *self, int ifindex, const NMEthtoolRingState *ring);
|
2013-03-27 22:23:24 +01:00
|
|
|
} NMPlatformClass;
|
|
|
|
|
|
|
|
|
|
/* NMPlatform signals
|
|
|
|
|
*
|
|
|
|
|
* Each signal handler is called with a type-specific object that provides
|
|
|
|
|
* key attributes that constitute identity of the object. They may also
|
|
|
|
|
* provide additional attributes for convenience.
|
|
|
|
|
*
|
|
|
|
|
* The object only intended to be used by the signal handler to determine
|
|
|
|
|
* the current values. It is no longer valid after the signal handler exits
|
|
|
|
|
* but you are free to copy the provided information and use it for later
|
|
|
|
|
* reference.
|
|
|
|
|
*/
|
2014-03-07 19:04:38 +01:00
|
|
|
#define NM_PLATFORM_SIGNAL_LINK_CHANGED "link-changed"
|
|
|
|
|
#define NM_PLATFORM_SIGNAL_IP4_ADDRESS_CHANGED "ip4-address-changed"
|
|
|
|
|
#define NM_PLATFORM_SIGNAL_IP6_ADDRESS_CHANGED "ip6-address-changed"
|
|
|
|
|
#define NM_PLATFORM_SIGNAL_IP4_ROUTE_CHANGED "ip4-route-changed"
|
|
|
|
|
#define NM_PLATFORM_SIGNAL_IP6_ROUTE_CHANGED "ip6-route-changed"
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
#define NM_PLATFORM_SIGNAL_ROUTING_RULE_CHANGED "routing-rule-changed"
|
2017-11-15 20:36:35 +01:00
|
|
|
#define NM_PLATFORM_SIGNAL_QDISC_CHANGED "qdisc-changed"
|
2017-11-15 20:36:35 +01:00
|
|
|
#define NM_PLATFORM_SIGNAL_TFILTER_CHANGED "tfilter-changed"
|
2013-03-27 22:23:24 +01:00
|
|
|
|
2015-04-24 12:28:07 +02:00
|
|
|
const char *nm_platform_signal_change_type_to_string(NMPlatformSignalChangeType change_type);
|
|
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2013-03-27 22:23:24 +01:00
|
|
|
|
|
|
|
|
GType nm_platform_get_type(void);
|
|
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2013-03-27 22:23:24 +01:00
|
|
|
|
2017-08-21 23:17:12 +02:00
|
|
|
/**
|
|
|
|
|
* nm_platform_route_table_coerce:
|
2017-09-22 15:26:56 +02:00
|
|
|
* @table: the route table, in its original value as received
|
|
|
|
|
* from rtm_table/RTA_TABLE.
|
2017-08-21 23:17:12 +02:00
|
|
|
*
|
2017-09-22 15:26:56 +02:00
|
|
|
* Returns: returns the coerced table id, that can be stored in
|
|
|
|
|
* NMPlatformIPRoute.table_coerced.
|
2017-08-21 23:17:12 +02:00
|
|
|
*/
|
|
|
|
|
static inline guint32
|
|
|
|
|
nm_platform_route_table_coerce(guint32 table)
|
|
|
|
|
{
|
2017-09-22 15:26:56 +02:00
|
|
|
/* For kernel, the default table is RT_TABLE_MAIN (254).
|
|
|
|
|
* We want that in NMPlatformIPRoute.table_coerced a numeric
|
|
|
|
|
* zero is the default. Hence, @table_coerced swaps the
|
|
|
|
|
* value 0 and 254. Use nm_platform_route_table_coerce()
|
|
|
|
|
* and nm_platform_route_table_uncoerce() to convert between
|
|
|
|
|
* the two domains. */
|
2017-08-21 23:17:12 +02:00
|
|
|
switch (table) {
|
|
|
|
|
case 0 /* RT_TABLE_UNSPEC */:
|
|
|
|
|
return 254;
|
|
|
|
|
case 254 /* RT_TABLE_MAIN */:
|
|
|
|
|
return 0;
|
|
|
|
|
default:
|
|
|
|
|
return table;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-09-22 15:26:56 +02:00
|
|
|
/**
|
|
|
|
|
* nm_platform_route_table_uncoerce:
|
platform: add flags to NMPlatformIP[46]Route to allow overriding the route table and metric
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
2020-09-23 13:38:39 +02:00
|
|
|
* @table_coerced: the route table, in its coerced value
|
2017-09-22 15:26:56 +02:00
|
|
|
* @normalize: whether to normalize RT_TABLE_UNSPEC to
|
|
|
|
|
* RT_TABLE_MAIN. For kernel, routes with a table id
|
|
|
|
|
* RT_TABLE_UNSPEC do not exist and are treated like
|
|
|
|
|
* RT_TABLE_MAIN.
|
|
|
|
|
*
|
|
|
|
|
* Returns: reverts the coerced table ID in NMPlatformIPRoute.table_coerced
|
|
|
|
|
* to the original value as kernel understands it.
|
|
|
|
|
*/
|
|
|
|
|
static inline guint32
|
|
|
|
|
nm_platform_route_table_uncoerce(guint32 table_coerced, gboolean normalize)
|
|
|
|
|
{
|
|
|
|
|
/* this undoes nm_platform_route_table_coerce(). */
|
|
|
|
|
switch (table_coerced) {
|
|
|
|
|
case 0 /* RT_TABLE_UNSPEC */:
|
|
|
|
|
return 254;
|
|
|
|
|
case 254 /* RT_TABLE_MAIN */:
|
|
|
|
|
return normalize ? 254 : 0;
|
|
|
|
|
default:
|
|
|
|
|
return table_coerced;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
nm_platform_route_table_is_main(guint32 table)
|
|
|
|
|
{
|
|
|
|
|
/* same as
|
|
|
|
|
* nm_platform_route_table_uncoerce (table, TRUE) == RT_TABLE_MAIN
|
|
|
|
|
* and
|
|
|
|
|
* nm_platform_route_table_uncoerce (nm_platform_route_table_coerce (table), TRUE) == RT_TABLE_MAIN
|
|
|
|
|
*
|
|
|
|
|
* That is, the function operates the same on @table and its coerced
|
|
|
|
|
* form.
|
|
|
|
|
*/
|
|
|
|
|
return table == 0 || table == 254;
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-03 10:47:41 +02:00
|
|
|
/**
|
|
|
|
|
* nm_platform_route_scope_inv:
|
|
|
|
|
* @scope: the route scope, either its original value, or its inverse.
|
|
|
|
|
*
|
|
|
|
|
* This function is useful, because the constants such as RT_SCOPE_NOWHERE
|
|
|
|
|
* are 'int', so ~scope also gives an 'int'. This function gets the type
|
|
|
|
|
* casts to guint8 right.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the bitwise inverse of the route scope.
|
|
|
|
|
* */
|
2015-06-25 18:44:58 +02:00
|
|
|
#define nm_platform_route_scope_inv _nm_platform_uint8_inv
|
2015-05-03 10:47:41 +02:00
|
|
|
static inline guint8
|
2015-06-25 18:44:58 +02:00
|
|
|
_nm_platform_uint8_inv(guint8 scope)
|
2015-05-03 10:47:41 +02:00
|
|
|
{
|
|
|
|
|
return (guint8) ~scope;
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-23 22:31:51 +02:00
|
|
|
static inline int
|
|
|
|
|
_nm_platform_link_get_inet6_addr_gen_mode(const NMPlatformLink *pllink)
|
|
|
|
|
{
|
|
|
|
|
if (!pllink)
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
return _nm_platform_uint8_inv(pllink->inet6_addr_gen_mode_inv);
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-07 18:50:54 +01:00
|
|
|
static inline gboolean
|
|
|
|
|
nm_platform_route_type_is_nodev(guint8 type)
|
|
|
|
|
{
|
2022-02-25 21:01:04 +01:00
|
|
|
return NM_IN_SET(type,
|
|
|
|
|
6 /* RTN_BLACKHOLE */,
|
|
|
|
|
7 /* RTN_UNREACHABLE */,
|
|
|
|
|
8 /* RTN_PROHIBIT */,
|
|
|
|
|
9 /* RTN_THROW */);
|
2022-02-07 18:50:54 +01:00
|
|
|
}
|
|
|
|
|
|
2020-05-29 17:53:02 +02:00
|
|
|
/**
|
|
|
|
|
* nm_platform_route_type_coerce:
|
|
|
|
|
* @table: the route type, in its original value.
|
|
|
|
|
*
|
|
|
|
|
* Returns: returns the coerced type, that can be stored in
|
|
|
|
|
* NMPlatformIPRoute.type_coerced.
|
|
|
|
|
*/
|
|
|
|
|
static inline guint8
|
|
|
|
|
nm_platform_route_type_coerce(guint8 type)
|
|
|
|
|
{
|
|
|
|
|
switch (type) {
|
|
|
|
|
case 0 /* RTN_UNSPEC */:
|
|
|
|
|
return 1;
|
|
|
|
|
case 1 /* RTN_UNICAST */:
|
|
|
|
|
return 0;
|
|
|
|
|
default:
|
|
|
|
|
return type;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_platform_route_type_uncoerce:
|
|
|
|
|
* @table: the type table, in its coerced value
|
|
|
|
|
*
|
|
|
|
|
* Returns: reverts the coerced type in NMPlatformIPRoute.type_coerced
|
|
|
|
|
* to the original value as kernel understands it.
|
|
|
|
|
*/
|
|
|
|
|
static inline guint8
|
|
|
|
|
nm_platform_route_type_uncoerce(guint8 type_coerced)
|
|
|
|
|
{
|
|
|
|
|
return nm_platform_route_type_coerce(type_coerced);
|
|
|
|
|
}
|
|
|
|
|
|
2022-07-22 20:28:35 +02:00
|
|
|
static inline guint8
|
|
|
|
|
nm_platform_ip4_address_get_scope(in_addr_t addr)
|
|
|
|
|
{
|
|
|
|
|
/* For IPv4 addresses, we can set any scope we want (for any address).
|
|
|
|
|
* However, there are scopes that make sense based on the address,
|
|
|
|
|
* so choose those. */
|
glib-aux: rename IP address related helpers from "nm-inet-utils.h"
- name things related to `in_addr_t`, `struct in6_addr`, `NMIPAddr` as
`nm_ip4_addr_*()`, `nm_ip6_addr_*()`, `nm_ip_addr_*()`, respectively.
- we have a wrapper `nm_inet_ntop()` for `inet_ntop()`. This name
of our wrapper is chosen to be familiar with the libc underlying
function. With this, also name functions that are about string
representations of addresses `nm_inet_*()`, `nm_inet4_*()`,
`nm_inet6_*()`. For example, `nm_inet_parse_str()`,
`nm_inet_is_normalized()`.
<<<<
R() {
git grep -l "$1" | xargs sed -i "s/\<$1\>/$2/g"
}
R NM_CMP_DIRECT_IN4ADDR_SAME_PREFIX NM_CMP_DIRECT_IP4_ADDR_SAME_PREFIX
R NM_CMP_DIRECT_IN6ADDR_SAME_PREFIX NM_CMP_DIRECT_IP6_ADDR_SAME_PREFIX
R NM_UTILS_INET_ADDRSTRLEN NM_INET_ADDRSTRLEN
R _nm_utils_inet4_ntop nm_inet4_ntop
R _nm_utils_inet6_ntop nm_inet6_ntop
R _nm_utils_ip4_get_default_prefix nm_ip4_addr_get_default_prefix
R _nm_utils_ip4_get_default_prefix0 nm_ip4_addr_get_default_prefix0
R _nm_utils_ip4_netmask_to_prefix nm_ip4_addr_netmask_to_prefix
R _nm_utils_ip4_prefix_to_netmask nm_ip4_addr_netmask_from_prefix
R nm_utils_inet4_ntop_dup nm_inet4_ntop_dup
R nm_utils_inet6_ntop_dup nm_inet6_ntop_dup
R nm_utils_inet_ntop nm_inet_ntop
R nm_utils_inet_ntop_dup nm_inet_ntop_dup
R nm_utils_ip4_address_clear_host_address nm_ip4_addr_clear_host_address
R nm_utils_ip4_address_is_link_local nm_ip4_addr_is_link_local
R nm_utils_ip4_address_is_loopback nm_ip4_addr_is_loopback
R nm_utils_ip4_address_is_zeronet nm_ip4_addr_is_zeronet
R nm_utils_ip4_address_same_prefix nm_ip4_addr_same_prefix
R nm_utils_ip4_address_same_prefix_cmp nm_ip4_addr_same_prefix_cmp
R nm_utils_ip6_address_clear_host_address nm_ip6_addr_clear_host_address
R nm_utils_ip6_address_same_prefix nm_ip6_addr_same_prefix
R nm_utils_ip6_address_same_prefix_cmp nm_ip6_addr_same_prefix_cmp
R nm_utils_ip6_is_ula nm_ip6_addr_is_ula
R nm_utils_ip_address_same_prefix nm_ip_addr_same_prefix
R nm_utils_ip_address_same_prefix_cmp nm_ip_addr_same_prefix_cmp
R nm_utils_ip_is_site_local nm_ip_addr_is_site_local
R nm_utils_ipaddr_is_normalized nm_inet_is_normalized
R nm_utils_ipaddr_is_valid nm_inet_is_valid
R nm_utils_ipx_address_clear_host_address nm_ip_addr_clear_host_address
R nm_utils_parse_inaddr nm_inet_parse_str
R nm_utils_parse_inaddr_bin nm_inet_parse_bin
R nm_utils_parse_inaddr_bin_full nm_inet_parse_bin_full
R nm_utils_parse_inaddr_prefix nm_inet_parse_with_prefix_str
R nm_utils_parse_inaddr_prefix_bin nm_inet_parse_with_prefix_bin
R test_nm_utils_ip6_address_same_prefix test_nm_ip_addr_same_prefix
./contrib/scripts/nm-code-format.sh -F
2022-08-19 13:15:20 +02:00
|
|
|
return nm_ip4_addr_is_loopback(addr) ? (254 /* RT_SCOPE_HOST */)
|
|
|
|
|
: nm_ip4_addr_is_link_local(addr) ? (253 /* RT_SCOPE_LINK */)
|
|
|
|
|
: (0 /* RT_SCOPE_UNIVERSE */);
|
2022-07-22 20:28:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline guint8
|
|
|
|
|
nm_platform_ip6_address_get_scope(const struct in6_addr *addr)
|
|
|
|
|
{
|
|
|
|
|
/* For IPv6, kernel does not allow userspace to configure the address scope.
|
|
|
|
|
* Instead, it is calculated based on the address. See rt_scope() and
|
|
|
|
|
* ipv6_addr_scope(). We do the same here. */
|
|
|
|
|
return IN6_IS_ADDR_LOOPBACK(addr) ? (254 /* RT_SCOPE_HOST */)
|
|
|
|
|
: IN6_IS_ADDR_LINKLOCAL(addr) ? (253 /* RT_SCOPE_LINK */)
|
|
|
|
|
: IN6_IS_ADDR_SITELOCAL(addr) ? (200 /* RT_SCOPE_SITE */)
|
|
|
|
|
: (0 /* RT_SCOPE_UNIVERSE */);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline guint8
|
|
|
|
|
nm_platform_ip_address_get_scope(int addr_family, gconstpointer addr)
|
|
|
|
|
{
|
2022-08-03 18:50:08 +02:00
|
|
|
/* Note that this function returns the scope as we configure
|
|
|
|
|
* it in kernel (for IPv4) or as kernel chooses it (for IPv6).
|
|
|
|
|
*
|
glib-aux: rename IP address related helpers from "nm-inet-utils.h"
- name things related to `in_addr_t`, `struct in6_addr`, `NMIPAddr` as
`nm_ip4_addr_*()`, `nm_ip6_addr_*()`, `nm_ip_addr_*()`, respectively.
- we have a wrapper `nm_inet_ntop()` for `inet_ntop()`. This name
of our wrapper is chosen to be familiar with the libc underlying
function. With this, also name functions that are about string
representations of addresses `nm_inet_*()`, `nm_inet4_*()`,
`nm_inet6_*()`. For example, `nm_inet_parse_str()`,
`nm_inet_is_normalized()`.
<<<<
R() {
git grep -l "$1" | xargs sed -i "s/\<$1\>/$2/g"
}
R NM_CMP_DIRECT_IN4ADDR_SAME_PREFIX NM_CMP_DIRECT_IP4_ADDR_SAME_PREFIX
R NM_CMP_DIRECT_IN6ADDR_SAME_PREFIX NM_CMP_DIRECT_IP6_ADDR_SAME_PREFIX
R NM_UTILS_INET_ADDRSTRLEN NM_INET_ADDRSTRLEN
R _nm_utils_inet4_ntop nm_inet4_ntop
R _nm_utils_inet6_ntop nm_inet6_ntop
R _nm_utils_ip4_get_default_prefix nm_ip4_addr_get_default_prefix
R _nm_utils_ip4_get_default_prefix0 nm_ip4_addr_get_default_prefix0
R _nm_utils_ip4_netmask_to_prefix nm_ip4_addr_netmask_to_prefix
R _nm_utils_ip4_prefix_to_netmask nm_ip4_addr_netmask_from_prefix
R nm_utils_inet4_ntop_dup nm_inet4_ntop_dup
R nm_utils_inet6_ntop_dup nm_inet6_ntop_dup
R nm_utils_inet_ntop nm_inet_ntop
R nm_utils_inet_ntop_dup nm_inet_ntop_dup
R nm_utils_ip4_address_clear_host_address nm_ip4_addr_clear_host_address
R nm_utils_ip4_address_is_link_local nm_ip4_addr_is_link_local
R nm_utils_ip4_address_is_loopback nm_ip4_addr_is_loopback
R nm_utils_ip4_address_is_zeronet nm_ip4_addr_is_zeronet
R nm_utils_ip4_address_same_prefix nm_ip4_addr_same_prefix
R nm_utils_ip4_address_same_prefix_cmp nm_ip4_addr_same_prefix_cmp
R nm_utils_ip6_address_clear_host_address nm_ip6_addr_clear_host_address
R nm_utils_ip6_address_same_prefix nm_ip6_addr_same_prefix
R nm_utils_ip6_address_same_prefix_cmp nm_ip6_addr_same_prefix_cmp
R nm_utils_ip6_is_ula nm_ip6_addr_is_ula
R nm_utils_ip_address_same_prefix nm_ip_addr_same_prefix
R nm_utils_ip_address_same_prefix_cmp nm_ip_addr_same_prefix_cmp
R nm_utils_ip_is_site_local nm_ip_addr_is_site_local
R nm_utils_ipaddr_is_normalized nm_inet_is_normalized
R nm_utils_ipaddr_is_valid nm_inet_is_valid
R nm_utils_ipx_address_clear_host_address nm_ip_addr_clear_host_address
R nm_utils_parse_inaddr nm_inet_parse_str
R nm_utils_parse_inaddr_bin nm_inet_parse_bin
R nm_utils_parse_inaddr_bin_full nm_inet_parse_bin_full
R nm_utils_parse_inaddr_prefix nm_inet_parse_with_prefix_str
R nm_utils_parse_inaddr_prefix_bin nm_inet_parse_with_prefix_bin
R test_nm_utils_ip6_address_same_prefix test_nm_ip_addr_same_prefix
./contrib/scripts/nm-code-format.sh -F
2022-08-19 13:15:20 +02:00
|
|
|
* That means, rfc1918 private addresses nm_ip_addr_is_site_local() are
|
2022-08-03 18:50:08 +02:00
|
|
|
* considered RT_SCOPE_UNIVERSE.
|
|
|
|
|
*
|
|
|
|
|
* Also, the deprecated IN6_IS_ADDR_SITELOCAL() addresses (fec0::/10)
|
|
|
|
|
* are considered RT_SCOPE_SITE, while unique local addresses (ULA, fc00::/7)
|
|
|
|
|
* are considered RT_SCOPE_UNIVERSE.
|
|
|
|
|
*
|
|
|
|
|
* You may not want to use this function when reasoning about
|
|
|
|
|
* site-local addresses (RFC1918, ULA). */
|
2022-07-22 20:28:35 +02:00
|
|
|
if (NM_IS_IPv4(addr_family))
|
|
|
|
|
return nm_platform_ip4_address_get_scope(*((in_addr_t *) addr));
|
|
|
|
|
return nm_platform_ip6_address_get_scope(addr);
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-29 10:51:38 +02:00
|
|
|
gboolean nm_platform_get_use_udev(NMPlatform *self);
|
2017-04-17 18:40:52 +02:00
|
|
|
gboolean nm_platform_get_log_with_ptr(NMPlatform *self);
|
2021-09-17 17:32:57 +02:00
|
|
|
gboolean nm_platform_get_cache_tc(NMPlatform *self);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-02-19 01:06:28 +01:00
|
|
|
NMPNetns *nm_platform_netns_get(NMPlatform *self);
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean nm_platform_netns_push(NMPlatform *self, NMPNetns **netns);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-04-28 07:55:30 +02:00
|
|
|
const char *nm_link_type_to_string(NMLinkType link_type);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-12-08 14:29:00 +01:00
|
|
|
#define NMP_SYSCTL_PATHID_ABSOLUTE(path) ((const char *) NULL), -1, (path)
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2023-06-26 15:07:31 +02:00
|
|
|
/* Uses alloca(). Use with care.
|
|
|
|
|
*
|
|
|
|
|
* Like NMP_SYSCTL_PATHID_NETDIR_A(), but "path" must not be a string literal.
|
|
|
|
|
* This is the "UNSAFE" part, where there is no compile time check for the
|
|
|
|
|
* maximum string length. It still must be reasonably short to not overflow
|
|
|
|
|
* the stack (the runtime assert checks for <200 chars). */
|
2023-06-26 15:01:04 +02:00
|
|
|
#define NMP_SYSCTL_PATHID_NETDIR_UNSAFE_A(dirfd, ifname, path) \
|
2023-05-25 15:05:29 +02:00
|
|
|
nm_sprintf_buf_unsafe_a(NM_STRLEN("net:/sys/class/net//\0") + NM_IFNAMSIZ + ({ \
|
|
|
|
|
const gsize _l = strlen(path); \
|
|
|
|
|
\
|
|
|
|
|
nm_assert(_l < 200); \
|
|
|
|
|
_l; \
|
|
|
|
|
}), \
|
|
|
|
|
"net:/sys/class/net/%s/%s", \
|
|
|
|
|
(ifname), \
|
|
|
|
|
(path)), \
|
2016-12-08 15:12:52 +01:00
|
|
|
(dirfd), (path)
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2023-06-26 15:07:31 +02:00
|
|
|
/* Uses alloca(). Use with care. */
|
2023-06-26 15:01:04 +02:00
|
|
|
#define NMP_SYSCTL_PATHID_NETDIR_A(dirfd, ifname, path) \
|
2023-05-25 15:05:29 +02:00
|
|
|
nm_sprintf_bufa(NM_STRLEN("net:/sys/class/net//" path "/\0") + NM_IFNAMSIZ, \
|
|
|
|
|
"net:/sys/class/net/%s/%s", \
|
|
|
|
|
(ifname), \
|
|
|
|
|
path), \
|
2016-12-08 15:12:52 +01:00
|
|
|
(dirfd), ("" path "")
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-12-08 15:12:52 +01:00
|
|
|
int nm_platform_sysctl_open_netdir(NMPlatform *self, int ifindex, char *out_ifname);
|
2016-12-08 14:29:00 +01:00
|
|
|
gboolean nm_platform_sysctl_set(NMPlatform *self,
|
|
|
|
|
const char *pathid,
|
|
|
|
|
int dirfd,
|
|
|
|
|
const char *path,
|
|
|
|
|
const char *value);
|
2021-11-09 13:28:54 +01:00
|
|
|
void nm_platform_sysctl_set_async(NMPlatform *self,
|
|
|
|
|
const char *pathid,
|
2019-03-05 10:20:25 +01:00
|
|
|
int dirfd,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *path,
|
|
|
|
|
const char *const *values,
|
2019-03-05 10:20:25 +01:00
|
|
|
NMPlatformAsyncCallback callback,
|
|
|
|
|
gpointer data,
|
2021-11-09 13:28:54 +01:00
|
|
|
GCancellable *cancellable);
|
|
|
|
|
char *nm_platform_sysctl_get(NMPlatform *self, const char *pathid, int dirfd, const char *path);
|
2016-12-08 14:29:00 +01:00
|
|
|
gint32 nm_platform_sysctl_get_int32(NMPlatform *self,
|
|
|
|
|
const char *pathid,
|
|
|
|
|
int dirfd,
|
|
|
|
|
const char *path,
|
|
|
|
|
gint32 fallback);
|
|
|
|
|
gint64 nm_platform_sysctl_get_int_checked(NMPlatform *self,
|
|
|
|
|
const char *pathid,
|
|
|
|
|
int dirfd,
|
|
|
|
|
const char *path,
|
|
|
|
|
guint base,
|
|
|
|
|
gint64 min,
|
|
|
|
|
gint64 max,
|
|
|
|
|
gint64 fallback);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
char *nm_platform_sysctl_ip_conf_get(NMPlatform *self,
|
2018-12-13 11:48:06 +01:00
|
|
|
int addr_family,
|
|
|
|
|
const char *ifname,
|
|
|
|
|
const char *property);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
gint64 nm_platform_sysctl_ip_conf_get_int_checked(NMPlatform *self,
|
2018-12-13 11:48:06 +01:00
|
|
|
int addr_family,
|
|
|
|
|
const char *ifname,
|
|
|
|
|
const char *property,
|
|
|
|
|
guint base,
|
|
|
|
|
gint64 min,
|
|
|
|
|
gint64 max,
|
|
|
|
|
gint64 fallback);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean nm_platform_sysctl_ip_conf_set(NMPlatform *self,
|
2018-12-13 11:48:06 +01:00
|
|
|
int addr_family,
|
|
|
|
|
const char *ifname,
|
|
|
|
|
const char *property,
|
|
|
|
|
const char *value);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean nm_platform_sysctl_ip_conf_set_int64(NMPlatform *self,
|
2018-12-13 11:48:06 +01:00
|
|
|
int addr_family,
|
|
|
|
|
const char *ifname,
|
|
|
|
|
const char *property,
|
|
|
|
|
gint64 value);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-12-13 12:55:51 +01:00
|
|
|
gboolean
|
|
|
|
|
nm_platform_sysctl_ip_conf_set_ipv6_hop_limit_safe(NMPlatform *self, const char *iface, int value);
|
2019-08-23 10:39:22 +02:00
|
|
|
gboolean nm_platform_sysctl_ip_neigh_set_ipv6_reachable_time(NMPlatform *self,
|
2018-12-13 12:55:51 +01:00
|
|
|
const char *iface,
|
2019-08-23 10:39:22 +02:00
|
|
|
guint value_ms);
|
|
|
|
|
gboolean nm_platform_sysctl_ip_neigh_set_ipv6_retrans_time(NMPlatform *self,
|
|
|
|
|
const char *iface,
|
|
|
|
|
guint value_ms);
|
2019-04-25 12:44:53 +02:00
|
|
|
int nm_platform_sysctl_ip_conf_get_rp_filter_ipv4(NMPlatform *platform,
|
|
|
|
|
const char *iface,
|
|
|
|
|
gboolean consider_all,
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean *out_due_to_all);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-01-27 13:44:09 +01:00
|
|
|
const char *nm_platform_if_indextoname(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
char out_ifname[static 16 /* IFNAMSIZ */]);
|
2016-12-26 11:54:30 +01:00
|
|
|
int nm_platform_if_nametoindex(NMPlatform *self, const char *ifname);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-07-04 12:49:47 +02:00
|
|
|
const NMPObject *nm_platform_link_get_obj(NMPlatform *self, int ifindex, gboolean visible_only);
|
2015-06-20 12:05:01 +02:00
|
|
|
const NMPlatformLink *nm_platform_link_get(NMPlatform *self, int ifindex);
|
|
|
|
|
const NMPlatformLink *nm_platform_link_get_by_ifname(NMPlatform *self, const char *ifname);
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink *nm_platform_link_get_by_address(NMPlatform *self,
|
2018-05-24 15:03:40 +02:00
|
|
|
NMLinkType link_type,
|
|
|
|
|
gconstpointer address,
|
|
|
|
|
size_t length);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2023-12-06 10:16:55 +01:00
|
|
|
GPtrArray *nm_platform_link_get_all(NMPlatform *self);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int nm_platform_link_add(NMPlatform *self,
|
2019-12-31 02:54:07 +01:00
|
|
|
NMLinkType type,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *name,
|
2019-12-31 11:47:33 +01:00
|
|
|
int parent,
|
2021-11-09 13:28:54 +01:00
|
|
|
const void *address,
|
2019-12-31 02:54:07 +01:00
|
|
|
size_t address_len,
|
2020-10-23 09:41:01 +02:00
|
|
|
guint32 mtu,
|
2019-12-31 02:54:07 +01:00
|
|
|
gconstpointer extra_data,
|
|
|
|
|
const NMPlatformLink **out_link);
|
|
|
|
|
|
2023-02-27 10:55:29 +01:00
|
|
|
int nm_platform_link_change_extra(NMPlatform *self,
|
|
|
|
|
NMLinkType type,
|
|
|
|
|
int ifindex,
|
|
|
|
|
gconstpointer extra_data);
|
2022-03-16 11:30:44 +01:00
|
|
|
|
2019-12-31 02:54:07 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_veth_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
|
|
|
|
const char *peer,
|
2019-12-31 02:54:07 +01:00
|
|
|
const NMPlatformLink **out_link)
|
|
|
|
|
{
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_VETH, name, 0, NULL, 0, 0, peer, out_link);
|
2019-12-31 02:54:07 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_dummy_add(NMPlatform *self, const char *name, const NMPlatformLink **out_link)
|
|
|
|
|
{
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_DUMMY, name, 0, NULL, 0, 0, NULL, out_link);
|
2019-12-31 02:54:07 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_bridge_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
|
|
|
|
const void *address,
|
2019-12-31 02:54:07 +01:00
|
|
|
size_t address_len,
|
2020-10-30 16:35:25 +01:00
|
|
|
guint32 mtu,
|
2020-08-05 13:46:28 -04:00
|
|
|
const NMPlatformLnkBridge *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 02:54:07 +01:00
|
|
|
{
|
2020-08-05 13:46:28 -04:00
|
|
|
return nm_platform_link_add(self,
|
|
|
|
|
NM_LINK_TYPE_BRIDGE,
|
|
|
|
|
name,
|
|
|
|
|
0,
|
|
|
|
|
address,
|
|
|
|
|
address_len,
|
2020-10-30 16:35:25 +01:00
|
|
|
mtu,
|
2020-08-05 13:46:28 -04:00
|
|
|
props,
|
|
|
|
|
out_link);
|
2019-12-31 02:54:07 +01:00
|
|
|
}
|
|
|
|
|
|
2022-03-16 11:30:44 +01:00
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_bridge_change(NMPlatform *self, int ifindex, const NMPlatformLnkBridge *props)
|
|
|
|
|
{
|
2023-02-27 10:55:29 +01:00
|
|
|
return nm_platform_link_change_extra(self, NM_LINK_TYPE_BRIDGE, ifindex, props);
|
2022-03-16 11:30:44 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-31 02:54:07 +01:00
|
|
|
static inline int
|
2022-07-25 16:01:35 +02:00
|
|
|
nm_platform_link_bond_change(NMPlatform *self, int ifindex, const NMPlatformLnkBond *props)
|
|
|
|
|
{
|
2023-02-27 10:55:29 +01:00
|
|
|
return nm_platform_link_change_extra(self, NM_LINK_TYPE_BOND, ifindex, props);
|
2022-07-25 16:01:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_bond_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
|
|
|
|
const NMPlatformLnkBond *props,
|
|
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 02:54:07 +01:00
|
|
|
{
|
2022-07-25 16:01:35 +02:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_BOND, name, 0, NULL, 0, 0, props, out_link);
|
2019-12-31 02:54:07 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_team_add(NMPlatform *self, const char *name, const NMPlatformLink **out_link)
|
|
|
|
|
{
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_TEAM, name, 0, NULL, 0, 0, NULL, out_link);
|
2019-12-31 02:54:07 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_wireguard_add(NMPlatform *self, const char *name, const NMPlatformLink **out_link)
|
|
|
|
|
{
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_WIREGUARD, name, 0, NULL, 0, 0, NULL, out_link);
|
2019-12-31 02:54:07 +01:00
|
|
|
}
|
2017-05-26 14:00:29 +02:00
|
|
|
|
2019-12-31 03:12:42 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_gre_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
|
|
|
|
const void *address,
|
2019-12-31 03:37:48 +01:00
|
|
|
size_t address_len,
|
2019-12-31 03:12:42 +01:00
|
|
|
const NMPlatformLnkGre *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 03:12:42 +01:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(props, -NME_BUG);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-12-31 03:37:48 +01:00
|
|
|
return nm_platform_link_add(self,
|
|
|
|
|
props->is_tap ? NM_LINK_TYPE_GRETAP : NM_LINK_TYPE_GRE,
|
|
|
|
|
name,
|
|
|
|
|
0,
|
|
|
|
|
address,
|
|
|
|
|
address_len,
|
2020-10-23 09:41:01 +02:00
|
|
|
0,
|
2019-12-31 03:37:48 +01:00
|
|
|
props,
|
|
|
|
|
out_link);
|
2019-12-31 03:12:42 +01:00
|
|
|
}
|
|
|
|
|
|
2023-10-27 14:01:13 +02:00
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_hsr_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
|
|
|
|
const NMPlatformLnkHsr *props,
|
|
|
|
|
const NMPlatformLink **out_link)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(props, -NME_BUG);
|
|
|
|
|
|
|
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_HSR, name, 0, NULL, 0, 0, props, out_link);
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-31 11:21:00 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_sit_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
2019-12-31 11:21:00 +01:00
|
|
|
const NMPlatformLnkSit *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 11:21:00 +01:00
|
|
|
{
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_SIT, name, 0, NULL, 0, 0, props, out_link);
|
2019-12-31 11:21:00 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-31 13:04:35 +01:00
|
|
|
static inline int
|
2022-12-02 10:47:14 +01:00
|
|
|
nm_platform_link_vlan_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
|
|
|
|
int parent,
|
|
|
|
|
const NMPlatformLnkVlan *props,
|
|
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 13:04:35 +01:00
|
|
|
{
|
2022-12-02 10:47:14 +01:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_VLAN, name, parent, NULL, 0, 0, props, out_link);
|
2019-12-31 13:04:35 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-05 10:35:25 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_vrf_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
2019-12-05 10:35:25 +01:00
|
|
|
const NMPlatformLnkVrf *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link)
|
2019-12-05 10:35:25 +01:00
|
|
|
{
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_VRF, name, 0, NULL, 0, 0, props, out_link);
|
2019-12-05 10:35:25 +01:00
|
|
|
}
|
|
|
|
|
|
2022-10-24 10:17:09 +02:00
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_vti_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
|
|
|
|
const NMPlatformLnkVti *props,
|
|
|
|
|
const NMPlatformLink **out_link)
|
|
|
|
|
{
|
|
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_VTI, name, 0, NULL, 0, 0, props, out_link);
|
|
|
|
|
}
|
|
|
|
|
|
2022-10-25 08:31:47 +02:00
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_vti6_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
|
|
|
|
const NMPlatformLnkVti6 *props,
|
|
|
|
|
const NMPlatformLink **out_link)
|
|
|
|
|
{
|
|
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_VTI6, name, 0, NULL, 0, 0, props, out_link);
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-31 13:08:45 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_vxlan_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
2019-12-31 13:08:45 +01:00
|
|
|
const NMPlatformLnkVxlan *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 13:08:45 +01:00
|
|
|
{
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_VXLAN, name, 0, NULL, 0, 0, props, out_link);
|
2019-12-31 13:08:45 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-31 13:19:53 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_6lowpan_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
2019-12-31 13:19:53 +01:00
|
|
|
int parent,
|
|
|
|
|
const NMPlatformLink **out_link)
|
|
|
|
|
{
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self,
|
|
|
|
|
NM_LINK_TYPE_6LOWPAN,
|
|
|
|
|
name,
|
|
|
|
|
parent,
|
|
|
|
|
NULL,
|
|
|
|
|
0,
|
|
|
|
|
0,
|
|
|
|
|
NULL,
|
|
|
|
|
out_link);
|
2019-12-31 13:19:53 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-31 13:27:02 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_ip6tnl_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
2019-12-31 13:27:02 +01:00
|
|
|
const NMPlatformLnkIp6Tnl *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 13:27:02 +01:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(props, -NME_BUG);
|
|
|
|
|
g_return_val_if_fail(!props->is_gre, -NME_BUG);
|
|
|
|
|
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_IP6TNL, name, 0, NULL, 0, 0, props, out_link);
|
2019-12-31 13:27:02 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-31 13:44:08 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_ip6gre_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
|
|
|
|
const void *address,
|
2020-05-14 11:35:47 +02:00
|
|
|
size_t address_len,
|
2019-12-31 13:44:08 +01:00
|
|
|
const NMPlatformLnkIp6Tnl *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 13:44:08 +01:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(props, -NME_BUG);
|
|
|
|
|
g_return_val_if_fail(props->is_gre, -NME_BUG);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-05-14 11:35:47 +02:00
|
|
|
return nm_platform_link_add(self,
|
|
|
|
|
props->is_tap ? NM_LINK_TYPE_IP6GRETAP : NM_LINK_TYPE_IP6GRE,
|
|
|
|
|
name,
|
|
|
|
|
0,
|
|
|
|
|
address,
|
|
|
|
|
address_len,
|
2020-10-23 09:41:01 +02:00
|
|
|
0,
|
2020-05-14 11:35:47 +02:00
|
|
|
props,
|
|
|
|
|
out_link);
|
2019-12-31 13:44:08 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-31 13:57:00 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_ipip_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
2019-12-31 13:57:00 +01:00
|
|
|
const NMPlatformLnkIpIp *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 13:57:00 +01:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(props, -NME_BUG);
|
|
|
|
|
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self, NM_LINK_TYPE_IPIP, name, 0, NULL, 0, 0, props, out_link);
|
2019-12-31 13:57:00 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-31 14:01:58 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_macsec_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
2019-12-31 14:01:58 +01:00
|
|
|
int parent,
|
|
|
|
|
const NMPlatformLnkMacsec *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 14:01:58 +01:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(props, -NME_BUG);
|
|
|
|
|
g_return_val_if_fail(parent > 0, -NME_BUG);
|
|
|
|
|
|
2020-10-23 09:41:01 +02:00
|
|
|
return nm_platform_link_add(self,
|
|
|
|
|
NM_LINK_TYPE_MACSEC,
|
|
|
|
|
name,
|
|
|
|
|
parent,
|
|
|
|
|
NULL,
|
|
|
|
|
0,
|
|
|
|
|
0,
|
|
|
|
|
props,
|
|
|
|
|
out_link);
|
2019-12-31 14:01:58 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-31 14:09:58 +01:00
|
|
|
static inline int
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_macvlan_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
2019-12-31 14:09:58 +01:00
|
|
|
int parent,
|
|
|
|
|
const NMPlatformLnkMacvlan *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link)
|
2019-12-31 14:09:58 +01:00
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(props, -NME_BUG);
|
|
|
|
|
g_return_val_if_fail(parent > 0, -NME_BUG);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-12-31 14:09:58 +01:00
|
|
|
return nm_platform_link_add(self,
|
|
|
|
|
props->tap ? NM_LINK_TYPE_MACVTAP : NM_LINK_TYPE_MACVLAN,
|
|
|
|
|
name,
|
|
|
|
|
parent,
|
|
|
|
|
NULL,
|
|
|
|
|
0,
|
2020-10-23 09:41:01 +02:00
|
|
|
0,
|
2019-12-31 14:09:58 +01:00
|
|
|
props,
|
|
|
|
|
out_link);
|
|
|
|
|
}
|
|
|
|
|
|
2024-09-06 14:14:24 +02:00
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_ipvlan_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
|
|
|
|
int parent,
|
|
|
|
|
const NMPlatformLnkIpvlan *props,
|
|
|
|
|
const NMPlatformLink **out_link)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(props, -NME_BUG);
|
|
|
|
|
g_return_val_if_fail(parent > 0, -NME_BUG);
|
|
|
|
|
|
|
|
|
|
return nm_platform_link_add(self,
|
|
|
|
|
NM_LINK_TYPE_IPVLAN,
|
|
|
|
|
name,
|
|
|
|
|
parent,
|
|
|
|
|
NULL,
|
|
|
|
|
0,
|
|
|
|
|
0,
|
|
|
|
|
props,
|
|
|
|
|
out_link);
|
|
|
|
|
}
|
|
|
|
|
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
gboolean nm_platform_link_delete(NMPlatform *self, int ifindex);
|
2015-06-20 12:05:01 +02:00
|
|
|
|
2016-03-08 13:02:58 +01:00
|
|
|
gboolean nm_platform_link_set_netns(NMPlatform *self, int ifindex, int netns_fd);
|
|
|
|
|
|
2017-06-29 14:46:32 +02:00
|
|
|
struct _NMDedupMultiHeadEntry;
|
|
|
|
|
struct _NMPLookup;
|
2021-11-09 13:28:54 +01:00
|
|
|
const struct _NMDedupMultiHeadEntry *nm_platform_lookup(NMPlatform *self,
|
2017-06-29 14:46:32 +02:00
|
|
|
const struct _NMPLookup *lookup);
|
|
|
|
|
|
2020-09-11 12:53:49 +02:00
|
|
|
#define nm_platform_iter_obj_for_each(iter, self, lookup, obj) \
|
|
|
|
|
for (nm_dedup_multi_iter_init((iter), nm_platform_lookup((self), (lookup))); \
|
|
|
|
|
nm_platform_dedup_multi_iter_next_obj((iter), (obj), NMP_OBJECT_TYPE_UNKNOWN);)
|
|
|
|
|
|
2017-09-12 15:27:59 +02:00
|
|
|
gboolean nm_platform_lookup_predicate_routes_main(const NMPObject *obj, gpointer user_data);
|
2017-08-21 23:17:12 +02:00
|
|
|
gboolean nm_platform_lookup_predicate_routes_main_skip_rtprot_kernel(const NMPObject *obj,
|
|
|
|
|
gpointer user_data);
|
2017-06-29 15:19:35 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
GPtrArray *nm_platform_lookup_clone(NMPlatform *self,
|
2017-06-29 15:19:35 +02:00
|
|
|
const struct _NMPLookup *lookup,
|
2017-08-14 14:52:55 +02:00
|
|
|
NMPObjectPredicateFunc predicate,
|
2017-06-29 15:19:35 +02:00
|
|
|
gpointer user_data);
|
|
|
|
|
|
2018-09-14 23:49:20 -04:00
|
|
|
/* convenience methods to lookup the link and access fields of NMPlatformLink. */
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
int nm_platform_link_get_ifindex(NMPlatform *self, const char *name);
|
|
|
|
|
const char *nm_platform_link_get_name(NMPlatform *self, int ifindex);
|
|
|
|
|
NMLinkType nm_platform_link_get_type(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean nm_platform_link_is_software(NMPlatform *self, int ifindex);
|
2018-11-29 11:31:50 +01:00
|
|
|
int nm_platform_link_get_ifi_flags(NMPlatform *self, int ifindex, guint requested_flags);
|
2015-06-20 12:05:01 +02:00
|
|
|
gboolean nm_platform_link_is_up(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean nm_platform_link_is_connected(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean nm_platform_link_uses_arp(NMPlatform *self, int ifindex);
|
|
|
|
|
guint32 nm_platform_link_get_mtu(NMPlatform *self, int ifindex);
|
2021-08-23 22:31:51 +02:00
|
|
|
int nm_platform_link_get_inet6_addr_gen_mode(NMPlatform *self, int ifindex);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-06-20 12:05:01 +02:00
|
|
|
gconstpointer nm_platform_link_get_address(NMPlatform *self, int ifindex, size_t *length);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2024-07-04 12:45:42 +02:00
|
|
|
int nm_platform_link_get_controller(NMPlatform *self, int port);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-03-21 15:22:10 +01:00
|
|
|
gboolean nm_platform_link_can_assume(NMPlatform *self, int ifindex);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2023-10-31 12:07:20 +01:00
|
|
|
NMOptionBool nm_platform_link_get_unmanaged(NMPlatform *self, int ifindex);
|
2024-07-04 12:45:42 +02:00
|
|
|
gboolean nm_platform_link_supports_ports(NMPlatform *self, int ifindex);
|
2023-10-31 12:07:20 +01:00
|
|
|
const char *nm_platform_link_get_type_name(NMPlatform *self, int ifindex);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
gboolean nm_platform_link_refresh(NMPlatform *self, int ifindex);
|
2015-06-19 15:38:41 +02:00
|
|
|
void nm_platform_process_events(NMPlatform *self);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-01-11 11:15:35 +01:00
|
|
|
const NMPlatformLink *
|
|
|
|
|
nm_platform_process_events_ensure_link(NMPlatform *self, int ifindex, const char *ifname);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-04-15 09:50:48 +02:00
|
|
|
int nm_platform_link_change_flags_full(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
unsigned flags_mask,
|
|
|
|
|
unsigned flags_set);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_platform_link_change_flags:
|
|
|
|
|
* @self: platform instance
|
|
|
|
|
* @ifindex: interface index
|
|
|
|
|
* @value: flag to be set
|
|
|
|
|
* @set: value to be set
|
|
|
|
|
*
|
|
|
|
|
* Change the interface flag to the value set.
|
|
|
|
|
*
|
|
|
|
|
* Returns: nm-errno code.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_change_flags(NMPlatform *self, int ifindex, unsigned value, gboolean set)
|
|
|
|
|
{
|
|
|
|
|
return nm_platform_link_change_flags_full(self, ifindex, value, set ? value : 0u);
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2023-02-16 16:37:54 +01:00
|
|
|
gboolean nm_platform_link_change(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
NMPlatformLinkProps *props,
|
2023-03-03 16:36:23 +01:00
|
|
|
NMPlatformLinkBondPort *bond_port,
|
2023-06-06 17:32:22 +02:00
|
|
|
NMPlatformLinkBridgePort *bridge_port,
|
2023-02-16 16:37:54 +01:00
|
|
|
NMPlatformLinkChangeFlags flags);
|
|
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_link_get_udev_property(NMPlatform *self,
|
2021-04-23 12:08:09 +02:00
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *name,
|
2021-04-23 12:08:09 +02:00
|
|
|
const char **out_value);
|
2015-06-15 14:41:35 +02:00
|
|
|
const char *nm_platform_link_get_udi(NMPlatform *self, int ifindex);
|
2020-06-11 15:02:38 +02:00
|
|
|
const char *nm_platform_link_get_path(NMPlatform *self, int ifindex);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-03-12 15:54:02 +01:00
|
|
|
struct udev_device *nm_platform_link_get_udev_device(NMPlatform *self, int ifindex);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-08-25 14:53:40 +02:00
|
|
|
int nm_platform_link_set_inet6_addr_gen_mode(NMPlatform *self, int ifindex, guint8 mode);
|
|
|
|
|
gboolean
|
|
|
|
|
nm_platform_link_set_ipv6_token(NMPlatform *self, int ifindex, const NMUtilsIPv6IfaceId *iid);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_link_get_permanent_address_ethtool(NMPlatform *self,
|
2021-08-14 14:53:58 -04:00
|
|
|
int ifindex,
|
|
|
|
|
NMPLinkAddress *out_address);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_link_get_permanent_address(NMPlatform *self,
|
2021-08-14 15:13:18 -04:00
|
|
|
const NMPlatformLink *plink,
|
2021-11-09 13:28:54 +01:00
|
|
|
NMPLinkAddress *out_address);
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int nm_platform_link_set_address(NMPlatform *self, int ifindex, const void *address, size_t length);
|
|
|
|
|
int nm_platform_link_set_mtu(NMPlatform *self, int ifindex, guint32 mtu);
|
2017-07-03 10:10:34 +02:00
|
|
|
gboolean nm_platform_link_set_name(NMPlatform *self, int ifindex, const char *name);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
void nm_platform_link_set_sriov_params_async(NMPlatform *self,
|
2019-03-05 14:39:29 +01:00
|
|
|
int ifindex,
|
2024-02-14 11:30:03 +01:00
|
|
|
NMPlatformSriovParams sriov_params,
|
2019-03-05 14:39:29 +01:00
|
|
|
NMPlatformAsyncCallback callback,
|
|
|
|
|
gpointer callback_data,
|
2021-11-09 13:28:54 +01:00
|
|
|
GCancellable *cancellable);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-05-23 14:33:24 +02:00
|
|
|
gboolean
|
|
|
|
|
nm_platform_link_set_sriov_vfs(NMPlatform *self, int ifindex, const NMPlatformVF *const *vfs);
|
2024-07-25 09:49:18 +02:00
|
|
|
gboolean nm_platform_link_set_bridge_vlans(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
gboolean on_controller,
|
|
|
|
|
const NMPlatformBridgeVlan *vlans,
|
|
|
|
|
guint num_vlans);
|
2024-07-11 09:03:05 +02:00
|
|
|
gboolean nm_platform_link_get_bridge_vlans(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
NMPlatformBridgeVlan **out_vlans,
|
|
|
|
|
guint *out_num_vlans);
|
2023-01-22 21:37:46 +07:00
|
|
|
gboolean nm_platform_link_set_bridge_info(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const NMPlatformLinkSetBridgeInfoData *bridge_info);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
char *nm_platform_link_get_physical_port_id(NMPlatform *self, int ifindex);
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
guint nm_platform_link_get_dev_id(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean nm_platform_link_get_wake_on_lan(NMPlatform *self, int ifindex);
|
2014-10-03 13:41:49 -05:00
|
|
|
gboolean nm_platform_link_get_driver_info(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
char **out_driver_name,
|
|
|
|
|
char **out_driver_version,
|
|
|
|
|
char **out_fw_version);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
gboolean nm_platform_link_supports_carrier_detect(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean nm_platform_link_supports_vlans(NMPlatform *self, int ifindex);
|
2017-04-14 23:03:33 +02:00
|
|
|
gboolean nm_platform_link_supports_sriov(NMPlatform *self, int ifindex);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2024-07-04 12:45:42 +02:00
|
|
|
gboolean nm_platform_link_attach_port(NMPlatform *self, int controller, int port);
|
|
|
|
|
gboolean nm_platform_link_release_port(NMPlatform *self, int controller, int port);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2024-05-27 17:58:08 +02:00
|
|
|
gboolean nm_platform_sysctl_controller_set_option(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const char *option,
|
|
|
|
|
const char *value);
|
|
|
|
|
char *nm_platform_sysctl_controller_get_option(NMPlatform *self, int ifindex, const char *option);
|
2024-07-04 12:45:42 +02:00
|
|
|
gboolean nm_platform_sysctl_port_set_option(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const char *option,
|
|
|
|
|
const char *value);
|
|
|
|
|
char *nm_platform_sysctl_port_get_option(NMPlatform *self, int ifindex, const char *option);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPObject *nm_platform_link_get_lnk(NMPlatform *self,
|
2015-10-29 11:27:55 +01:00
|
|
|
int ifindex,
|
|
|
|
|
NMLinkType link_type,
|
|
|
|
|
const NMPlatformLink **out_link);
|
2022-07-25 16:01:35 +02:00
|
|
|
const NMPlatformLnkBond *
|
|
|
|
|
nm_platform_link_get_lnk_bond(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2020-08-05 13:46:28 -04:00
|
|
|
const NMPlatformLnkBridge *
|
|
|
|
|
nm_platform_link_get_lnk_bridge(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2015-10-12 15:15:21 +02:00
|
|
|
const NMPlatformLnkGre *
|
|
|
|
|
nm_platform_link_get_lnk_gre(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2018-06-26 10:45:35 +02:00
|
|
|
const NMPlatformLnkGre *
|
|
|
|
|
nm_platform_link_get_lnk_gretap(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2023-10-27 14:01:13 +02:00
|
|
|
const NMPlatformLnkHsr *
|
|
|
|
|
nm_platform_link_get_lnk_hsr(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2015-11-27 22:22:25 +01:00
|
|
|
const NMPlatformLnkIp6Tnl *
|
|
|
|
|
nm_platform_link_get_lnk_ip6tnl(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2018-06-26 12:06:43 +02:00
|
|
|
const NMPlatformLnkIp6Tnl *
|
|
|
|
|
nm_platform_link_get_lnk_ip6gre(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
|
|
|
|
const NMPlatformLnkIp6Tnl *
|
|
|
|
|
nm_platform_link_get_lnk_ip6gretap(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2015-11-27 22:22:25 +01:00
|
|
|
const NMPlatformLnkIpIp *
|
|
|
|
|
nm_platform_link_get_lnk_ipip(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2015-10-15 15:47:14 +02:00
|
|
|
const NMPlatformLnkInfiniband *
|
|
|
|
|
nm_platform_link_get_lnk_infiniband(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2015-11-27 14:01:56 +01:00
|
|
|
const NMPlatformLnkIpIp *
|
|
|
|
|
nm_platform_link_get_lnk_ipip(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2016-06-30 18:20:09 +02:00
|
|
|
const NMPlatformLnkMacsec *
|
|
|
|
|
nm_platform_link_get_lnk_macsec(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2015-10-12 15:15:21 +02:00
|
|
|
const NMPlatformLnkMacvlan *
|
|
|
|
|
nm_platform_link_get_lnk_macvlan(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2024-09-06 14:14:24 +02:00
|
|
|
const NMPlatformLnkIpvlan *
|
|
|
|
|
nm_platform_link_get_lnk_ipvlan(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2019-12-31 14:19:40 +01:00
|
|
|
const NMPlatformLnkMacvlan *
|
|
|
|
|
nm_platform_link_get_lnk_macvtap(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2015-11-11 18:41:48 +01:00
|
|
|
const NMPlatformLnkSit *
|
|
|
|
|
nm_platform_link_get_lnk_sit(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
core/platform: add support for TUN/TAP netlink support and various cleanup
Kernel recently got support for exposing TUN/TAP information on netlink
[1], [2], [3]. Add support for it to the platform cache.
The advantage of using netlink is that querying sysctl bypasses the
order of events of the netlink socket. It is out of sync and racy. For
example, platform cache might still think that a tun device exists, but
a subsequent lookup at sysfs might fail because the device was deleted
in the meantime. Another point is, that we don't get change
notifications via sysctl and that it requires various extra syscalls
to read the device information. If the tun information is present on
netlink, put it into the cache. This bypasses checking sysctl while
we keep looking at sysctl for backward compatibility until we require
support from kernel.
Notes:
- we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This
deviates from the model of how kernel treats TUN/TAP devices, which
makes it more complicated. The link type of a NMPlatformLink instance
should match what kernel thinks about the device. Point in case,
when parsing RTM_NETLINK messages, we very early need to determine
the link type (_linktype_get_type()). However, to determine the
type of a TUN/TAP at that point, we need to look into nested
netlink attributes which in turn depend on the type (IFLA_INFO_KIND
and IFLA_INFO_DATA), or even worse, we would need to look into
sysctl for older kernel vesions. Now, the TUN/TAP type is a property
of the link type NM_LINK_TYPE_TUN, instead of determining two
different link types.
- various parts of the API (both kernel's sysctl vs. netlink) and
NMDeviceTun vs. NMSettingTun disagree whether the PI is positive
(NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted
(NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way,
but prefer the positive form for internal API at NMPlatformLnkTun.pi.
- previously NMDeviceTun.mode could not change after initializing
the object. Allow for that to happen, because forcing some properties
that are reported by kernel to not change is wrong, in case they
might change. Of course, in practice kernel doesn't allow the device
to ever change its type, but the type property of the NMDeviceTun
should not make that assumption, because, if it actually changes, what
would it mean?
- note that as of now, new netlink API is not yet merged to mainline Linus
tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API
for now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457
[2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818
https://bugzilla.redhat.com/show_bug.cgi?id=1547213
https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
|
|
|
const NMPlatformLnkTun *
|
|
|
|
|
nm_platform_link_get_lnk_tun(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2015-10-12 13:44:44 +02:00
|
|
|
const NMPlatformLnkVlan *
|
|
|
|
|
nm_platform_link_get_lnk_vlan(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2019-12-05 10:35:25 +01:00
|
|
|
const NMPlatformLnkVrf *
|
|
|
|
|
nm_platform_link_get_lnk_vrf(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2022-10-24 10:17:09 +02:00
|
|
|
const NMPlatformLnkVti *
|
|
|
|
|
nm_platform_link_get_lnk_vti(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2022-10-25 08:31:47 +02:00
|
|
|
const NMPlatformLnkVti6 *
|
|
|
|
|
nm_platform_link_get_lnk_vti6(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2015-10-12 15:15:21 +02:00
|
|
|
const NMPlatformLnkVxlan *
|
|
|
|
|
nm_platform_link_get_lnk_vxlan(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2018-07-28 14:54:33 +02:00
|
|
|
const NMPlatformLnkWireGuard *
|
|
|
|
|
nm_platform_link_get_lnk_wireguard(NMPlatform *self, int ifindex, const NMPlatformLink **out_link);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-12-09 16:14:49 +01:00
|
|
|
gboolean nm_platform_link_vlan_set_ingress_map(NMPlatform *self, int ifindex, int from, int to);
|
|
|
|
|
gboolean nm_platform_link_vlan_set_egress_map(NMPlatform *self, int ifindex, int from, int to);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_link_vlan_change(NMPlatform *self,
|
2015-10-27 16:14:54 +01:00
|
|
|
int ifindex,
|
2021-03-03 20:57:01 +01:00
|
|
|
_NMVlanFlags flags_mask,
|
|
|
|
|
_NMVlanFlags flags_set,
|
2015-10-27 16:14:54 +01:00
|
|
|
gboolean ingress_reset_all,
|
|
|
|
|
const NMVlanQosMapping *ingress_map,
|
|
|
|
|
gsize n_ingress_map,
|
|
|
|
|
gboolean egress_reset_all,
|
|
|
|
|
const NMVlanQosMapping *egress_map,
|
|
|
|
|
gsize n_egress_map);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int nm_platform_link_infiniband_add(NMPlatform *self,
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int parent,
|
|
|
|
|
int p_key,
|
|
|
|
|
const NMPlatformLink **out_link);
|
2015-12-09 16:14:49 +01:00
|
|
|
int nm_platform_link_infiniband_delete(NMPlatform *self, int parent, int p_key);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_link_infiniband_get_properties(NMPlatform *self,
|
2015-12-09 16:14:49 +01:00
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
int *parent,
|
|
|
|
|
int *p_key,
|
2015-12-09 16:14:49 +01:00
|
|
|
const char **mode);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-12-09 16:14:49 +01:00
|
|
|
gboolean nm_platform_link_veth_get_properties(NMPlatform *self, int ifindex, int *out_peer_ifindex);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_link_tun_get_properties(NMPlatform *self,
|
core/platform: add support for TUN/TAP netlink support and various cleanup
Kernel recently got support for exposing TUN/TAP information on netlink
[1], [2], [3]. Add support for it to the platform cache.
The advantage of using netlink is that querying sysctl bypasses the
order of events of the netlink socket. It is out of sync and racy. For
example, platform cache might still think that a tun device exists, but
a subsequent lookup at sysfs might fail because the device was deleted
in the meantime. Another point is, that we don't get change
notifications via sysctl and that it requires various extra syscalls
to read the device information. If the tun information is present on
netlink, put it into the cache. This bypasses checking sysctl while
we keep looking at sysctl for backward compatibility until we require
support from kernel.
Notes:
- we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This
deviates from the model of how kernel treats TUN/TAP devices, which
makes it more complicated. The link type of a NMPlatformLink instance
should match what kernel thinks about the device. Point in case,
when parsing RTM_NETLINK messages, we very early need to determine
the link type (_linktype_get_type()). However, to determine the
type of a TUN/TAP at that point, we need to look into nested
netlink attributes which in turn depend on the type (IFLA_INFO_KIND
and IFLA_INFO_DATA), or even worse, we would need to look into
sysctl for older kernel vesions. Now, the TUN/TAP type is a property
of the link type NM_LINK_TYPE_TUN, instead of determining two
different link types.
- various parts of the API (both kernel's sysctl vs. netlink) and
NMDeviceTun vs. NMSettingTun disagree whether the PI is positive
(NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted
(NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way,
but prefer the positive form for internal API at NMPlatformLnkTun.pi.
- previously NMDeviceTun.mode could not change after initializing
the object. Allow for that to happen, because forcing some properties
that are reported by kernel to not change is wrong, in case they
might change. Of course, in practice kernel doesn't allow the device
to ever change its type, but the type property of the NMDeviceTun
should not make that assumption, because, if it actually changes, what
would it mean?
- note that as of now, new netlink API is not yet merged to mainline Linus
tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API
for now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457
[2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818
https://bugzilla.redhat.com/show_bug.cgi?id=1547213
https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
|
|
|
int ifindex,
|
|
|
|
|
NMPlatformLnkTun *out_properties);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
gboolean
|
2021-03-03 17:32:50 +01:00
|
|
|
nm_platform_wifi_get_capabilities(NMPlatform *self, int ifindex, _NMDeviceWifiCapabilities *caps);
|
2021-03-03 20:57:01 +01:00
|
|
|
guint32 nm_platform_wifi_get_frequency(NMPlatform *self, int ifindex);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_wifi_get_station(NMPlatform *self,
|
2021-03-03 20:57:01 +01:00
|
|
|
int ifindex,
|
|
|
|
|
NMEtherAddr *out_bssid,
|
2021-11-09 13:28:54 +01:00
|
|
|
int *out_quality,
|
|
|
|
|
guint32 *out_rate);
|
2021-03-03 20:57:01 +01:00
|
|
|
_NM80211Mode nm_platform_wifi_get_mode(NMPlatform *self, int ifindex);
|
|
|
|
|
void nm_platform_wifi_set_mode(NMPlatform *self, int ifindex, _NM80211Mode mode);
|
|
|
|
|
void nm_platform_wifi_set_powersave(NMPlatform *self, int ifindex, guint32 powersave);
|
2023-03-21 18:05:03 +01:00
|
|
|
guint32
|
|
|
|
|
nm_platform_wifi_find_frequency(NMPlatform *self, int ifindex, const guint32 *freqs, gboolean ap);
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
void nm_platform_wifi_indicate_addressing_running(NMPlatform *self, int ifindex, gboolean running);
|
2021-03-03 08:51:38 +01:00
|
|
|
_NMSettingWirelessWakeOnWLan nm_platform_wifi_get_wake_on_wlan(NMPlatform *self, int ifindex);
|
2018-05-25 17:43:54 +02:00
|
|
|
gboolean
|
2021-03-03 08:51:38 +01:00
|
|
|
nm_platform_wifi_set_wake_on_wlan(NMPlatform *self, int ifindex, _NMSettingWirelessWakeOnWLan wowl);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
guint32 nm_platform_mesh_get_channel(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean nm_platform_mesh_set_channel(NMPlatform *self, int ifindex, guint32 channel);
|
|
|
|
|
gboolean nm_platform_mesh_set_ssid(NMPlatform *self, int ifindex, const guint8 *ssid, gsize len);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
guint16 nm_platform_wpan_get_pan_id(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean nm_platform_wpan_set_pan_id(NMPlatform *self, int ifindex, guint16 pan_id);
|
|
|
|
|
guint16 nm_platform_wpan_get_short_addr(NMPlatform *self, int ifindex);
|
|
|
|
|
gboolean nm_platform_wpan_set_short_addr(NMPlatform *self, int ifindex, guint16 short_addr);
|
|
|
|
|
gboolean nm_platform_wpan_set_channel(NMPlatform *self, int ifindex, guint8 page, guint8 channel);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-03-29 17:14:33 +02:00
|
|
|
const NMPObject *nm_platform_ip_address_get(NMPlatform *self,
|
|
|
|
|
int addr_family,
|
|
|
|
|
int ifindex,
|
|
|
|
|
gconstpointer /* (NMPlatformIPAddress *) */ needle);
|
|
|
|
|
|
2016-04-06 18:04:26 +02:00
|
|
|
const NMPlatformIP4Address *nm_platform_ip4_address_get(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
in_addr_t address,
|
|
|
|
|
guint8 plen,
|
|
|
|
|
in_addr_t peer_address);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-09-20 12:46:06 +02:00
|
|
|
const NMPlatformIP6Address *
|
|
|
|
|
nm_platform_ip6_address_get(NMPlatform *self, int ifindex, const struct in6_addr *address);
|
|
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int nm_platform_link_sit_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
const NMPlatformLnkSit *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link);
|
|
|
|
|
int nm_platform_link_tun_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
const NMPlatformLnkTun *props,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLink **out_link,
|
|
|
|
|
int *out_fd);
|
2018-05-22 11:50:05 +02:00
|
|
|
gboolean nm_platform_link_6lowpan_get_properties(NMPlatform *self, int ifindex, int *out_parent);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-05-22 11:50:05 +02:00
|
|
|
int
|
2018-12-25 18:41:28 +01:00
|
|
|
nm_platform_link_wireguard_add(NMPlatform *self, const char *name, const NMPlatformLink **out_link);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int nm_platform_link_wireguard_change(NMPlatform *self,
|
2018-12-25 18:41:28 +01:00
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
const NMPlatformLnkWireGuard *lnk_wireguard,
|
|
|
|
|
const struct _NMPWireGuardPeer *peers,
|
2019-02-11 11:07:06 +01:00
|
|
|
const NMPlatformWireGuardChangePeerFlags *peer_flags,
|
2019-01-13 14:21:59 +01:00
|
|
|
guint peers_len,
|
2019-02-10 15:22:26 +01:00
|
|
|
NMPlatformWireGuardChangeFlags change_flags);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-11-29 13:10:39 +01:00
|
|
|
gboolean nm_platform_object_delete(NMPlatform *self, const NMPObject *route);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-10-10 19:58:59 +02:00
|
|
|
gboolean nm_platform_ip4_address_add(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
in_addr_t address,
|
2016-04-06 18:04:26 +02:00
|
|
|
guint8 plen,
|
2015-10-10 19:58:59 +02:00
|
|
|
in_addr_t peer_address,
|
platform: track IFA_BROADCAST address in NMPlatformIP4Address
- track the broadcast address in NMPlatformIP4Address. For addresses
that we receive from kernel and that we cache in NMPlatform, this
allows us to show the additional information. For example, we
can see it in debug logging.
- when setting the address, we still mostly generate our default
broadcast address. This is done in the only relevant caller
nm_platform_ip4_address_sync(). Basically, we merely moved setting
the broadcast address to the caller.
That is, because no callers explicitly set the "use_ip4_broadcast_address"
flag (yet). However, in the future some caller might want to set an explicit
broadcast address.
In practice, we currently don't support configuring special broadcast
addresses in NetworkManager. Instead, we always add the default one with
"address|~netmask" (for plen < 31).
Note that a main point of IFA_BROADCAST is to add a broadcast route to
the local table. Also note that kernel anyway will add such a
"address|~netmask" route, that is regardless whether IFA_BROADCAST is
set or not. Hence, setting it or not makes very little difference for
normal broadcast addresses -- because kernel tends to add this route either
way. It would make a difference if NetworkManager configured an unusual
IFA_BROADCAST address or an address for prefixes >= 31 (in which cases
kernel wouldn't add them automatically). But we don't do that at the
moment.
So, while what NM does has little effect in practice, it still seems
more correct to add the broadcast address, only so that you see it in
`ip addr show`.
2020-01-10 08:11:37 +01:00
|
|
|
in_addr_t broadcast_address,
|
2015-10-10 19:58:59 +02:00
|
|
|
guint32 lifetime,
|
|
|
|
|
guint32 preferred_lft,
|
2016-02-29 17:06:21 +01:00
|
|
|
guint32 flags,
|
2023-02-17 12:07:05 +01:00
|
|
|
const char *label,
|
|
|
|
|
char **out_extack_msg);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_ip6_address_add(NMPlatform *self,
|
2015-10-10 19:58:59 +02:00
|
|
|
int ifindex,
|
|
|
|
|
struct in6_addr address,
|
2016-04-06 18:04:26 +02:00
|
|
|
guint8 plen,
|
2015-10-10 19:58:59 +02:00
|
|
|
struct in6_addr peer_address,
|
|
|
|
|
guint32 lifetime,
|
|
|
|
|
guint32 preferred_lft,
|
2023-02-17 12:07:05 +01:00
|
|
|
guint32 flags,
|
|
|
|
|
char **out_extack_msg);
|
2016-04-06 18:04:26 +02:00
|
|
|
gboolean nm_platform_ip4_address_delete(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
in_addr_t address,
|
|
|
|
|
guint8 plen,
|
|
|
|
|
in_addr_t peer_address);
|
|
|
|
|
gboolean
|
|
|
|
|
nm_platform_ip6_address_delete(NMPlatform *self, int ifindex, struct in6_addr address, guint8 plen);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-03-28 22:26:15 +02:00
|
|
|
static inline gboolean
|
|
|
|
|
nm_platform_ip_address_delete(NMPlatform *self,
|
|
|
|
|
int addr_family,
|
|
|
|
|
int ifindex,
|
|
|
|
|
gconstpointer /* (const NMPlatformIPAddress *) */ addr)
|
|
|
|
|
{
|
|
|
|
|
if (NM_IS_IPv4(addr_family)) {
|
|
|
|
|
const NMPlatformIP4Address *a = addr;
|
|
|
|
|
|
|
|
|
|
if (ifindex <= 0)
|
|
|
|
|
ifindex = a->ifindex;
|
|
|
|
|
|
|
|
|
|
return nm_platform_ip4_address_delete(self, ifindex, a->address, a->plen, a->peer_address);
|
|
|
|
|
} else {
|
|
|
|
|
const NMPlatformIP6Address *a = addr;
|
|
|
|
|
|
|
|
|
|
if (ifindex <= 0)
|
|
|
|
|
ifindex = a->ifindex;
|
|
|
|
|
|
|
|
|
|
return nm_platform_ip6_address_delete(self, ifindex, a->address, a->plen);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-08 09:28:28 +02:00
|
|
|
typedef enum {
|
|
|
|
|
NMP_IP_ADDRESS_SYNC_FLAGS_NONE = 0,
|
|
|
|
|
NMP_IP_ADDRESS_SYNC_FLAGS_WITH_NOPREFIXROUTE = (1 << 0),
|
|
|
|
|
} NMPIPAddressSyncFlags;
|
|
|
|
|
|
|
|
|
|
gboolean nm_platform_ip_address_sync(NMPlatform *self,
|
|
|
|
|
int addr_family,
|
|
|
|
|
int ifindex,
|
|
|
|
|
GPtrArray *known_addresses,
|
|
|
|
|
GPtrArray *addresses_prune,
|
|
|
|
|
NMPIPAddressSyncFlags flags);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
l3cfg: fix clearing IPv6 temporary addresses to avoid stale addresses
IPv6 temporary addresses are configured by kernel, with the
"ipv6.ip6-privacy" setting ("use_tempaddr" sysctl) and the
IFA_F_MANAGETEMPADDR flag.
As such, the idea was that during reapply we would not remove them.
However, that is wrong.
The only case when we want to keep those addresses, is if during reapply
we are going to configure the same primary address (with mngtmpaddr
flag) again. Otherwise, theses addresses must always go away.
This is quite serious. This not only affects Reapply. Also during disconnect
we clear IP configuration via l3cfg.
Have an ethernet profile active with "ipv6.ip6-privacy". Unplug
the cable, the device disconnects but the temporary IPv6 address is not
cleared. As such, nm_device_generate_connection() will now generate
an external profile (with "ipv6.method=disabled" and no manual IP addresses).
The result is, that the device cannot properly autoconnect again,
once you replug the cable.
This is serious for disconnect. But I could not actually reproduce the
problem using reapply. That is, because during reapply we usually
toggle ipv6_disable sysctl, which drops all IPv6 addresses. I still
went through the effort of trying to preserve addresses that we still
want to have, because I am not sure whether there are cases where we
don't toggle ipv6_disable. Also, doing ipv6_disable during reapply is
bad anyway, and we might want to avoid that in the future.
Fixes: 58287cbcc0c8 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
2022-05-05 10:22:20 +02:00
|
|
|
GPtrArray *
|
|
|
|
|
nm_platform_ip_address_get_prune_list(NMPlatform *self,
|
|
|
|
|
int addr_family,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const struct in6_addr *ipv6_temporary_addr_prefixes_keep,
|
|
|
|
|
guint ipv6_temporary_addr_prefixes_keep_len);
|
2020-07-29 12:46:21 +02:00
|
|
|
|
2017-08-14 18:13:10 +02:00
|
|
|
gboolean nm_platform_ip_address_flush(NMPlatform *self, int addr_family, int ifindex);
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
|
2017-08-17 13:37:21 +02:00
|
|
|
void nm_platform_ip_route_normalize(int addr_family, NMPlatformIPRoute *route);
|
|
|
|
|
|
platform: add flags to NMPlatformIP[46]Route to allow overriding the route table and metric
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
2020-09-23 13:38:39 +02:00
|
|
|
static inline guint32
|
|
|
|
|
nm_platform_ip4_route_get_effective_metric(const NMPlatformIP4Route *r)
|
|
|
|
|
{
|
|
|
|
|
nm_assert(r);
|
|
|
|
|
|
2020-10-26 16:47:13 +01:00
|
|
|
return r->metric_any ? nm_add_clamped_u32(NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP4, r->metric)
|
2020-10-22 10:29:03 +02:00
|
|
|
: r->metric;
|
platform: add flags to NMPlatformIP[46]Route to allow overriding the route table and metric
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
2020-09-23 13:38:39 +02:00
|
|
|
}
|
|
|
|
|
|
2022-09-15 14:03:51 +02:00
|
|
|
static inline guint
|
|
|
|
|
nm_platform_ip4_route_get_n_nexthops(const NMPlatformIP4Route *r)
|
|
|
|
|
{
|
|
|
|
|
/* The first hop of the "n_nexthops" is in NMPlatformIP4Route
|
|
|
|
|
* itself. Thus, if the caller only sets ifindex and leaves
|
|
|
|
|
* n_nexthops at zero, the number of next hops is still 1
|
|
|
|
|
* (for convenience of the user who wants to initialize a
|
|
|
|
|
* single hop route). */
|
|
|
|
|
if (r->n_nexthops >= 1) {
|
|
|
|
|
nm_assert(r->ifindex > 0);
|
|
|
|
|
return r->n_nexthops;
|
|
|
|
|
}
|
|
|
|
|
if (r->ifindex > 0)
|
|
|
|
|
return 1;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
platform: add flags to NMPlatformIP[46]Route to allow overriding the route table and metric
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
2020-09-23 13:38:39 +02:00
|
|
|
static inline guint32
|
|
|
|
|
nm_platform_ip6_route_get_effective_metric(const NMPlatformIP6Route *r)
|
|
|
|
|
{
|
|
|
|
|
nm_assert(r);
|
|
|
|
|
|
2020-10-26 16:47:13 +01:00
|
|
|
return r->metric_any ? nm_add_clamped_u32(NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP6, r->metric)
|
2020-10-22 10:29:03 +02:00
|
|
|
: r->metric;
|
platform: add flags to NMPlatformIP[46]Route to allow overriding the route table and metric
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
2020-09-23 13:38:39 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline guint32
|
|
|
|
|
nm_platform_ip_route_get_effective_table(const NMPlatformIPRoute *r)
|
|
|
|
|
{
|
|
|
|
|
nm_assert(r);
|
|
|
|
|
nm_assert(!r->table_any || r->table_coerced == 0);
|
|
|
|
|
|
|
|
|
|
return r->table_any ? 254u /* RT_TABLE_MAIN */
|
|
|
|
|
: nm_platform_route_table_uncoerce(r->table_coerced, TRUE);
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-28 08:09:12 +02:00
|
|
|
static inline gconstpointer
|
|
|
|
|
nm_platform_ip_route_get_gateway(int addr_family, const NMPlatformIPRoute *route)
|
|
|
|
|
{
|
|
|
|
|
nm_assert_addr_family(addr_family);
|
2021-10-30 09:44:32 +02:00
|
|
|
|
|
|
|
|
if (!route)
|
|
|
|
|
return NULL;
|
2020-07-28 08:09:12 +02:00
|
|
|
|
|
|
|
|
if (NM_IS_IPv4(addr_family))
|
|
|
|
|
return &((NMPlatformIP4Route *) route)->gateway;
|
|
|
|
|
return &((NMPlatformIP6Route *) route)->gateway;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-30 15:54:18 -05:00
|
|
|
static inline const NMIPAddrTyped *
|
|
|
|
|
nm_platform_ip4_route_get_via(const NMPlatformIP4Route *route)
|
|
|
|
|
{
|
|
|
|
|
nm_assert(route);
|
|
|
|
|
|
|
|
|
|
return &route->via;
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-09 10:55:41 +01:00
|
|
|
static inline gconstpointer
|
|
|
|
|
nm_platform_ip_route_get_pref_src(int addr_family, const NMPlatformIPRoute *route)
|
|
|
|
|
{
|
|
|
|
|
nm_assert_addr_family(addr_family);
|
|
|
|
|
|
|
|
|
|
if (!route)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
if (NM_IS_IPv4(addr_family))
|
|
|
|
|
return &((NMPlatformIP4Route *) route)->pref_src;
|
|
|
|
|
return &((NMPlatformIP6Route *) route)->pref_src;
|
|
|
|
|
}
|
|
|
|
|
|
2023-02-17 12:07:05 +01:00
|
|
|
int nm_platform_ip_route_add(NMPlatform *self,
|
|
|
|
|
NMPNlmFlags flags,
|
|
|
|
|
const NMPObject *route,
|
|
|
|
|
char **out_extack_msg);
|
2022-10-18 18:53:46 +02:00
|
|
|
int nm_platform_ip4_route_add(NMPlatform *self,
|
|
|
|
|
NMPNlmFlags flags,
|
|
|
|
|
const NMPlatformIP4Route *route,
|
|
|
|
|
const NMPlatformIP4RtNextHop *extra_nexthops);
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int nm_platform_ip6_route_add(NMPlatform *self, NMPNlmFlags flags, const NMPlatformIP6Route *route);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
GPtrArray *nm_platform_ip_route_get_prune_list(NMPlatform *self,
|
core: inject route list to delete for nm_platform_ip_route_sync()
Whenever we call a platform operation that reads or writes the netlink
socket, there is the possibility that the cache gets updated, as we
receive netlink events.
It is thus racy, if nm_platform_ip_route_sync() *first* adds routes, and
then obtains a list of routes to delete. The correct approach is to
determine which routes to delete first (and keep it in a list
@routes_prune), and pass that list down to nm_platform_ip_route_sync().
Arguably, this doesn't yet solve every race. For example, NMDevice
calls update_ext_ip_config() during ip4_config_merge_and_apply().
That is good, as it resyncs with platform. However, before calling
nm_ip4_config_commit() it calls other platform operations, like
_commit_mtu(). So, the race is still there.
2017-09-22 12:37:12 +02:00
|
|
|
int addr_family,
|
2017-09-13 17:42:41 +02:00
|
|
|
int ifindex,
|
2024-11-27 13:53:02 +01:00
|
|
|
NMIPRouteTableSyncMode route_table_sync,
|
|
|
|
|
GPtrArray *old_routes_objs);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
platform: add non-exclusive routes and drop route-manager
Previously, we would add exclusive routes via netlink message flags
NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`.
Using that form of RTM_NEWROUTE message, we could only add a certain
route with a certain network/plen,metric triple once. That was already
hugely inconvenient, because
- when configuring routes, multiple (managed) interfaces may get
conflicting routes (multihoming). Only one of the routes can be actually
configured using `ip route replace`, so we need to track routes that are
currently shadowed.
- when configuring routes, we might replace externally configured
routes on unmanaged interfaces. We should not interfere with such
routes.
That was worked around by having NMRouteManager (and NMDefaultRouteManager).
NMRouteManager would keep a list of the routes which NetworkManager would like
to configure, even if momentarily being unable to do so due to conflicting routes.
This worked mostly well but was complicated. It involved bumping metrics to
avoid conflicts for device routes, as we might require them for gateway routes.
Drop that now. Instead, use the corresponding of `ip route append` to configure
routes. This allows NetworkManager to confiure (almost) all routes that we care.
Especially, it can configure all routes on a managed interface, without
replacing/interfering with routes on other interfaces. Hence, NMRouteManager
becomes obsolete.
It practice it is a bit more complicated because:
- when adding an IPv4 address, kernel will automatically create a device route
for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for
IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4
addresses yet (and we don't require such a kernel yet), we still need functionality
similar to nm_route_manager_ip4_route_register_device_route_purge_list().
This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set().
- trying to configure an IPv6 route with a source address will be rejected
by kernel as long as the address is tentative (see related bug rh#1457196).
Preferably, NMDevice would keep the list of routes which should be configured,
while kernel would have the list of what actually is configured. There is a
feed-back loop where both affect each other (for example, when externally deleting
a route, NMDevice must forget about it too). Previously, NMRouteManager would have
the task of remembering all routes which we currently want to configure, but cannot
due to conflicting routes.
We get rid of that, because now we configure non-exclusive routes. We however still
will need to remember IPv6 routes with a source address, that currently cannot be
configured yet. Hence, we will need to keep track of routes that
currently cannot be configured, but later may be.
That is still not done yet, as NMRouteManager didn't handle this
correctly either.
2017-08-14 14:18:53 +02:00
|
|
|
gboolean nm_platform_ip_route_sync(NMPlatform *self,
|
|
|
|
|
int addr_family,
|
|
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
GPtrArray *routes,
|
|
|
|
|
GPtrArray *routes_prune,
|
platform: rework handling of failed routes during nm_platform_ip_route_sync()
Previously, there was "temporary-not-available" mechanism in NML3Cfg,
which aimed to handle IPv6 routes with prefsrc. Theoretically, that
mechanism may have been extended to other use-cases, like IPv4 routes
with prefsrc. What it attempted to handle, is the inability to configure
such routes, unless the respective prefsrc address is configured and
non-tentative. However, the address that we are waiting for, could also
be on another interface, so that mechanism wasn't applicable. This is
now replaced by _routes_watch_ip_addrs(). It seems there isn't anything
useful left for the "temporary-not-available" mechanism and it can go,
except...
We want to log a warning when we are unable to configure a route. Also,
in the future we might want to know when the IP configuration is
degradated due to inability to configure the desired routes (a condition
that we might want to expose to the user, not only via logging; or we
may want to react on that).
However, with prefsrc routes we don't know right away whether the
inability to configure the route right away indicates an actual problem,
or whether that will resolve itself (e.g. after the address passes
DAD/ACD, after we received an DHCP lease or after the address was
configured on another interface). Consequently, to know whether the
current inability to configure such a route is a problem, we need to
know the larger context. nm_platform_ip_route_sync() does not have that
context.
Instead, nm_platform_ip_route_sync() needs only do debug log about
failure to configure routes. It will now also return all the failed
routes to NML3Cfg, which can decide whether that is a problem.
This reworks the previous "temporary-not-available" mechanism to track
the state of the failed routes, to eventually decide whether there is an
actual problem (and log about it).
Another problem this solves is that since commit ('platform: always
reconfigure IP routes even if removed externally'), we will eagerly
re-try to configure the same route over and over. We cannot just spam
the log with warnings about the same failure on every commit. We need to
remember that we already logged about the problem and rate limit
warnings otherwise. This is what the new mechanism also achieves.
Indeed, all this is mostly for the sole benefit of logging better
warnings (and not duplicated).
2023-03-08 16:08:23 +01:00
|
|
|
GPtrArray **out_routes_failed);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
platform: add non-exclusive routes and drop route-manager
Previously, we would add exclusive routes via netlink message flags
NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`.
Using that form of RTM_NEWROUTE message, we could only add a certain
route with a certain network/plen,metric triple once. That was already
hugely inconvenient, because
- when configuring routes, multiple (managed) interfaces may get
conflicting routes (multihoming). Only one of the routes can be actually
configured using `ip route replace`, so we need to track routes that are
currently shadowed.
- when configuring routes, we might replace externally configured
routes on unmanaged interfaces. We should not interfere with such
routes.
That was worked around by having NMRouteManager (and NMDefaultRouteManager).
NMRouteManager would keep a list of the routes which NetworkManager would like
to configure, even if momentarily being unable to do so due to conflicting routes.
This worked mostly well but was complicated. It involved bumping metrics to
avoid conflicts for device routes, as we might require them for gateway routes.
Drop that now. Instead, use the corresponding of `ip route append` to configure
routes. This allows NetworkManager to confiure (almost) all routes that we care.
Especially, it can configure all routes on a managed interface, without
replacing/interfering with routes on other interfaces. Hence, NMRouteManager
becomes obsolete.
It practice it is a bit more complicated because:
- when adding an IPv4 address, kernel will automatically create a device route
for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for
IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4
addresses yet (and we don't require such a kernel yet), we still need functionality
similar to nm_route_manager_ip4_route_register_device_route_purge_list().
This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set().
- trying to configure an IPv6 route with a source address will be rejected
by kernel as long as the address is tentative (see related bug rh#1457196).
Preferably, NMDevice would keep the list of routes which should be configured,
while kernel would have the list of what actually is configured. There is a
feed-back loop where both affect each other (for example, when externally deleting
a route, NMDevice must forget about it too). Previously, NMRouteManager would have
the task of remembering all routes which we currently want to configure, but cannot
due to conflicting routes.
We get rid of that, because now we configure non-exclusive routes. We however still
will need to remember IPv6 routes with a source address, that currently cannot be
configured yet. Hence, we will need to keep track of routes that
currently cannot be configured, but later may be.
That is still not done yet, as NMRouteManager didn't handle this
correctly either.
2017-08-14 14:18:53 +02:00
|
|
|
gboolean nm_platform_ip_route_flush(NMPlatform *self, int addr_family, int ifindex);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int nm_platform_ip_route_get(NMPlatform *self,
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int addr_family,
|
|
|
|
|
gconstpointer address,
|
2024-09-03 14:47:58 +02:00
|
|
|
guint32 fwmark,
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int oif_ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
NMPObject **out_route);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int nm_platform_routing_rule_add(NMPlatform *self,
|
2019-03-05 12:13:04 +01:00
|
|
|
NMPNlmFlags flags,
|
|
|
|
|
const NMPlatformRoutingRule *routing_rule);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-09-14 17:46:02 +02:00
|
|
|
int nm_platform_qdisc_add(NMPlatform *self, NMPNlmFlags flags, const NMPlatformQdisc *qdisc);
|
|
|
|
|
int nm_platform_qdisc_delete(NMPlatform *self, int ifindex, guint32 parent, gboolean log_error);
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int nm_platform_tfilter_add(NMPlatform *self, NMPNlmFlags flags, const NMPlatformTfilter *tfilter);
|
2021-09-14 17:46:02 +02:00
|
|
|
int nm_platform_tfilter_delete(NMPlatform *self, int ifindex, guint32 parent, gboolean log_error);
|
2021-09-14 17:48:09 +02:00
|
|
|
gboolean nm_platform_tc_sync(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
GPtrArray *known_qdiscs,
|
|
|
|
|
GPtrArray *known_tfilters);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
const char *nm_platform_link_to_string(const NMPlatformLink *link, char *buf, gsize len);
|
2022-07-25 16:01:35 +02:00
|
|
|
const char *nm_platform_lnk_bond_to_string(const NMPlatformLnkBond *lnk, char *buf, gsize len);
|
2015-10-12 10:27:33 +02:00
|
|
|
const char *nm_platform_lnk_bridge_to_string(const NMPlatformLnkBridge *lnk, char *buf, gsize len);
|
2020-08-05 13:46:28 -04:00
|
|
|
const char *nm_platform_lnk_gre_to_string(const NMPlatformLnkGre *lnk, char *buf, gsize len);
|
2023-10-27 14:01:13 +02:00
|
|
|
const char *nm_platform_lnk_hsr_to_string(const NMPlatformLnkHsr *lnk, char *buf, gsize len);
|
2015-10-12 15:15:21 +02:00
|
|
|
const char *
|
2015-10-15 15:47:14 +02:00
|
|
|
nm_platform_lnk_infiniband_to_string(const NMPlatformLnkInfiniband *lnk, char *buf, gsize len);
|
2015-11-27 22:22:25 +01:00
|
|
|
const char *nm_platform_lnk_ip6tnl_to_string(const NMPlatformLnkIp6Tnl *lnk, char *buf, gsize len);
|
2015-11-27 14:01:56 +01:00
|
|
|
const char *nm_platform_lnk_ipip_to_string(const NMPlatformLnkIpIp *lnk, char *buf, gsize len);
|
2016-06-30 18:20:09 +02:00
|
|
|
const char *nm_platform_lnk_macsec_to_string(const NMPlatformLnkMacsec *lnk, char *buf, gsize len);
|
2015-10-12 15:15:21 +02:00
|
|
|
const char *
|
|
|
|
|
nm_platform_lnk_macvlan_to_string(const NMPlatformLnkMacvlan *lnk, char *buf, gsize len);
|
2024-09-06 14:14:24 +02:00
|
|
|
const char *nm_platform_lnk_ipvlan_to_string(const NMPlatformLnkIpvlan *lnk, char *buf, gsize len);
|
2015-11-11 18:41:48 +01:00
|
|
|
const char *nm_platform_lnk_sit_to_string(const NMPlatformLnkSit *lnk, char *buf, gsize len);
|
core/platform: add support for TUN/TAP netlink support and various cleanup
Kernel recently got support for exposing TUN/TAP information on netlink
[1], [2], [3]. Add support for it to the platform cache.
The advantage of using netlink is that querying sysctl bypasses the
order of events of the netlink socket. It is out of sync and racy. For
example, platform cache might still think that a tun device exists, but
a subsequent lookup at sysfs might fail because the device was deleted
in the meantime. Another point is, that we don't get change
notifications via sysctl and that it requires various extra syscalls
to read the device information. If the tun information is present on
netlink, put it into the cache. This bypasses checking sysctl while
we keep looking at sysctl for backward compatibility until we require
support from kernel.
Notes:
- we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This
deviates from the model of how kernel treats TUN/TAP devices, which
makes it more complicated. The link type of a NMPlatformLink instance
should match what kernel thinks about the device. Point in case,
when parsing RTM_NETLINK messages, we very early need to determine
the link type (_linktype_get_type()). However, to determine the
type of a TUN/TAP at that point, we need to look into nested
netlink attributes which in turn depend on the type (IFLA_INFO_KIND
and IFLA_INFO_DATA), or even worse, we would need to look into
sysctl for older kernel vesions. Now, the TUN/TAP type is a property
of the link type NM_LINK_TYPE_TUN, instead of determining two
different link types.
- various parts of the API (both kernel's sysctl vs. netlink) and
NMDeviceTun vs. NMSettingTun disagree whether the PI is positive
(NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted
(NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way,
but prefer the positive form for internal API at NMPlatformLnkTun.pi.
- previously NMDeviceTun.mode could not change after initializing
the object. Allow for that to happen, because forcing some properties
that are reported by kernel to not change is wrong, in case they
might change. Of course, in practice kernel doesn't allow the device
to ever change its type, but the type property of the NMDeviceTun
should not make that assumption, because, if it actually changes, what
would it mean?
- note that as of now, new netlink API is not yet merged to mainline Linus
tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API
for now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457
[2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818
https://bugzilla.redhat.com/show_bug.cgi?id=1547213
https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
|
|
|
const char *nm_platform_lnk_tun_to_string(const NMPlatformLnkTun *lnk, char *buf, gsize len);
|
2015-10-12 13:44:44 +02:00
|
|
|
const char *nm_platform_lnk_vlan_to_string(const NMPlatformLnkVlan *lnk, char *buf, gsize len);
|
2019-12-05 10:35:25 +01:00
|
|
|
const char *nm_platform_lnk_vrf_to_string(const NMPlatformLnkVrf *lnk, char *buf, gsize len);
|
2022-10-24 10:17:09 +02:00
|
|
|
const char *nm_platform_lnk_vti_to_string(const NMPlatformLnkVti *lnk, char *buf, gsize len);
|
2022-10-25 08:31:47 +02:00
|
|
|
const char *nm_platform_lnk_vti6_to_string(const NMPlatformLnkVti6 *lnk, char *buf, gsize len);
|
2015-10-12 15:15:21 +02:00
|
|
|
const char *nm_platform_lnk_vxlan_to_string(const NMPlatformLnkVxlan *lnk, char *buf, gsize len);
|
2018-07-28 14:54:33 +02:00
|
|
|
const char *
|
|
|
|
|
nm_platform_lnk_wireguard_to_string(const NMPlatformLnkWireGuard *lnk, char *buf, gsize len);
|
2022-09-15 14:03:51 +02:00
|
|
|
|
|
|
|
|
const char *nm_platform_ip4_route_to_string_full(const NMPlatformIP4Route *route,
|
|
|
|
|
const NMPlatformIP4RtNextHop *extra_nexthops,
|
|
|
|
|
char *buf,
|
|
|
|
|
gsize len);
|
|
|
|
|
|
|
|
|
|
static inline const char *
|
|
|
|
|
nm_platform_ip4_route_to_string(const NMPlatformIP4Route *route, char *buf, gsize len)
|
|
|
|
|
{
|
|
|
|
|
return nm_platform_ip4_route_to_string_full(route, NULL, buf, len);
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-12 10:27:33 +02:00
|
|
|
const char *nm_platform_ip6_route_to_string(const NMPlatformIP6Route *route, char *buf, gsize len);
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
const char *
|
|
|
|
|
nm_platform_routing_rule_to_string(const NMPlatformRoutingRule *routing_rule, char *buf, gsize len);
|
2017-11-15 20:36:35 +01:00
|
|
|
const char *nm_platform_qdisc_to_string(const NMPlatformQdisc *qdisc, char *buf, gsize len);
|
2017-11-15 20:36:35 +01:00
|
|
|
const char *nm_platform_tfilter_to_string(const NMPlatformTfilter *tfilter, char *buf, gsize len);
|
2018-05-23 14:33:24 +02:00
|
|
|
const char *nm_platform_vf_to_string(const NMPlatformVF *vf, char *buf, gsize len);
|
2019-03-16 17:22:35 +01:00
|
|
|
const char *
|
|
|
|
|
nm_platform_bridge_vlan_to_string(const NMPlatformBridgeVlan *vlan, char *buf, gsize len);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *nm_platform_vlan_qos_mapping_to_string(const char *name,
|
2015-10-27 16:14:54 +01:00
|
|
|
const NMVlanQosMapping *map,
|
|
|
|
|
gsize n_map,
|
2021-11-09 13:28:54 +01:00
|
|
|
char *buf,
|
2015-10-27 16:14:54 +01:00
|
|
|
gsize len);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
platform/wireguard: rework parsing wireguard links in platform
- previously, parsing wireguard genl data resulted in memory corruption:
- _wireguard_update_from_allowedips_nla() takes pointers to
allowedip = &g_array_index (buf->allowedips, NMWireGuardAllowedIP, buf->allowedips->len - 1);
but resizing the GArray will invalidate this pointer. This happens
when there are multiple allowed-ips to parse.
- there was some confusion who owned the allowedips pointers.
_wireguard_peers_cpy() and _vt_cmd_obj_dispose_lnk_wireguard()
assumed each peer owned their own chunk, but _wireguard_get_link_properties()
would not duplicate the memory properly.
- rework memory handling for allowed_ips. Now, the NMPObjectLnkWireGuard
keeps a pointer _allowed_ips_buf. This buffer contains the instances for
all peers.
The parsing of the netlink message is the complicated part, because
we don't know upfront how many peers/allowed-ips we receive. During
construction, the tracking of peers/allowed-ips is complicated,
via a CList/GArray. At the end of that, we prettify the data
representation and put everything into two buffers. That is more
efficient and simpler for user afterwards. This moves complexity
to the way how the object is created, vs. how it is used later.
- ensure that we nm_explicit_bzero() private-key and preshared-key. However,
that only works to a certain point, because our netlink library does not
ensure that no data is leaked.
- don't use a "struct sockaddr" union for the peer's endpoint. Instead,
use a combintation of endpoint_family, endpoint_port, and
endpoint_addr.
- a lot of refactoring.
2018-09-07 09:54:07 +02:00
|
|
|
const char *
|
|
|
|
|
nm_platform_wireguard_peer_to_string(const struct _NMPWireGuardPeer *peer, char *buf, gsize len);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-07-13 16:24:05 +02:00
|
|
|
const char *
|
|
|
|
|
nm_platform_mptcp_addr_to_string(const NMPlatformMptcpAddr *mptcp_addr, char *buf, gsize len);
|
|
|
|
|
|
2014-04-05 18:35:20 +02:00
|
|
|
int nm_platform_link_cmp(const NMPlatformLink *a, const NMPlatformLink *b);
|
2022-07-25 16:01:35 +02:00
|
|
|
int nm_platform_lnk_bond_cmp(const NMPlatformLnkBond *a, const NMPlatformLnkBond *b);
|
2020-08-05 13:46:28 -04:00
|
|
|
int nm_platform_lnk_bridge_cmp(const NMPlatformLnkBridge *a, const NMPlatformLnkBridge *b);
|
2015-10-12 15:15:21 +02:00
|
|
|
int nm_platform_lnk_gre_cmp(const NMPlatformLnkGre *a, const NMPlatformLnkGre *b);
|
2023-10-27 14:01:13 +02:00
|
|
|
int nm_platform_lnk_hsr_cmp(const NMPlatformLnkHsr *a, const NMPlatformLnkHsr *b);
|
2015-10-15 15:47:14 +02:00
|
|
|
int nm_platform_lnk_infiniband_cmp(const NMPlatformLnkInfiniband *a,
|
|
|
|
|
const NMPlatformLnkInfiniband *b);
|
2015-11-27 22:22:25 +01:00
|
|
|
int nm_platform_lnk_ip6tnl_cmp(const NMPlatformLnkIp6Tnl *a, const NMPlatformLnkIp6Tnl *b);
|
2015-11-27 14:01:56 +01:00
|
|
|
int nm_platform_lnk_ipip_cmp(const NMPlatformLnkIpIp *a, const NMPlatformLnkIpIp *b);
|
2016-06-30 18:20:09 +02:00
|
|
|
int nm_platform_lnk_macsec_cmp(const NMPlatformLnkMacsec *a, const NMPlatformLnkMacsec *b);
|
2024-09-06 14:14:24 +02:00
|
|
|
int nm_platform_lnk_ipvlan_cmp(const NMPlatformLnkIpvlan *a, const NMPlatformLnkIpvlan *b);
|
2015-10-12 15:15:21 +02:00
|
|
|
int nm_platform_lnk_macvlan_cmp(const NMPlatformLnkMacvlan *a, const NMPlatformLnkMacvlan *b);
|
2015-11-11 18:41:48 +01:00
|
|
|
int nm_platform_lnk_sit_cmp(const NMPlatformLnkSit *a, const NMPlatformLnkSit *b);
|
core/platform: add support for TUN/TAP netlink support and various cleanup
Kernel recently got support for exposing TUN/TAP information on netlink
[1], [2], [3]. Add support for it to the platform cache.
The advantage of using netlink is that querying sysctl bypasses the
order of events of the netlink socket. It is out of sync and racy. For
example, platform cache might still think that a tun device exists, but
a subsequent lookup at sysfs might fail because the device was deleted
in the meantime. Another point is, that we don't get change
notifications via sysctl and that it requires various extra syscalls
to read the device information. If the tun information is present on
netlink, put it into the cache. This bypasses checking sysctl while
we keep looking at sysctl for backward compatibility until we require
support from kernel.
Notes:
- we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This
deviates from the model of how kernel treats TUN/TAP devices, which
makes it more complicated. The link type of a NMPlatformLink instance
should match what kernel thinks about the device. Point in case,
when parsing RTM_NETLINK messages, we very early need to determine
the link type (_linktype_get_type()). However, to determine the
type of a TUN/TAP at that point, we need to look into nested
netlink attributes which in turn depend on the type (IFLA_INFO_KIND
and IFLA_INFO_DATA), or even worse, we would need to look into
sysctl for older kernel vesions. Now, the TUN/TAP type is a property
of the link type NM_LINK_TYPE_TUN, instead of determining two
different link types.
- various parts of the API (both kernel's sysctl vs. netlink) and
NMDeviceTun vs. NMSettingTun disagree whether the PI is positive
(NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted
(NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way,
but prefer the positive form for internal API at NMPlatformLnkTun.pi.
- previously NMDeviceTun.mode could not change after initializing
the object. Allow for that to happen, because forcing some properties
that are reported by kernel to not change is wrong, in case they
might change. Of course, in practice kernel doesn't allow the device
to ever change its type, but the type property of the NMDeviceTun
should not make that assumption, because, if it actually changes, what
would it mean?
- note that as of now, new netlink API is not yet merged to mainline Linus
tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API
for now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457
[2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818
https://bugzilla.redhat.com/show_bug.cgi?id=1547213
https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
|
|
|
int nm_platform_lnk_tun_cmp(const NMPlatformLnkTun *a, const NMPlatformLnkTun *b);
|
2015-10-12 13:44:44 +02:00
|
|
|
int nm_platform_lnk_vlan_cmp(const NMPlatformLnkVlan *a, const NMPlatformLnkVlan *b);
|
2019-12-05 10:35:25 +01:00
|
|
|
int nm_platform_lnk_vrf_cmp(const NMPlatformLnkVrf *a, const NMPlatformLnkVrf *b);
|
2022-10-24 10:17:09 +02:00
|
|
|
int nm_platform_lnk_vti_cmp(const NMPlatformLnkVti *a, const NMPlatformLnkVti *b);
|
2022-10-25 08:31:47 +02:00
|
|
|
int nm_platform_lnk_vti6_cmp(const NMPlatformLnkVti6 *a, const NMPlatformLnkVti6 *b);
|
2015-10-12 15:15:21 +02:00
|
|
|
int nm_platform_lnk_vxlan_cmp(const NMPlatformLnkVxlan *a, const NMPlatformLnkVxlan *b);
|
2018-07-28 14:54:33 +02:00
|
|
|
int nm_platform_lnk_wireguard_cmp(const NMPlatformLnkWireGuard *a, const NMPlatformLnkWireGuard *b);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-08-06 17:45:20 +02:00
|
|
|
GHashTable *nm_platform_ip4_address_addr_to_hash(NMPlatform *self, int ifindex);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2024-11-27 13:53:02 +01:00
|
|
|
void nm_platform_route_objs_sort(GPtrArray *routes_objs, NMPlatformIPRouteCmpType cmp_type);
|
|
|
|
|
|
2017-07-26 10:50:23 +02:00
|
|
|
int nm_platform_ip4_route_cmp(const NMPlatformIP4Route *a,
|
|
|
|
|
const NMPlatformIP4Route *b,
|
|
|
|
|
NMPlatformIPRouteCmpType cmp_type);
|
2022-09-15 14:03:51 +02:00
|
|
|
int nm_platform_ip4_rt_nexthop_cmp(const NMPlatformIP4RtNextHop *a,
|
|
|
|
|
const NMPlatformIP4RtNextHop *b,
|
|
|
|
|
gboolean for_id);
|
2017-07-26 10:50:23 +02:00
|
|
|
int nm_platform_ip6_route_cmp(const NMPlatformIP6Route *a,
|
|
|
|
|
const NMPlatformIP6Route *b,
|
|
|
|
|
NMPlatformIPRouteCmpType cmp_type);
|
2017-04-13 22:34:32 +02:00
|
|
|
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
int nm_platform_routing_rule_cmp(const NMPlatformRoutingRule *a,
|
|
|
|
|
const NMPlatformRoutingRule *b,
|
|
|
|
|
NMPlatformRoutingRuleCmpType cmp_type);
|
|
|
|
|
|
2022-11-21 17:44:07 +01:00
|
|
|
int
|
|
|
|
|
nm_platform_qdisc_cmp(const NMPlatformQdisc *a, const NMPlatformQdisc *b, gboolean compare_handle);
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
int nm_platform_tfilter_cmp(const NMPlatformTfilter *a, const NMPlatformTfilter *b);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-07-13 16:24:05 +02:00
|
|
|
int nm_platform_mptcp_addr_cmp(const NMPlatformMptcpAddr *a, const NMPlatformMptcpAddr *b);
|
|
|
|
|
|
2017-10-17 11:53:08 +02:00
|
|
|
void nm_platform_link_hash_update(const NMPlatformLink *obj, NMHashState *h);
|
2023-03-03 16:36:23 +01:00
|
|
|
void nm_platform_link_bond_port_hash_update(const NMPlatformLinkBondPort *obj, NMHashState *h);
|
2023-06-06 17:32:22 +02:00
|
|
|
void nm_platform_link_bridge_port_hash_update(const NMPlatformLinkBridgePort *obj, NMHashState *h);
|
2023-03-03 16:36:23 +01:00
|
|
|
int nm_platform_link_bond_port_cmp(const NMPlatformLinkBondPort *a,
|
|
|
|
|
const NMPlatformLinkBondPort *b);
|
2023-06-06 17:32:22 +02:00
|
|
|
int nm_platform_link_bridge_port_cmp(const NMPlatformLinkBridgePort *a,
|
|
|
|
|
const NMPlatformLinkBridgePort *b);
|
2017-10-17 11:53:08 +02:00
|
|
|
void nm_platform_ip4_route_hash_update(const NMPlatformIP4Route *obj,
|
|
|
|
|
NMPlatformIPRouteCmpType cmp_type,
|
2021-11-09 13:28:54 +01:00
|
|
|
NMHashState *h);
|
2022-11-08 15:54:48 +01:00
|
|
|
|
|
|
|
|
static inline guint
|
|
|
|
|
nm_platform_ip4_route_hash(const NMPlatformIP4Route *obj, NMPlatformIPRouteCmpType cmp_type)
|
|
|
|
|
{
|
|
|
|
|
NMHashState h;
|
|
|
|
|
|
|
|
|
|
nm_hash_init(&h, 1118769853u);
|
|
|
|
|
nm_platform_ip4_route_hash_update(obj, cmp_type, &h);
|
|
|
|
|
return nm_hash_complete(&h);
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-15 14:03:51 +02:00
|
|
|
void nm_platform_ip4_rt_nexthop_hash_update(const NMPlatformIP4RtNextHop *obj,
|
|
|
|
|
gboolean for_id,
|
|
|
|
|
NMHashState *h);
|
2017-10-17 11:53:08 +02:00
|
|
|
void nm_platform_ip6_route_hash_update(const NMPlatformIP6Route *obj,
|
|
|
|
|
NMPlatformIPRouteCmpType cmp_type,
|
2021-11-09 13:28:54 +01:00
|
|
|
NMHashState *h);
|
platform: add support for routing-rule objects and cache them in platform
Add and implement NMPlatformRoutingRule types and let the platform cache
handle rules.
Rules are special in two ways:
- they don't have an ifindex. That makes them different from all other
currently existing NMPlatform* types, which have an "ifindex" field and
"implement" NMPlatformObjWithIfindex.
- they have an address family, but contrary to addresses and routes, there
is only one NMPlatformRoutingRule object to handle both address
families.
Both of these points require some special considerations.
Kernel treats routing-rules quite similar to routes. That is, kernel
allows to add different rules/routes, as long as they differ in certain
fields. These "fields" make up the identity of the rules/routes. But
in practice, it's not defined which fields contribute to the identity
of these objects. That makes using the netlink API very hard. For
example, when kernel gains support for a new attribute which
NetworkManager does not know yet, then users can add two rules/routes
that look the same to NetworkManager. That can easily result in cache
inconsistencies.
Another problem is, that older kernel versions may not yet support all
fields, which NetworkManager (and newer kernels) considers for identity.
The older kernel will not simply reject netlink messages with these unknown
keys, instead it will proceed adding the route/rule without it. That means,
the added route/rule will have a different identity than what NetworkManager
intended to add.
2019-02-14 13:08:12 +01:00
|
|
|
void nm_platform_routing_rule_hash_update(const NMPlatformRoutingRule *obj,
|
|
|
|
|
NMPlatformRoutingRuleCmpType cmp_type,
|
2021-11-09 13:28:54 +01:00
|
|
|
NMHashState *h);
|
2022-07-25 16:01:35 +02:00
|
|
|
void nm_platform_lnk_bond_hash_update(const NMPlatformLnkBond *obj, NMHashState *h);
|
2020-08-05 13:46:28 -04:00
|
|
|
void nm_platform_lnk_bridge_hash_update(const NMPlatformLnkBridge *obj, NMHashState *h);
|
2017-10-17 11:53:08 +02:00
|
|
|
void nm_platform_lnk_gre_hash_update(const NMPlatformLnkGre *obj, NMHashState *h);
|
2023-10-27 14:01:13 +02:00
|
|
|
void nm_platform_lnk_hsr_hash_update(const NMPlatformLnkHsr *obj, NMHashState *h);
|
2017-10-17 11:53:08 +02:00
|
|
|
void nm_platform_lnk_infiniband_hash_update(const NMPlatformLnkInfiniband *obj, NMHashState *h);
|
|
|
|
|
void nm_platform_lnk_ip6tnl_hash_update(const NMPlatformLnkIp6Tnl *obj, NMHashState *h);
|
|
|
|
|
void nm_platform_lnk_ipip_hash_update(const NMPlatformLnkIpIp *obj, NMHashState *h);
|
|
|
|
|
void nm_platform_lnk_macsec_hash_update(const NMPlatformLnkMacsec *obj, NMHashState *h);
|
|
|
|
|
void nm_platform_lnk_macvlan_hash_update(const NMPlatformLnkMacvlan *obj, NMHashState *h);
|
2024-09-06 14:14:24 +02:00
|
|
|
void nm_platform_lnk_ipvlan_hash_update(const NMPlatformLnkIpvlan *obj, NMHashState *h);
|
2017-10-17 11:53:08 +02:00
|
|
|
void nm_platform_lnk_sit_hash_update(const NMPlatformLnkSit *obj, NMHashState *h);
|
core/platform: add support for TUN/TAP netlink support and various cleanup
Kernel recently got support for exposing TUN/TAP information on netlink
[1], [2], [3]. Add support for it to the platform cache.
The advantage of using netlink is that querying sysctl bypasses the
order of events of the netlink socket. It is out of sync and racy. For
example, platform cache might still think that a tun device exists, but
a subsequent lookup at sysfs might fail because the device was deleted
in the meantime. Another point is, that we don't get change
notifications via sysctl and that it requires various extra syscalls
to read the device information. If the tun information is present on
netlink, put it into the cache. This bypasses checking sysctl while
we keep looking at sysctl for backward compatibility until we require
support from kernel.
Notes:
- we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This
deviates from the model of how kernel treats TUN/TAP devices, which
makes it more complicated. The link type of a NMPlatformLink instance
should match what kernel thinks about the device. Point in case,
when parsing RTM_NETLINK messages, we very early need to determine
the link type (_linktype_get_type()). However, to determine the
type of a TUN/TAP at that point, we need to look into nested
netlink attributes which in turn depend on the type (IFLA_INFO_KIND
and IFLA_INFO_DATA), or even worse, we would need to look into
sysctl for older kernel vesions. Now, the TUN/TAP type is a property
of the link type NM_LINK_TYPE_TUN, instead of determining two
different link types.
- various parts of the API (both kernel's sysctl vs. netlink) and
NMDeviceTun vs. NMSettingTun disagree whether the PI is positive
(NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted
(NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way,
but prefer the positive form for internal API at NMPlatformLnkTun.pi.
- previously NMDeviceTun.mode could not change after initializing
the object. Allow for that to happen, because forcing some properties
that are reported by kernel to not change is wrong, in case they
might change. Of course, in practice kernel doesn't allow the device
to ever change its type, but the type property of the NMDeviceTun
should not make that assumption, because, if it actually changes, what
would it mean?
- note that as of now, new netlink API is not yet merged to mainline Linus
tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API
for now.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457
[2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818
https://bugzilla.redhat.com/show_bug.cgi?id=1547213
https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
|
|
|
void nm_platform_lnk_tun_hash_update(const NMPlatformLnkTun *obj, NMHashState *h);
|
2017-10-17 11:53:08 +02:00
|
|
|
void nm_platform_lnk_vlan_hash_update(const NMPlatformLnkVlan *obj, NMHashState *h);
|
2019-12-05 10:35:25 +01:00
|
|
|
void nm_platform_lnk_vrf_hash_update(const NMPlatformLnkVrf *obj, NMHashState *h);
|
2022-10-24 10:17:09 +02:00
|
|
|
void nm_platform_lnk_vti_hash_update(const NMPlatformLnkVti *obj, NMHashState *h);
|
2022-10-25 08:31:47 +02:00
|
|
|
void nm_platform_lnk_vti6_hash_update(const NMPlatformLnkVti6 *obj, NMHashState *h);
|
2017-10-17 11:53:08 +02:00
|
|
|
void nm_platform_lnk_vxlan_hash_update(const NMPlatformLnkVxlan *obj, NMHashState *h);
|
2018-07-28 14:54:33 +02:00
|
|
|
void nm_platform_lnk_wireguard_hash_update(const NMPlatformLnkWireGuard *obj, NMHashState *h);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
void nm_platform_qdisc_hash_update(const NMPlatformQdisc *obj, NMHashState *h);
|
2017-11-15 20:36:35 +01:00
|
|
|
void nm_platform_tfilter_hash_update(const NMPlatformTfilter *obj, NMHashState *h);
|
2017-11-15 20:36:35 +01:00
|
|
|
|
2022-07-13 16:24:05 +02:00
|
|
|
void nm_platform_mptcp_addr_hash_update(const NMPlatformMptcpAddr *obj, NMHashState *h);
|
|
|
|
|
|
2022-07-27 13:50:43 +02:00
|
|
|
guint nm_platform_mptcp_addr_index_addr_cmp(gconstpointer data);
|
|
|
|
|
gboolean nm_platform_mptcp_addr_index_addr_equal(gconstpointer data_a, gconstpointer data_b);
|
|
|
|
|
|
2024-07-04 12:45:42 +02:00
|
|
|
#define NM_PLATFORM_LINK_FLAGS2STR_MAX_LEN ((gsize) 165)
|
2019-05-30 08:29:19 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_ethtool_set_wake_on_lan(NMPlatform *self,
|
2021-01-08 17:01:45 +01:00
|
|
|
int ifindex,
|
|
|
|
|
_NMSettingWiredWakeOnLan wol,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *wol_password);
|
|
|
|
|
gboolean nm_platform_ethtool_set_link_settings(NMPlatform *self,
|
2016-12-11 22:46:14 +01:00
|
|
|
int ifindex,
|
|
|
|
|
gboolean autoneg,
|
|
|
|
|
guint32 speed,
|
|
|
|
|
NMPlatformLinkDuplexType duplex);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_ethtool_get_link_settings(NMPlatform *self,
|
2016-12-11 22:46:14 +01:00
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean *out_autoneg,
|
|
|
|
|
guint32 *out_speed,
|
2016-12-11 22:46:14 +01:00
|
|
|
NMPlatformLinkDuplexType *out_duplex);
|
2018-07-16 15:42:07 +02:00
|
|
|
|
2025-03-25 11:53:16 +01:00
|
|
|
NMEthtoolFeatureStates *nm_platform_ethtool_get_features(NMPlatform *self, int ifindex);
|
2018-07-16 15:42:07 +02:00
|
|
|
gboolean nm_platform_ethtool_set_features(
|
2021-11-09 13:28:54 +01:00
|
|
|
NMPlatform *self,
|
2018-07-16 15:42:07 +02:00
|
|
|
int ifindex,
|
|
|
|
|
const NMEthtoolFeatureStates *features,
|
2021-01-10 16:51:37 +01:00
|
|
|
const NMOptionBool *requested /* indexed by NMEthtoolID - _NM_ETHTOOL_ID_FEATURE_FIRST */,
|
|
|
|
|
gboolean do_set /* or reset */);
|
2018-07-16 15:42:07 +02:00
|
|
|
|
2025-03-25 11:53:16 +01:00
|
|
|
gboolean
|
|
|
|
|
nm_platform_ethtool_get_coalesce(NMPlatform *self, int ifindex, NMEthtoolCoalesceState *coalesce);
|
2020-05-07 17:11:34 +02:00
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_ethtool_set_coalesce(NMPlatform *self,
|
2020-05-07 17:11:34 +02:00
|
|
|
int ifindex,
|
2020-05-14 09:16:30 +02:00
|
|
|
const NMEthtoolCoalesceState *coalesce);
|
2020-05-07 17:11:34 +02:00
|
|
|
|
2025-03-25 11:53:16 +01:00
|
|
|
gboolean nm_platform_ethtool_get_ring(NMPlatform *self, int ifindex, NMEthtoolRingState *ring);
|
2020-05-14 18:27:54 +02:00
|
|
|
|
|
|
|
|
gboolean
|
|
|
|
|
nm_platform_ethtool_set_ring(NMPlatform *self, int ifindex, const NMEthtoolRingState *ring);
|
|
|
|
|
|
2025-03-25 11:53:16 +01:00
|
|
|
gboolean
|
|
|
|
|
nm_platform_ethtool_get_channels(NMPlatform *self, int ifindex, NMEthtoolChannelsState *channels);
|
2023-10-11 19:11:14 +02:00
|
|
|
|
|
|
|
|
gboolean nm_platform_ethtool_set_channels(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const NMEthtoolChannelsState *channels);
|
|
|
|
|
|
2024-10-21 15:31:24 +08:00
|
|
|
gboolean nm_platform_ethtool_get_fec_mode(NMPlatform *self, int ifindex, uint32_t *fec_mode);
|
|
|
|
|
|
|
|
|
|
gboolean nm_platform_ethtool_set_fec_mode(NMPlatform *self, int ifindex, uint32_t fec_mode);
|
|
|
|
|
|
2025-03-25 11:53:16 +01:00
|
|
|
gboolean nm_platform_ethtool_get_pause(NMPlatform *self, int ifindex, NMEthtoolPauseState *pause);
|
2021-05-11 15:45:22 +08:00
|
|
|
|
2025-03-25 11:53:16 +01:00
|
|
|
gboolean nm_platform_ethtool_get_eee(NMPlatform *self, int ifindex, NMEthtoolEEEState *eee);
|
2023-10-25 16:52:47 +02:00
|
|
|
|
2021-05-11 15:45:22 +08:00
|
|
|
gboolean
|
|
|
|
|
nm_platform_ethtool_set_pause(NMPlatform *self, int ifindex, const NMEthtoolPauseState *pause);
|
|
|
|
|
|
2023-10-25 16:52:47 +02:00
|
|
|
gboolean nm_platform_ethtool_set_eee(NMPlatform *self, int ifindex, const NMEthtoolEEEState *eee);
|
|
|
|
|
|
platform: add non-exclusive routes and drop route-manager
Previously, we would add exclusive routes via netlink message flags
NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`.
Using that form of RTM_NEWROUTE message, we could only add a certain
route with a certain network/plen,metric triple once. That was already
hugely inconvenient, because
- when configuring routes, multiple (managed) interfaces may get
conflicting routes (multihoming). Only one of the routes can be actually
configured using `ip route replace`, so we need to track routes that are
currently shadowed.
- when configuring routes, we might replace externally configured
routes on unmanaged interfaces. We should not interfere with such
routes.
That was worked around by having NMRouteManager (and NMDefaultRouteManager).
NMRouteManager would keep a list of the routes which NetworkManager would like
to configure, even if momentarily being unable to do so due to conflicting routes.
This worked mostly well but was complicated. It involved bumping metrics to
avoid conflicts for device routes, as we might require them for gateway routes.
Drop that now. Instead, use the corresponding of `ip route append` to configure
routes. This allows NetworkManager to confiure (almost) all routes that we care.
Especially, it can configure all routes on a managed interface, without
replacing/interfering with routes on other interfaces. Hence, NMRouteManager
becomes obsolete.
It practice it is a bit more complicated because:
- when adding an IPv4 address, kernel will automatically create a device route
for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for
IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4
addresses yet (and we don't require such a kernel yet), we still need functionality
similar to nm_route_manager_ip4_route_register_device_route_purge_list().
This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set().
- trying to configure an IPv6 route with a source address will be rejected
by kernel as long as the address is tentative (see related bug rh#1457196).
Preferably, NMDevice would keep the list of routes which should be configured,
while kernel would have the list of what actually is configured. There is a
feed-back loop where both affect each other (for example, when externally deleting
a route, NMDevice must forget about it too). Previously, NMRouteManager would have
the task of remembering all routes which we currently want to configure, but cannot
due to conflicting routes.
We get rid of that, because now we configure non-exclusive routes. We however still
will need to remember IPv6 routes with a source address, that currently cannot be
configured yet. Hence, we will need to keep track of routes that
currently cannot be configured, but later may be.
That is still not done yet, as NMRouteManager didn't handle this
correctly either.
2017-08-14 14:18:53 +02:00
|
|
|
void nm_platform_ip4_dev_route_blacklist_set(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
GPtrArray *ip4_dev_route_blacklist);
|
platform: add non-exclusive routes and drop route-manager
Previously, we would add exclusive routes via netlink message flags
NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`.
Using that form of RTM_NEWROUTE message, we could only add a certain
route with a certain network/plen,metric triple once. That was already
hugely inconvenient, because
- when configuring routes, multiple (managed) interfaces may get
conflicting routes (multihoming). Only one of the routes can be actually
configured using `ip route replace`, so we need to track routes that are
currently shadowed.
- when configuring routes, we might replace externally configured
routes on unmanaged interfaces. We should not interfere with such
routes.
That was worked around by having NMRouteManager (and NMDefaultRouteManager).
NMRouteManager would keep a list of the routes which NetworkManager would like
to configure, even if momentarily being unable to do so due to conflicting routes.
This worked mostly well but was complicated. It involved bumping metrics to
avoid conflicts for device routes, as we might require them for gateway routes.
Drop that now. Instead, use the corresponding of `ip route append` to configure
routes. This allows NetworkManager to confiure (almost) all routes that we care.
Especially, it can configure all routes on a managed interface, without
replacing/interfering with routes on other interfaces. Hence, NMRouteManager
becomes obsolete.
It practice it is a bit more complicated because:
- when adding an IPv4 address, kernel will automatically create a device route
for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for
IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4
addresses yet (and we don't require such a kernel yet), we still need functionality
similar to nm_route_manager_ip4_route_register_device_route_purge_list().
This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set().
- trying to configure an IPv6 route with a source address will be rejected
by kernel as long as the address is tentative (see related bug rh#1457196).
Preferably, NMDevice would keep the list of routes which should be configured,
while kernel would have the list of what actually is configured. There is a
feed-back loop where both affect each other (for example, when externally deleting
a route, NMDevice must forget about it too). Previously, NMRouteManager would have
the task of remembering all routes which we currently want to configure, but cannot
due to conflicting routes.
We get rid of that, because now we configure non-exclusive routes. We however still
will need to remember IPv6 routes with a source address, that currently cannot be
configured yet. Hence, we will need to keep track of routes that
currently cannot be configured, but later may be.
That is still not done yet, as NMRouteManager didn't handle this
correctly either.
2017-08-14 14:18:53 +02:00
|
|
|
|
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_platform_get_multi_idx(NMPlatform *self);
|
|
|
|
|
|
2020-09-11 12:33:40 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
platform: add genl socket support for events and genl family
For generic netlink, the family-id is important. It changes when
loading/unloading a module, so we should not cache it indefinitely.
To get this right, takes some effort. For "nl80211", "nl802154"
and "wireguard", we only cache the family ID in relation to an
interface. If the module gets unloaded, the family ID also becomes
irrelevant and we need to re-fetch it the next time.
For generic families like "mptcp_pm" or "ethtool", they are commonly not
kernel modules and cannot be unloaded. So caching them would be
(probably) fine.
Still. Some generic netlink families emit notifications, and it will
be interesting to be able to handle them. Since that will be useful later,
start by doing something simple: let the generic netlink family also be
cached this way. Generic netlink will send notifications when a family gets
added/deleted, and we can use that to reliably cache the family ID.
We only care about a well-known set of generic families. Unlike libnl
(which has "struct genl_family" object to handle any family), we can hard
code the few we care about (NMPGenlFamilyType).
This adds the necessary infrastructure of NMLinuxPlatform to listen to
events on the generic netlink socket.
2022-06-21 22:01:28 +02:00
|
|
|
guint16 nm_platform_genl_get_family_id(NMPlatform *self, NMPGenlFamilyType family_type);
|
|
|
|
|
|
2022-07-14 22:19:47 +02:00
|
|
|
int
|
|
|
|
|
nm_platform_mptcp_addr_update(NMPlatform *self, NMOptionBool add, const NMPlatformMptcpAddr *addr);
|
|
|
|
|
|
|
|
|
|
GPtrArray *nm_platform_mptcp_addrs_dump(NMPlatform *self);
|
|
|
|
|
|
2022-09-22 13:33:17 +02:00
|
|
|
gboolean nm_platform_ip6_dadfailed_check(NMPlatform *self, int ifindex, const struct in6_addr *ip6);
|
|
|
|
|
void nm_platform_ip6_dadfailed_set(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const struct in6_addr *ip6,
|
|
|
|
|
gboolean failed);
|
|
|
|
|
|
2022-06-12 19:50:09 -04:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
static inline NMPlatformIP4Address *
|
|
|
|
|
nm_platform_ip4_address_init_loopback_addr1(NMPlatformIP4Address *a)
|
|
|
|
|
{
|
2024-10-04 10:45:56 +02:00
|
|
|
*a = ((NMPlatformIP4Address) {
|
2022-06-12 19:50:09 -04:00
|
|
|
.address = NM_IPV4LO_ADDR1,
|
|
|
|
|
.peer_address = NM_IPV4LO_ADDR1,
|
|
|
|
|
.ifindex = NM_LOOPBACK_IFINDEX,
|
|
|
|
|
.plen = NM_IPV4LO_PREFIXLEN,
|
|
|
|
|
});
|
|
|
|
|
return a;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline NMPlatformIP6Address *
|
|
|
|
|
nm_platform_ip6_address_init_loopback(NMPlatformIP6Address *a)
|
|
|
|
|
{
|
2024-10-04 10:45:56 +02:00
|
|
|
*a = ((NMPlatformIP6Address) {
|
2022-06-12 19:50:09 -04:00
|
|
|
.address = IN6ADDR_LOOPBACK_INIT,
|
|
|
|
|
.ifindex = NM_LOOPBACK_IFINDEX,
|
|
|
|
|
.plen = 128,
|
|
|
|
|
});
|
|
|
|
|
return a;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
#endif /* __NETWORKMANAGER_PLATFORM_H__ */
|