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"
|
2020-12-25 17:54:46 +01:00
|
|
|
|
2013-03-27 22:23:24 +01:00
|
|
|
#define NM_TYPE_PLATFORM (nm_platform_get_type())
|
|
|
|
|
#define NM_PLATFORM(obj) (G_TYPE_CHECK_INSTANCE_CAST((obj), NM_TYPE_PLATFORM, NMPlatform))
|
|
|
|
|
#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
|
|
|
|
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"
|
2017-04-17 18:40:52 +02:00
|
|
|
#define NM_PLATFORM_LOG_WITH_PTR "log-with-ptr"
|
2021-09-17 17:32:57 +02:00
|
|
|
#define NM_PLATFORM_CACHE_TC "cache-tc"
|
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-11-12 15:23:36 +01:00
|
|
|
/* IFNAMSIZ is both defined in <linux/if.h> and <net/if.h>. In the past, these
|
|
|
|
|
* headers conflicted, so we cannot simply include either of them in a header-file.*/
|
|
|
|
|
#define NMP_IFNAMSIZ 16
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
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);
|
|
|
|
|
|
2014-03-04 14:30:01 +01:00
|
|
|
/* workaround for older libnl version, that does not define these flags. */
|
|
|
|
|
#ifndef IFA_F_MANAGETEMPADDR
|
2021-07-09 08:48:48 +02:00
|
|
|
#define IFA_F_MANAGETEMPADDR 0x100
|
2014-03-04 14:30:01 +01:00
|
|
|
#endif
|
|
|
|
|
#ifndef IFA_F_NOPREFIXROUTE
|
2021-07-09 08:48:48 +02:00
|
|
|
#define IFA_F_NOPREFIXROUTE 0x200
|
2014-03-04 14:30:01 +01:00
|
|
|
#endif
|
|
|
|
|
|
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-10-12 16:07:01 +02:00
|
|
|
/* Define of the IN6_ADDR_GEN_MODE_* values to workaround old kernel headers
|
|
|
|
|
* that don't define it. */
|
|
|
|
|
#define NM_IN6_ADDR_GEN_MODE_UNKNOWN 255 /* no corresponding value. */
|
2021-05-03 21:48:58 +02:00
|
|
|
#define NM_IN6_ADDR_GEN_MODE_EUI64 0 /* IN6_ADDR_GEN_MODE_EUI64 */
|
|
|
|
|
#define NM_IN6_ADDR_GEN_MODE_NONE 1 /* IN6_ADDR_GEN_MODE_NONE */
|
|
|
|
|
#define NM_IN6_ADDR_GEN_MODE_STABLE_PRIVACY 2 /* IN6_ADDR_GEN_MODE_STABLE_PRIVACY */
|
|
|
|
|
#define NM_IN6_ADDR_GEN_MODE_RANDOM 3 /* IN6_ADDR_GEN_MODE_RANDOM */
|
2015-10-12 16:07:01 +02:00
|
|
|
|
2015-09-15 15:07:37 +02:00
|
|
|
#define NM_IFF_MULTI_QUEUE 0x0100 /* IFF_MULTI_QUEUE */
|
|
|
|
|
|
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,
|
|
|
|
|
|
|
|
|
|
/* compare two routes as kernel would allow to add them with
|
|
|
|
|
* `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,
|
|
|
|
|
|
|
|
|
|
/* 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
|
|
|
|
2018-03-09 16:08:52 +01:00
|
|
|
typedef enum {
|
|
|
|
|
|
|
|
|
|
/* match-flags are strictly inclusive. That means,
|
|
|
|
|
* by default nothing is matched, but if you enable a particular
|
|
|
|
|
* flag, a candidate that matches passes the check.
|
|
|
|
|
*
|
|
|
|
|
* In other words: adding more flags can only extend the result
|
|
|
|
|
* set of matching objects.
|
|
|
|
|
*
|
|
|
|
|
* Also, the flags form partitions. Like, an address can be either of
|
|
|
|
|
* ADDRTYPE_NORMAL or ADDRTYPE_LINKLOCAL, but never both. Same for
|
|
|
|
|
* the ADDRSTATE match types.
|
|
|
|
|
*/
|
|
|
|
|
NM_PLATFORM_MATCH_WITH_NONE = 0,
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-03-09 16:08:52 +01:00
|
|
|
NM_PLATFORM_MATCH_WITH_ADDRTYPE_NORMAL = (1LL << 0),
|
|
|
|
|
NM_PLATFORM_MATCH_WITH_ADDRTYPE_LINKLOCAL = (1LL << 1),
|
|
|
|
|
NM_PLATFORM_MATCH_WITH_ADDRTYPE__ANY =
|
|
|
|
|
NM_PLATFORM_MATCH_WITH_ADDRTYPE_NORMAL | NM_PLATFORM_MATCH_WITH_ADDRTYPE_LINKLOCAL,
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-06-10 22:53:31 +02:00
|
|
|
NM_PLATFORM_MATCH_WITH_ADDRSTATE_NORMAL = (1LL << 2),
|
|
|
|
|
NM_PLATFORM_MATCH_WITH_ADDRSTATE_TENTATIVE = (1LL << 3),
|
|
|
|
|
NM_PLATFORM_MATCH_WITH_ADDRSTATE_DADFAILED = (1LL << 4),
|
|
|
|
|
NM_PLATFORM_MATCH_WITH_ADDRSTATE_DEPRECATED = (1LL << 5),
|
|
|
|
|
NM_PLATFORM_MATCH_WITH_ADDRSTATE__ANY =
|
|
|
|
|
NM_PLATFORM_MATCH_WITH_ADDRSTATE_NORMAL | NM_PLATFORM_MATCH_WITH_ADDRSTATE_TENTATIVE
|
|
|
|
|
| NM_PLATFORM_MATCH_WITH_ADDRSTATE_DADFAILED | NM_PLATFORM_MATCH_WITH_ADDRSTATE_DEPRECATED,
|
2018-03-09 16:08:52 +01:00
|
|
|
} NMPlatformMatchFlags;
|
|
|
|
|
|
2015-08-17 17:48:37 +02:00
|
|
|
#define NM_PLATFORM_LINK_OTHER_NETNS (-1)
|
|
|
|
|
|
2019-03-04 13:01:21 +01:00
|
|
|
struct _NMPlatformObject {
|
|
|
|
|
/* the object type has no fields of its own, it is only used to having
|
|
|
|
|
* a special pointer type that can be used to indicate "any" type. */
|
|
|
|
|
char _dummy_don_t_use_me;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define __NMPlatformObjWithIfindex_COMMON \
|
2014-04-03 11:02:48 +02:00
|
|
|
int ifindex; \
|
|
|
|
|
;
|
|
|
|
|
|
2019-03-04 13:01:21 +01:00
|
|
|
struct _NMPlatformObjWithIfindex {
|
|
|
|
|
__NMPlatformObjWithIfindex_COMMON;
|
|
|
|
|
};
|
|
|
|
|
|
2014-07-17 17:06:44 -04:00
|
|
|
struct _NMPlatformLink {
|
2019-03-04 13:01:21 +01:00
|
|
|
__NMPlatformObjWithIfindex_COMMON;
|
2018-11-12 15:23:36 +01:00
|
|
|
char name[NMP_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
|
|
|
|
2013-03-27 22:53:55 +01:00
|
|
|
int master;
|
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;
|
|
|
|
|
|
2016-02-29 15:52:27 +01:00
|
|
|
/* @connected is mostly identical to (@n_ifi_flags & IFF_UP). Except for bridge/bond masters,
|
2015-04-25 16:42:26 +02:00
|
|
|
* where we coerce the link as disconnect if it has no slaves. */
|
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;
|
2014-07-17 17:06:44 -04:00
|
|
|
};
|
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);
|
|
|
|
|
|
2015-07-02 16:57:28 +02:00
|
|
|
typedef enum {
|
2015-04-13 18:55:59 +02:00
|
|
|
NM_PLATFORM_SIGNAL_NONE,
|
2014-03-07 19:04:38 +01:00
|
|
|
NM_PLATFORM_SIGNAL_ADDED,
|
|
|
|
|
NM_PLATFORM_SIGNAL_CHANGED,
|
|
|
|
|
NM_PLATFORM_SIGNAL_REMOVED,
|
|
|
|
|
} NMPlatformSignalChangeType;
|
|
|
|
|
|
2017-11-30 14:11:04 +01:00
|
|
|
#define NM_PLATFORM_IP_ADDRESS_CAST(address) \
|
|
|
|
|
NM_CONSTCAST(NMPlatformIPAddress, \
|
|
|
|
|
(address), \
|
|
|
|
|
NMPlatformIPXAddress, \
|
|
|
|
|
NMPlatformIP4Address, \
|
|
|
|
|
NMPlatformIP6Address)
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-04-03 11:02:48 +02:00
|
|
|
#define __NMPlatformIPAddress_COMMON \
|
2019-03-04 13:01:21 +01:00
|
|
|
__NMPlatformObjWithIfindex_COMMON; \
|
2016-04-11 13:09:52 +02:00
|
|
|
NMIPConfigSource addr_source; \
|
platform: fix preferred and valid lifetimes for addresses from netlink/kernel
The kernel tells the address lifetimes in the 'struct ifa_cacheinfo'
attribute. This contains two timestamps (cstamp and tstamp) and two
relative lifetimes (ifa_prefered and ifa_valid).
The timestamps are equal to clock_gettime(CLOCK_MONOTONIC) scale in
1/100th of a second (wrapping every 497 days).
The preferred/valid times are re-adjusted everytime when sending the
message and count down as the time goes by. In other words, they are
anchored relatively to the moment of when kernel creates the netlink
message.
As platform is caching the rtnl_addr object, the information of *when* the
lifetimes started counting is not available.
This patch fixes reading these values by hacking the libnl object
when it gets received, so that valid and preferred are instead absolute
expiration timestamps in scale nm_utils_get_monotonic_timestamp_s() --
which NM internally is used for address timestamps.
There are two minor downsides to this hack:
- the valid and preferred properties of a cached rtnl_addr object have
an unexpected meaning, i.e. they are absolute and in a different time
scale.
- later when converting rtnl_addr to NMPlatformIPAddress, the base
timestamp is set to "1", i.e. an NMPlatformIPAddress has no knowledge
of when the address was created or last modified. The timestamp
property of NMPlatformIPAddress is solely there to anchor the relative
timestamps lifetime and preferred. Do not use it for anything
else.
Another reason the timestamp property is meaningless is that
its scale nm_utils_get_monotonic_timestamp_s() starts counting at
process start. So addresses that existed before would have a negative
or zero timestamp, which we avoid. This in turn could be solved by either
allowing negative timestamps or by shifting
nm_utils_get_monotonic_timestamp_*(). Both is viable, but not
necessary (ATM), because the age of an address has no other apparent
use then to anchor the relative timestamps.
Another implication is, that we potentially could get rid of the
timestamp completely, and insteat make preferred and lifetime be
absolute expiries.
This will be fixed properly later, by not caching libnl objects but instead
native NMPlatform objects. For those we have full control over their properties.
https://bugzilla.gnome.org/show_bug.cgi?id=727382
Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-02 13:35:21 +02:00
|
|
|
\
|
|
|
|
|
/* Timestamp in seconds in the reference system of nm_utils_get_monotonic_timestamp_*().
|
2014-06-09 10:03:01 +02:00
|
|
|
*
|
|
|
|
|
* The rules are:
|
|
|
|
|
* 1 @lifetime==0: @timestamp and @preferred is irrelevant (but mostly set to 0 too). Such addresses
|
|
|
|
|
* are permanent. This rule is so that unset addresses (calloc) are permanent by default.
|
|
|
|
|
* 2 @lifetime==@preferred==NM_PLATFORM_LIFETIME_PERMANENT: @timestamp is irrelevant (but mostly
|
|
|
|
|
* set to 0). Such addresses are permanent.
|
2018-09-14 23:49:20 -04:00
|
|
|
* 3 Non permanent addresses should (almost) always have @timestamp > 0. 0 is not a valid timestamp
|
2019-12-13 16:54:30 +01:00
|
|
|
* and never returned by nm_utils_get_monotonic_timestamp_sec(). In this case @valid/@preferred
|
2014-06-09 10:03:01 +02:00
|
|
|
* is anchored at @timestamp.
|
2018-09-14 23:49:20 -04:00
|
|
|
* 4 Non permanent addresses with @timestamp == 0 are implicitly anchored at *now*, thus the time
|
2014-06-09 10:03:01 +02:00
|
|
|
* moves as time goes by. This is usually not useful, except e.g. nm_platform_ip[46]_address_add().
|
|
|
|
|
*
|
|
|
|
|
* Non permanent addresses from DHCP/RA might have the @timestamp set to the moment of when the
|
|
|
|
|
* lease was received. Addresses from kernel might have the @timestamp based on the last modification
|
|
|
|
|
* time of the addresses. But don't rely on this behaviour, the @timestamp is only defined for anchoring
|
|
|
|
|
* @lifetime and @preferred.
|
platform: fix preferred and valid lifetimes for addresses from netlink/kernel
The kernel tells the address lifetimes in the 'struct ifa_cacheinfo'
attribute. This contains two timestamps (cstamp and tstamp) and two
relative lifetimes (ifa_prefered and ifa_valid).
The timestamps are equal to clock_gettime(CLOCK_MONOTONIC) scale in
1/100th of a second (wrapping every 497 days).
The preferred/valid times are re-adjusted everytime when sending the
message and count down as the time goes by. In other words, they are
anchored relatively to the moment of when kernel creates the netlink
message.
As platform is caching the rtnl_addr object, the information of *when* the
lifetimes started counting is not available.
This patch fixes reading these values by hacking the libnl object
when it gets received, so that valid and preferred are instead absolute
expiration timestamps in scale nm_utils_get_monotonic_timestamp_s() --
which NM internally is used for address timestamps.
There are two minor downsides to this hack:
- the valid and preferred properties of a cached rtnl_addr object have
an unexpected meaning, i.e. they are absolute and in a different time
scale.
- later when converting rtnl_addr to NMPlatformIPAddress, the base
timestamp is set to "1", i.e. an NMPlatformIPAddress has no knowledge
of when the address was created or last modified. The timestamp
property of NMPlatformIPAddress is solely there to anchor the relative
timestamps lifetime and preferred. Do not use it for anything
else.
Another reason the timestamp property is meaningless is that
its scale nm_utils_get_monotonic_timestamp_s() starts counting at
process start. So addresses that existed before would have a negative
or zero timestamp, which we avoid. This in turn could be solved by either
allowing negative timestamps or by shifting
nm_utils_get_monotonic_timestamp_*(). Both is viable, but not
necessary (ATM), because the age of an address has no other apparent
use then to anchor the relative timestamps.
Another implication is, that we potentially could get rid of the
timestamp completely, and insteat make preferred and lifetime be
absolute expiries.
This will be fixed properly later, by not caching libnl objects but instead
native NMPlatform objects. For those we have full control over their properties.
https://bugzilla.gnome.org/show_bug.cgi?id=727382
Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-02 13:35:21 +02:00
|
|
|
*/ \
|
|
|
|
|
guint32 timestamp; \
|
|
|
|
|
guint32 lifetime; /* seconds since timestamp */ \
|
|
|
|
|
guint32 preferred; /* seconds since timestamp */ \
|
2016-02-29 16:50:55 +01:00
|
|
|
\
|
|
|
|
|
/* ifa_flags in 'struct ifaddrmsg' from <linux/if_addr.h>, extended to 32 bit by
|
|
|
|
|
* IFA_FLAGS attribute. */ \
|
|
|
|
|
guint32 n_ifa_flags; \
|
|
|
|
|
\
|
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
|
|
|
bool use_ip4_broadcast_address : 1; \
|
2020-10-09 18:59:58 +02:00
|
|
|
\
|
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 addresses that
|
|
|
|
|
* should be configured. */ \
|
|
|
|
|
/* Whether the address is should be configured once during assume. */ \
|
2021-09-06 13:58:59 +02:00
|
|
|
bool a_assume_config_once : 1; \
|
2021-11-11 22:16:14 +01:00
|
|
|
bool a_force_commit : 1; \
|
2021-09-10 13:43:34 +02:00
|
|
|
\
|
|
|
|
|
guint8 plen; \
|
2014-04-03 11:02:48 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* NMPlatformIPAddress:
|
|
|
|
|
*
|
|
|
|
|
* Common parts of NMPlatformIP4Address and NMPlatformIP6Address.
|
|
|
|
|
**/
|
|
|
|
|
typedef struct {
|
|
|
|
|
__NMPlatformIPAddress_COMMON;
|
|
|
|
|
union {
|
|
|
|
|
guint8 address_ptr[1];
|
|
|
|
|
guint32 __dummy_for_32bit_alignment;
|
|
|
|
|
};
|
|
|
|
|
} NMPlatformIPAddress;
|
|
|
|
|
|
2013-12-10 19:04:22 +01:00
|
|
|
/**
|
|
|
|
|
* NMPlatformIP4Address:
|
2019-12-13 16:54:30 +01:00
|
|
|
* @timestamp: timestamp as returned by nm_utils_get_monotonic_timestamp_sec()
|
2013-12-10 19:04:22 +01:00
|
|
|
**/
|
2014-07-17 17:06:44 -04:00
|
|
|
struct _NMPlatformIP4Address {
|
2014-04-03 11:02:48 +02:00
|
|
|
__NMPlatformIPAddress_COMMON;
|
2015-10-21 23:17:11 +02:00
|
|
|
|
2021-09-06 14:46:47 +02:00
|
|
|
/* Whether the address is ready to be configured. By default, an address is, but this
|
|
|
|
|
* flag may indicate that the address is just for tracking purpose only, but the ACD
|
|
|
|
|
* state is not yet ready for the address to be configured. */
|
|
|
|
|
bool a_acd_not_ready : 1;
|
|
|
|
|
|
2015-10-21 23:17:11 +02:00
|
|
|
/* The local address IFA_LOCAL. */
|
2013-03-27 22:23:24 +01:00
|
|
|
in_addr_t address;
|
2015-10-21 23:17:11 +02:00
|
|
|
|
|
|
|
|
/* The IFA_ADDRESS PTP peer address. This field is rather important, because
|
|
|
|
|
* it constitutes the identifier for the IPv4 address (e.g. you can add two
|
|
|
|
|
* addresses that only differ by their peer's network-part.
|
|
|
|
|
*
|
|
|
|
|
* Beware that for most cases, NetworkManager doesn't want to set an explicit
|
2020-09-18 12:25:23 +02:00
|
|
|
* peer-address. However, that corresponds to setting the peer address to @address
|
2015-10-21 23:17:11 +02:00
|
|
|
* itself. Leaving peer-address unset/zero, means explicitly setting the peer
|
|
|
|
|
* address to 0.0.0.0, which you probably don't want.
|
|
|
|
|
* */
|
2013-12-02 10:20:26 -05:00
|
|
|
in_addr_t peer_address; /* PTP peer address */
|
2015-10-21 23:17:11 +02:00
|
|
|
|
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
|
|
|
/* IFA_BROADCAST.
|
|
|
|
|
*
|
|
|
|
|
* This parameter is ignored unless use_ip4_broadcast_address is TRUE.
|
|
|
|
|
* See nm_platform_ip4_broadcast_address_from_addr(). */
|
|
|
|
|
in_addr_t broadcast_address;
|
|
|
|
|
|
2018-11-12 15:23:36 +01:00
|
|
|
char label[NMP_IFNAMSIZ];
|
2014-07-17 17:06:44 -04:00
|
|
|
};
|
2013-03-27 22:23:24 +01:00
|
|
|
|
2013-12-10 19:04:22 +01:00
|
|
|
/**
|
|
|
|
|
* NMPlatformIP6Address:
|
2019-12-13 16:54:30 +01:00
|
|
|
* @timestamp: timestamp as returned by nm_utils_get_monotonic_timestamp_sec()
|
2013-12-10 19:04:22 +01:00
|
|
|
**/
|
2014-07-17 17:06:44 -04:00
|
|
|
struct _NMPlatformIP6Address {
|
2014-04-03 11:02:48 +02:00
|
|
|
__NMPlatformIPAddress_COMMON;
|
2013-03-27 22:23:24 +01:00
|
|
|
struct in6_addr address;
|
2013-12-02 10:20:26 -05:00
|
|
|
struct in6_addr peer_address;
|
2014-07-17 17:06:44 -04:00
|
|
|
};
|
2014-04-03 11:02:48 +02:00
|
|
|
|
2014-11-10 14:23:44 +01:00
|
|
|
typedef union {
|
|
|
|
|
NMPlatformIPAddress ax;
|
|
|
|
|
NMPlatformIP4Address a4;
|
|
|
|
|
NMPlatformIP6Address a6;
|
|
|
|
|
} NMPlatformIPXAddress;
|
|
|
|
|
|
2014-04-03 11:02:48 +02:00
|
|
|
#undef __NMPlatformIPAddress_COMMON
|
|
|
|
|
|
2020-09-18 12:25:23 +02:00
|
|
|
#define NM_PLATFORM_IP4_ADDRESS_INIT(...) (&((const NMPlatformIP4Address){__VA_ARGS__}))
|
|
|
|
|
|
|
|
|
|
#define NM_PLATFORM_IP6_ADDRESS_INIT(...) (&((const NMPlatformIP6Address){__VA_ARGS__}))
|
|
|
|
|
|
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; \
|
|
|
|
|
\
|
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; \
|
|
|
|
|
\
|
|
|
|
|
guint8 plen; \
|
|
|
|
|
\
|
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; \
|
|
|
|
|
\
|
|
|
|
|
/* 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-07-20 11:09:40 +02:00
|
|
|
\
|
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
|
|
|
|
|
* should be configured. */ \
|
|
|
|
|
/* Whether the route is should be configured once during assume. */ \
|
2021-09-06 13:58:59 +02:00
|
|
|
bool r_assume_config_once : 1; \
|
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
|
|
|
\
|
2017-11-07 15:32:55 +01:00
|
|
|
/* rtnh_flags
|
|
|
|
|
*
|
|
|
|
|
* 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().
|
|
|
|
|
*
|
2018-01-23 12:24:29 +01:00
|
|
|
* NOTE: currently we ignore all flags except RTM_F_CLONED
|
2019-04-09 12:55:32 +02:00
|
|
|
* and RTNH_F_ONLINK.
|
2017-11-07 15:32:55 +01:00
|
|
|
* We also may not properly consider the flags as part of the ID
|
2020-10-22 10:29:03 +02:00
|
|
|
* in route-cmp. */ \
|
|
|
|
|
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; \
|
|
|
|
|
\
|
|
|
|
|
/* 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; \
|
|
|
|
|
\
|
2017-08-21 23:17:12 +02:00
|
|
|
/* 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
|
2020-10-22 10:29:03 +02:00
|
|
|
* table. Use nm_platform_route_table_coerce()/nm_platform_route_table_uncoerce(). */ \
|
|
|
|
|
guint32 table_coerced; \
|
|
|
|
|
\
|
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.
|
2020-10-22 10:29:03 +02:00
|
|
|
* */ \
|
|
|
|
|
guint8 type_coerced; \
|
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;
|
|
|
|
|
union {
|
|
|
|
|
guint8 network_ptr[1];
|
|
|
|
|
guint32 __dummy_for_32bit_alignment;
|
|
|
|
|
};
|
|
|
|
|
} NMPlatformIPRoute;
|
|
|
|
|
|
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;
|
2013-03-27 22:23:24 +01:00
|
|
|
in_addr_t 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
|
|
|
in_addr_t gateway;
|
2015-05-03 10:47:41 +02:00
|
|
|
|
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
|
|
|
|
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;
|
2014-07-17 17:06:44 -04:00
|
|
|
};
|
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,
|
|
|
|
|
* Not only `ip route append`, but also `ip route add` allows to add routes that only
|
|
|
|
|
* 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;
|
2014-07-17 17:06:44 -04:00
|
|
|
};
|
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
|
|
|
|
|
|
2021-08-27 08:38:19 +02:00
|
|
|
#define NM_PLATFORM_IP4_ROUTE_INIT(...) (&((const NMPlatformIP4Route){__VA_ARGS__}))
|
|
|
|
|
|
|
|
|
|
#define NM_PLATFORM_IP6_ROUTE_INIT(...) (&((const NMPlatformIP6Route){__VA_ARGS__}))
|
|
|
|
|
|
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 */
|
|
|
|
|
char iifname[NMP_IFNAMSIZ]; /* FRA_IIFNAME */
|
|
|
|
|
char oifname[NMP_IFNAMSIZ]; /* FRA_OIFNAME */
|
|
|
|
|
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) */
|
|
|
|
|
} NMPlatformRoutingRule;
|
|
|
|
|
|
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
|
|
|
};
|
2017-11-15 20:36:35 +01:00
|
|
|
} 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;
|
|
|
|
|
} NMPlatformTfilter;
|
|
|
|
|
|
2019-03-04 13:01:21 +01:00
|
|
|
#undef __NMPlatformObjWithIfindex_COMMON
|
2014-04-03 11:02:48 +02:00
|
|
|
|
2015-03-25 11:28:19 +01:00
|
|
|
typedef struct {
|
|
|
|
|
gboolean is_ip4;
|
2017-06-29 15:19:35 +02:00
|
|
|
NMPObjectType obj_type;
|
2015-03-25 11:28:19 +01:00
|
|
|
int addr_family;
|
|
|
|
|
gsize sizeof_route;
|
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;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
guint32 index;
|
|
|
|
|
guint32 min_tx_rate;
|
|
|
|
|
guint32 max_tx_rate;
|
|
|
|
|
guint num_vlans;
|
|
|
|
|
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;
|
|
|
|
|
|
2019-03-16 17:22:35 +01:00
|
|
|
typedef struct {
|
2019-04-15 15:14:33 +02:00
|
|
|
guint16 vid_start;
|
|
|
|
|
guint16 vid_end;
|
2019-03-16 17:22:35 +01:00
|
|
|
bool untagged : 1;
|
|
|
|
|
bool pvid : 1;
|
|
|
|
|
} NMPlatformBridgeVlan;
|
|
|
|
|
|
2020-08-05 13:46:28 -04:00
|
|
|
typedef struct {
|
2020-08-20 09:40:17 -04:00
|
|
|
NMEtherAddr group_addr;
|
|
|
|
|
bool mcast_querier : 1;
|
|
|
|
|
bool mcast_query_use_ifaddr : 1;
|
|
|
|
|
bool mcast_snooping : 1;
|
2020-08-06 16:52:16 -04:00
|
|
|
bool stp_state : 1;
|
2020-08-20 09:40:17 -04:00
|
|
|
bool vlan_stats_enabled : 1;
|
|
|
|
|
guint16 group_fwd_mask;
|
|
|
|
|
guint16 priority;
|
|
|
|
|
guint16 vlan_protocol;
|
|
|
|
|
guint32 ageing_time;
|
2020-08-05 13:46:28 -04:00
|
|
|
guint32 forward_delay;
|
|
|
|
|
guint32 hello_time;
|
|
|
|
|
guint32 max_age;
|
2020-08-06 16:52:16 -04:00
|
|
|
guint32 mcast_last_member_count;
|
2020-08-20 09:40:17 -04:00
|
|
|
guint32 mcast_startup_query_count;
|
2020-08-20 09:40:17 -04:00
|
|
|
guint32 mcast_hash_max;
|
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;
|
2020-08-20 09:40:17 -04:00
|
|
|
guint8 mcast_router;
|
2020-08-05 13:46:28 -04:00
|
|
|
} NMPlatformLnkBridge;
|
|
|
|
|
|
|
|
|
|
extern const NMPlatformLnkBridge nm_platform_lnk_bridge_default;
|
|
|
|
|
|
2015-10-15 15:47:14 +02:00
|
|
|
typedef struct {
|
2016-02-29 15:57:37 +01:00
|
|
|
in_addr_t local;
|
|
|
|
|
in_addr_t remote;
|
2015-10-16 18:26:38 +02:00
|
|
|
int parent_ifindex;
|
|
|
|
|
guint16 input_flags;
|
|
|
|
|
guint16 output_flags;
|
|
|
|
|
guint32 input_key;
|
|
|
|
|
guint32 output_key;
|
|
|
|
|
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;
|
2015-10-16 18:26:38 +02:00
|
|
|
} NMPlatformLnkGre;
|
2015-10-12 13:44:44 +02:00
|
|
|
|
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;
|
2015-10-16 18:26:38 +02:00
|
|
|
} 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;
|
2015-11-27 22:22:25 +01:00
|
|
|
guint8 ttl;
|
|
|
|
|
guint8 tclass;
|
|
|
|
|
guint8 encap_limit;
|
|
|
|
|
guint8 proto;
|
2016-02-29 15:57:37 +01:00
|
|
|
guint flow_label;
|
2017-12-22 10:24:25 +01:00
|
|
|
guint32 flags;
|
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;
|
2015-11-27 22:22:25 +01:00
|
|
|
} NMPlatformLnkIp6Tnl;
|
|
|
|
|
|
2015-11-27 14:01:56 +01:00
|
|
|
typedef struct {
|
|
|
|
|
in_addr_t local;
|
|
|
|
|
in_addr_t remote;
|
2016-02-29 15:57:37 +01:00
|
|
|
int parent_ifindex;
|
2015-11-27 14:01:56 +01:00
|
|
|
guint8 ttl;
|
|
|
|
|
guint8 tos;
|
2016-02-29 15:57:37 +01:00
|
|
|
bool path_mtu_discovery : 1;
|
2015-11-27 14:01:56 +01:00
|
|
|
} NMPlatformLnkIpIp;
|
|
|
|
|
|
2016-06-30 18:20: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;
|
|
|
|
|
} NMPlatformLnkMacsec;
|
|
|
|
|
|
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;
|
2015-10-12 15:15:21 +02:00
|
|
|
} NMPlatformLnkMacvlan;
|
2013-05-06 09:16:17 -04:00
|
|
|
|
2015-11-11 18:41:48 +01:00
|
|
|
typedef struct {
|
|
|
|
|
in_addr_t local;
|
|
|
|
|
in_addr_t remote;
|
2016-02-29 15:57:37 +01:00
|
|
|
int parent_ifindex;
|
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;
|
2015-11-11 18:41:48 +01:00
|
|
|
} NMPlatformLnkSit;
|
|
|
|
|
|
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;
|
|
|
|
|
} NMPlatformLnkTun;
|
|
|
|
|
|
2015-10-16 18:26:38 +02:00
|
|
|
typedef struct {
|
|
|
|
|
/* rtnl_link_vlan_get_id(), IFLA_VLAN_ID */
|
2021-03-03 20:57:01 +01:00
|
|
|
guint16 id;
|
|
|
|
|
_NMVlanFlags flags;
|
2015-10-16 18:26:38 +02:00
|
|
|
} NMPlatformLnkVlan;
|
|
|
|
|
|
2019-12-05 10:35:25 +01:00
|
|
|
typedef struct {
|
|
|
|
|
guint32 table;
|
|
|
|
|
} NMPlatformLnkVrf;
|
|
|
|
|
|
2013-06-04 10:31:22 -03:00
|
|
|
typedef struct {
|
|
|
|
|
struct in6_addr group6;
|
|
|
|
|
struct in6_addr local6;
|
2016-02-29 15:57:37 +01:00
|
|
|
in_addr_t group;
|
|
|
|
|
in_addr_t local;
|
|
|
|
|
int parent_ifindex;
|
|
|
|
|
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;
|
2015-10-12 15:15:21 +02:00
|
|
|
} 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];
|
2018-07-28 14:54:33 +02:00
|
|
|
} NMPlatformLnkWireGuard;
|
2018-03-13 13:35:35 +00:00
|
|
|
|
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);
|
|
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2013-03-27 22:23:24 +01:00
|
|
|
|
2022-02-28 18:46:12 +02:00
|
|
|
typedef struct _NMPlatformCsmeConnInfo {
|
|
|
|
|
guint8 ssid[32];
|
|
|
|
|
guint32 channel;
|
|
|
|
|
NMEtherAddr addr;
|
|
|
|
|
guint8 sta_cipher;
|
|
|
|
|
guint8 auth_mode;
|
|
|
|
|
} NMPlatformCsmeConnInfo;
|
|
|
|
|
|
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,
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
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);
|
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,
|
|
|
|
|
guint num_vfs,
|
2021-01-10 16:51:37 +01:00
|
|
|
NMOptionBool autoprobe,
|
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);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean (*link_set_bridge_vlans)(NMPlatform *self,
|
2019-03-16 17:22:35 +01:00
|
|
|
int ifindex,
|
|
|
|
|
gboolean on_master,
|
|
|
|
|
const NMPlatformBridgeVlan *const *vlans);
|
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
|
|
|
|
2019-01-02 11:28:53 +01:00
|
|
|
gboolean (*link_enslave)(NMPlatform *self, int master, int slave);
|
|
|
|
|
gboolean (*link_release)(NMPlatform *self, int master, int slave);
|
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);
|
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);
|
|
|
|
|
guint32 (*wifi_find_frequency)(NMPlatform *self, int ifindex, const guint32 *freqs);
|
|
|
|
|
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);
|
2022-02-28 18:46:12 +02:00
|
|
|
gboolean (*wifi_get_csme_conn_info)(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
NMPlatformCsmeConnInfo *out_conn_info);
|
2022-02-28 22:28:41 +02:00
|
|
|
gboolean (*wifi_get_device_from_csme)(NMPlatform *self, int ifindex);
|
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,
|
2014-02-19 16:10:59 -05:00
|
|
|
const char *label);
|
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,
|
2016-02-29 15:36:12 +01:00
|
|
|
guint32 flags);
|
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
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
int (*ip_route_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
|
|
|
NMPNlmFlags flags,
|
|
|
|
|
int addr_family,
|
|
|
|
|
const NMPlatformIPRoute *route);
|
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,
|
|
|
|
|
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);
|
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
|
|
|
|
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
|
|
|
static inline in_addr_t
|
|
|
|
|
nm_platform_ip4_broadcast_address_create(in_addr_t address, guint8 plen)
|
|
|
|
|
{
|
|
|
|
|
return address | ~_nm_utils_ip4_prefix_to_netmask(plen);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline in_addr_t
|
|
|
|
|
nm_platform_ip4_broadcast_address_from_addr(const NMPlatformIP4Address *addr)
|
|
|
|
|
{
|
|
|
|
|
nm_assert(addr);
|
|
|
|
|
|
|
|
|
|
if (addr->use_ip4_broadcast_address)
|
|
|
|
|
return addr->broadcast_address;
|
|
|
|
|
|
platform: generate IFA_BROADCAST address based on the peer IFA_ADDRESS
This is also what iproute2 does ([1]) when creating a default broadcast address
with `ip addr add 192.168.1.5/24 brd + dev eth0`.
Also, kernel does in fib_add_ifaddr() ([2]):
```
__be32 addr = ifa->ifa_local;
__be32 prefix = ifa->ifa_address & mask;
...
/* Add broadcast address, if it is explicitly assigned. */
if (ifa->ifa_broadcast && ifa->ifa_broadcast != htonl(0xFFFFFFFF))
fib_magic(RTM_NEWROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32,
prim, 0);
if (!ipv4_is_zeronet(prefix) && !(ifa->ifa_flags & IFA_F_SECONDARY) &&
(prefix != addr || ifa->ifa_prefixlen < 32)) {
if (!(ifa->ifa_flags & IFA_F_NOPREFIXROUTE))
fib_magic(RTM_NEWROUTE,
dev->flags & IFF_LOOPBACK ? RTN_LOCAL : RTN_UNICAST,
prefix, ifa->ifa_prefixlen, prim,
ifa->ifa_rt_priority);
/* Add network specific broadcasts, when it takes a sense */
if (ifa->ifa_prefixlen < 31) {
fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix, 32,
prim, 0);
fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix | ~mask,
32, prim, 0);
}
}
```
Which means by default kernel already adds those special broadcast routes which
are identical to what we configure with IFA_BROADCAST. However, kernel too bases
them on the peer (IFA_ADDRESS).
[1] https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/ipaddress.c?id=d5391e186f04214315a5a80797c78e50ad9f5271#n2380
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/fib_frontend.c?id=bef1d88263ff769f15aa0e1515cdcede84e61d15#n1109
2020-01-10 16:06:39 +01:00
|
|
|
/* the set broadcast-address gets ignored, and we determine a default brd base
|
|
|
|
|
* on the peer IFA_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
|
|
|
if (addr->peer_address != 0u && addr->plen < 31 /* RFC3021 */)
|
platform: generate IFA_BROADCAST address based on the peer IFA_ADDRESS
This is also what iproute2 does ([1]) when creating a default broadcast address
with `ip addr add 192.168.1.5/24 brd + dev eth0`.
Also, kernel does in fib_add_ifaddr() ([2]):
```
__be32 addr = ifa->ifa_local;
__be32 prefix = ifa->ifa_address & mask;
...
/* Add broadcast address, if it is explicitly assigned. */
if (ifa->ifa_broadcast && ifa->ifa_broadcast != htonl(0xFFFFFFFF))
fib_magic(RTM_NEWROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32,
prim, 0);
if (!ipv4_is_zeronet(prefix) && !(ifa->ifa_flags & IFA_F_SECONDARY) &&
(prefix != addr || ifa->ifa_prefixlen < 32)) {
if (!(ifa->ifa_flags & IFA_F_NOPREFIXROUTE))
fib_magic(RTM_NEWROUTE,
dev->flags & IFF_LOOPBACK ? RTN_LOCAL : RTN_UNICAST,
prefix, ifa->ifa_prefixlen, prim,
ifa->ifa_rt_priority);
/* Add network specific broadcasts, when it takes a sense */
if (ifa->ifa_prefixlen < 31) {
fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix, 32,
prim, 0);
fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix | ~mask,
32, prim, 0);
}
}
```
Which means by default kernel already adds those special broadcast routes which
are identical to what we configure with IFA_BROADCAST. However, kernel too bases
them on the peer (IFA_ADDRESS).
[1] https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/ipaddress.c?id=d5391e186f04214315a5a80797c78e50ad9f5271#n2380
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/fib_frontend.c?id=bef1d88263ff769f15aa0e1515cdcede84e61d15#n1109
2020-01-10 16:06:39 +01:00
|
|
|
return nm_platform_ip4_broadcast_address_create(addr->peer_address, addr->plen);
|
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
|
|
|
return 0u;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
2016-12-08 15:12:52 +01:00
|
|
|
#define NMP_SYSCTL_PATHID_NETDIR_unsafe(dirfd, ifname, path) \
|
2019-01-10 12:00:34 +01:00
|
|
|
nm_sprintf_buf_unsafe_a(NM_STRLEN("net:/sys/class/net//\0") + NMP_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
|
|
|
|
2016-12-08 15:12:52 +01:00
|
|
|
#define NMP_SYSCTL_PATHID_NETDIR(dirfd, ifname, path) \
|
2018-11-12 15:23:36 +01:00
|
|
|
nm_sprintf_bufa(NM_STRLEN("net:/sys/class/net//" path "/\0") + NMP_IFNAMSIZ, \
|
2016-12-08 15:12:52 +01:00
|
|
|
"net:/sys/class/net/%s/%s", \
|
|
|
|
|
(ifname), \
|
|
|
|
|
path), \
|
|
|
|
|
(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
|
|
|
|
2017-07-04 22:29:27 +02:00
|
|
|
GPtrArray *nm_platform_link_get_all(NMPlatform *self, gboolean sort_by_name);
|
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);
|
|
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
nm_platform_link_bond_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_BOND, name, 0, NULL, 0, 0, NULL, 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
|
|
|
}
|
|
|
|
|
|
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
|
2021-11-09 13:28:54 +01:00
|
|
|
nm_platform_link_vlan_add(NMPlatform *self,
|
|
|
|
|
const char *name,
|
2019-12-31 13:04:35 +01:00
|
|
|
int parent,
|
|
|
|
|
int vlanid,
|
|
|
|
|
guint32 vlanflags,
|
|
|
|
|
const NMPlatformLink **out_link)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(parent >= 0, -NME_BUG);
|
|
|
|
|
g_return_val_if_fail(vlanid >= 0, -NME_BUG);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-12-31 13:04:35 +01:00
|
|
|
return nm_platform_link_add(self,
|
|
|
|
|
NM_LINK_TYPE_VLAN,
|
|
|
|
|
name,
|
|
|
|
|
parent,
|
|
|
|
|
NULL,
|
|
|
|
|
0,
|
2020-10-23 09:41:01 +02:00
|
|
|
0,
|
2019-12-31 13:04:35 +01:00
|
|
|
&((NMPlatformLnkVlan){
|
|
|
|
|
.id = vlanid,
|
|
|
|
|
.flags = vlanflags,
|
|
|
|
|
}),
|
|
|
|
|
out_link);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
2015-06-20 12:05:01 +02:00
|
|
|
int nm_platform_link_get_master(NMPlatform *self, int slave);
|
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
|
|
|
|
2015-06-24 14:21:27 +02:00
|
|
|
gboolean nm_platform_link_get_unmanaged(NMPlatform *self, int ifindex, gboolean *unmanaged);
|
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_slaves(NMPlatform *self, int ifindex);
|
2015-06-20 12:05:01 +02: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
|
|
|
|
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,
|
|
|
|
|
guint num_vfs,
|
2021-01-10 16:51:37 +01:00
|
|
|
NMOptionBool autoprobe,
|
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);
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_link_set_bridge_vlans(NMPlatform *self,
|
2019-03-16 17:22:35 +01:00
|
|
|
int ifindex,
|
|
|
|
|
gboolean on_master,
|
|
|
|
|
const NMPlatformBridgeVlan *const *vlans);
|
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
|
|
|
|
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_enslave(NMPlatform *self, int master, int slave);
|
|
|
|
|
gboolean nm_platform_link_release(NMPlatform *self, int master, int slave);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-12-09 17:33:30 +01:00
|
|
|
gboolean nm_platform_sysctl_master_set_option(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const char *option,
|
|
|
|
|
const char *value);
|
2021-11-09 13:28:54 +01:00
|
|
|
char *nm_platform_sysctl_master_get_option(NMPlatform *self, int ifindex, const char *option);
|
2015-12-09 17:33:30 +01:00
|
|
|
gboolean nm_platform_sysctl_slave_set_option(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
const char *option,
|
|
|
|
|
const char *value);
|
2021-11-09 13:28:54 +01:00
|
|
|
char *nm_platform_sysctl_slave_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);
|
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);
|
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);
|
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);
|
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);
|
|
|
|
|
guint32 nm_platform_wifi_find_frequency(NMPlatform *self, int ifindex, const guint32 *freqs);
|
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);
|
2022-02-28 18:46:12 +02:00
|
|
|
gboolean nm_platform_wifi_get_csme_conn_info(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
|
|
|
|
NMPlatformCsmeConnInfo *out_conn_info);
|
2022-02-28 22:28:41 +02:00
|
|
|
gboolean nm_platform_wifi_get_device_from_csme(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
|
|
|
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
|
|
|
|
2016-04-06 18:04:26 +02:00
|
|
|
void nm_platform_ip4_address_set_addr(NMPlatformIP4Address *addr, in_addr_t address, guint8 plen);
|
2015-10-10 17:48:32 +02:00
|
|
|
const struct in6_addr *nm_platform_ip6_address_get_peer(const NMPlatformIP6Address *addr);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
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
|
|
|
|
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
|
|
|
|
2020-09-16 13:24:07 +02:00
|
|
|
const NMPlatformIP6Address *
|
|
|
|
|
nm_platform_ip6_address_get(NMPlatform *self, int ifindex, const struct in6_addr *address);
|
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,
|
2014-02-19 16:10:59 -05:00
|
|
|
const char *label);
|
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,
|
2016-02-29 15:36:12 +01:00
|
|
|
guint32 flags);
|
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
|
|
|
|
2020-07-29 13:49:31 +02:00
|
|
|
gboolean nm_platform_ip_address_sync(NMPlatform *self,
|
|
|
|
|
int addr_family,
|
|
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
GPtrArray *known_addresses,
|
|
|
|
|
GPtrArray *addresses_prune);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-07-29 13:49:31 +02:00
|
|
|
GPtrArray *nm_platform_ip_address_get_prune_list(NMPlatform *self,
|
|
|
|
|
int addr_family,
|
2020-07-29 14:06:56 +02:00
|
|
|
int ifindex,
|
|
|
|
|
gboolean exclude_ipv6_temporary_addrs);
|
2020-07-29 13:49:31 +02:00
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
_nm_platform_ip_address_sync(NMPlatform *self,
|
|
|
|
|
int addr_family,
|
|
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
GPtrArray *known_addresses,
|
2020-07-29 13:49:31 +02:00
|
|
|
gboolean full_sync)
|
|
|
|
|
{
|
|
|
|
|
gs_unref_ptrarray GPtrArray *addresses_prune = NULL;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-07-29 14:06:56 +02:00
|
|
|
addresses_prune = nm_platform_ip_address_get_prune_list(self, addr_family, ifindex, !full_sync);
|
|
|
|
|
return nm_platform_ip_address_sync(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
|
|
|
addr_family,
|
2020-09-28 16:03:33 +02:00
|
|
|
ifindex,
|
2020-07-29 14:06:56 +02:00
|
|
|
known_addresses,
|
|
|
|
|
addresses_prune);
|
2020-07-29 13:49:31 +02:00
|
|
|
}
|
2020-07-29 12:46:21 +02:00
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
nm_platform_ip4_address_sync(NMPlatform *self, int ifindex, GPtrArray *known_addresses)
|
|
|
|
|
{
|
2020-07-29 13:49:31 +02:00
|
|
|
return _nm_platform_ip_address_sync(self, AF_INET, ifindex, known_addresses, TRUE);
|
2020-07-29 12:46:21 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
nm_platform_ip6_address_sync(NMPlatform *self,
|
|
|
|
|
int ifindex,
|
2021-11-09 13:28:54 +01:00
|
|
|
GPtrArray *known_addresses,
|
2020-07-29 12:46:21 +02:00
|
|
|
gboolean full_sync)
|
|
|
|
|
{
|
2020-07-29 13:49:31 +02:00
|
|
|
return _nm_platform_ip_address_sync(self, AF_INET6, ifindex, known_addresses, full_sync);
|
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
|
|
|
|
2021-10-08 18:30:56 +02:00
|
|
|
static inline gpointer
|
2020-08-26 21:23:02 +02:00
|
|
|
nm_platform_ip_address_get_peer_address(int addr_family, const NMPlatformIPAddress *addr)
|
|
|
|
|
{
|
|
|
|
|
nm_assert_addr_family(addr_family);
|
|
|
|
|
nm_assert(addr);
|
|
|
|
|
|
|
|
|
|
if (NM_IS_IPv4(addr_family))
|
|
|
|
|
return &((NMPlatformIP4Address *) addr)->peer_address;
|
|
|
|
|
return &((NMPlatformIP6Address *) addr)->peer_address;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
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_ip_route_add(NMPlatform *self, NMPNlmFlags flags, const NMPObject *route);
|
|
|
|
|
int nm_platform_ip4_route_add(NMPlatform *self, NMPNlmFlags flags, const NMPlatformIP4Route *route);
|
|
|
|
|
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,
|
|
|
|
|
NMIPRouteTableSyncMode route_table_sync);
|
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,
|
2017-09-13 16:45:22 +02:00
|
|
|
GPtrArray **out_temporary_not_available);
|
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,
|
|
|
|
|
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);
|
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);
|
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);
|
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);
|
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);
|
2015-10-12 10:27:33 +02:00
|
|
|
const char *
|
|
|
|
|
nm_platform_ip4_address_to_string(const NMPlatformIP4Address *address, char *buf, gsize len);
|
|
|
|
|
const char *
|
|
|
|
|
nm_platform_ip6_address_to_string(const NMPlatformIP6Address *address, char *buf, gsize len);
|
|
|
|
|
const char *nm_platform_ip4_route_to_string(const NMPlatformIP4Route *route, char *buf, gsize len);
|
|
|
|
|
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
|
|
|
|
2014-04-05 18:35:20 +02:00
|
|
|
int nm_platform_link_cmp(const NMPlatformLink *a, const NMPlatformLink *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);
|
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);
|
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);
|
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);
|
2013-09-06 09:58:55 +02:00
|
|
|
int nm_platform_ip4_address_cmp(const NMPlatformIP4Address *a, const NMPlatformIP4Address *b);
|
|
|
|
|
int nm_platform_ip6_address_cmp(const NMPlatformIP6Address *a, const NMPlatformIP6Address *b);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-07-22 15:23:23 +02:00
|
|
|
int nm_platform_ip4_address_pretty_sort_cmp(const NMPlatformIP4Address *a1,
|
|
|
|
|
const NMPlatformIP4Address *a2);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-07-22 15:23:23 +02:00
|
|
|
int nm_platform_ip6_address_pretty_sort_cmp(const NMPlatformIP6Address *a1,
|
|
|
|
|
const NMPlatformIP6Address *a2,
|
|
|
|
|
gboolean prefer_temp);
|
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
|
|
|
|
2017-07-26 10:50:23 +02:00
|
|
|
int nm_platform_ip4_route_cmp(const NMPlatformIP4Route *a,
|
|
|
|
|
const NMPlatformIP4Route *b,
|
|
|
|
|
NMPlatformIPRouteCmpType cmp_type);
|
|
|
|
|
int nm_platform_ip6_route_cmp(const NMPlatformIP6Route *a,
|
|
|
|
|
const NMPlatformIP6Route *b,
|
|
|
|
|
NMPlatformIPRouteCmpType cmp_type);
|
2017-04-13 22:34:32 +02:00
|
|
|
|
|
|
|
|
static inline int
|
2017-07-26 10:50:23 +02:00
|
|
|
nm_platform_ip4_route_cmp_full(const NMPlatformIP4Route *a, const NMPlatformIP4Route *b)
|
2017-04-13 22:34:32 +02:00
|
|
|
{
|
2017-07-26 10:50:23 +02:00
|
|
|
return nm_platform_ip4_route_cmp(a, b, NM_PLATFORM_IP_ROUTE_CMP_TYPE_FULL);
|
2017-04-13 22:34:32 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
2017-07-26 10:50:23 +02:00
|
|
|
nm_platform_ip6_route_cmp_full(const NMPlatformIP6Route *a, const NMPlatformIP6Route *b)
|
2017-04-13 22:34:32 +02:00
|
|
|
{
|
2017-07-26 10:50:23 +02:00
|
|
|
return nm_platform_ip6_route_cmp(a, b, NM_PLATFORM_IP_ROUTE_CMP_TYPE_FULL);
|
2017-04-13 22:34:32 +02:00
|
|
|
}
|
2013-09-06 09:58:55 +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);
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
nm_platform_routing_rule_cmp_full(const NMPlatformRoutingRule *a, const NMPlatformRoutingRule *b)
|
|
|
|
|
{
|
|
|
|
|
return nm_platform_routing_rule_cmp(a, b, NM_PLATFORM_ROUTING_RULE_CMP_TYPE_FULL);
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-15 20:36:35 +01:00
|
|
|
int nm_platform_qdisc_cmp(const NMPlatformQdisc *a, const NMPlatformQdisc *b);
|
2020-05-22 17:49:39 +02:00
|
|
|
int nm_platform_qdisc_cmp_full(const NMPlatformQdisc *a,
|
|
|
|
|
const NMPlatformQdisc *b,
|
|
|
|
|
gboolean compare_handle);
|
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
|
|
|
|
2017-10-17 11:53:08 +02:00
|
|
|
void nm_platform_link_hash_update(const NMPlatformLink *obj, NMHashState *h);
|
|
|
|
|
void nm_platform_ip4_address_hash_update(const NMPlatformIP4Address *obj, NMHashState *h);
|
|
|
|
|
void nm_platform_ip6_address_hash_update(const NMPlatformIP6Address *obj, NMHashState *h);
|
|
|
|
|
void nm_platform_ip4_route_hash_update(const NMPlatformIP4Route *obj,
|
|
|
|
|
NMPlatformIPRouteCmpType cmp_type,
|
2021-11-09 13:28:54 +01:00
|
|
|
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);
|
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);
|
|
|
|
|
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);
|
|
|
|
|
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);
|
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
|
|
|
|
2019-05-30 08:29:19 +02:00
|
|
|
#define NM_PLATFORM_LINK_FLAGS2STR_MAX_LEN ((gsize) 162)
|
|
|
|
|
|
2015-10-26 21:35:18 +01:00
|
|
|
const char *nm_platform_link_flags2str(unsigned flags, char *buf, gsize len);
|
|
|
|
|
const char *nm_platform_link_inet6_addrgenmode2str(guint8 mode, char *buf, gsize len);
|
|
|
|
|
const char *nm_platform_addr_flags2str(unsigned flags, char *buf, gsize len);
|
|
|
|
|
const char *nm_platform_route_scope2str(int scope, char *buf, gsize len);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-04-03 11:42:00 +02:00
|
|
|
int nm_platform_ip_address_cmp_expiry(const NMPlatformIPAddress *a, const NMPlatformIPAddress *b);
|
2020-09-28 16:03:33 +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
|
|
|
|
|
|
|
|
NMEthtoolFeatureStates *nm_platform_ethtool_get_link_features(NMPlatform *self, int ifindex);
|
|
|
|
|
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
|
|
|
|
2021-11-09 13:28:54 +01:00
|
|
|
gboolean nm_platform_ethtool_get_link_coalesce(NMPlatform *self,
|
2020-05-14 09:16:30 +02:00
|
|
|
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
|
|
|
|
2020-05-14 18:27:54 +02:00
|
|
|
gboolean nm_platform_ethtool_get_link_ring(NMPlatform *self, int ifindex, NMEthtoolRingState *ring);
|
|
|
|
|
|
|
|
|
|
gboolean
|
|
|
|
|
nm_platform_ethtool_set_ring(NMPlatform *self, int ifindex, const NMEthtoolRingState *ring);
|
|
|
|
|
|
2021-05-11 15:45:22 +08:00
|
|
|
gboolean
|
|
|
|
|
nm_platform_ethtool_get_link_pause(NMPlatform *self, int ifindex, NMEthtoolPauseState *pause);
|
|
|
|
|
|
|
|
|
|
gboolean
|
|
|
|
|
nm_platform_ethtool_set_pause(NMPlatform *self, int ifindex, const NMEthtoolPauseState *pause);
|
|
|
|
|
|
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
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2021-09-27 07:48:43 +02:00
|
|
|
NMPlatformIP4Route *nm_platform_ip4_address_generate_device_route(const NMPlatformIP4Address *addr,
|
|
|
|
|
int ifindex,
|
|
|
|
|
guint32 route_table,
|
|
|
|
|
guint32 route_metric,
|
2021-12-15 17:23:23 +01:00
|
|
|
gboolean force_commit,
|
2021-09-27 07:48:43 +02:00
|
|
|
NMPlatformIP4Route *dst);
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2021-06-10 22:45:48 +02:00
|
|
|
gboolean nm_platform_ip_address_match(int addr_family,
|
|
|
|
|
const NMPlatformIPAddress *addr,
|
|
|
|
|
NMPlatformMatchFlags match_flag);
|
2020-09-11 12:33:40 +02: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
|
|
|
#endif /* __NETWORKMANAGER_PLATFORM_H__ */
|