NetworkManager/src/devices/nm-device-tun.c

529 lines
18 KiB
C
Raw Normal View History

/* NetworkManager -- Network link manager
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Copyright 2013 - 2015 Red Hat, Inc.
*/
#include "nm-default.h"
#include "nm-device-tun.h"
#include <stdlib.h>
#include <sys/types.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
#include <linux/if_tun.h>
#include "nm-act-request.h"
#include "nm-device-private.h"
#include "nm-ip4-config.h"
#include "platform/nm-platform.h"
2014-09-08 11:50:37 -05:00
#include "nm-device-factory.h"
#include "nm-setting-tun.h"
#include "nm-core-internal.h"
#include "nm-device-logging.h"
_LOG_DECLARE_SELF(NMDeviceTun);
/*****************************************************************************/
NM_GOBJECT_PROPERTIES_DEFINE (NMDeviceTun,
PROP_OWNER,
PROP_GROUP,
PROP_MODE,
PROP_NO_PI,
PROP_VNET_HDR,
PROP_MULTI_QUEUE,
);
typedef struct {
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
NMPlatformLnkTun props;
} NMDeviceTunPrivate;
struct _NMDeviceTun {
NMDevice parent;
NMDeviceTunPrivate _priv;
};
struct _NMDeviceTunClass {
NMDeviceClass parent;
};
G_DEFINE_TYPE (NMDeviceTun, nm_device_tun, NM_TYPE_DEVICE)
#define NM_DEVICE_TUN_GET_PRIVATE(self) _NM_GET_PRIVATE (self, NMDeviceTun, NM_IS_DEVICE_TUN)
/*****************************************************************************/
static void
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
update_properties_from_struct (NMDeviceTun *self,
const NMPlatformLnkTun *props)
{
NMDeviceTunPrivate *priv = NM_DEVICE_TUN_GET_PRIVATE (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
const NMPlatformLnkTun props0 = { };
device/tun: fix reloading tun properties Before the device is setup, we call nm_platform_tun_get_properties() without a valid ifindex. That triggered an assertion [1]. Thereby, change nm_platform_tun_get_properties() to effectively clear the tun properties when we are unable to fetch them. Also, never modify the tun-mode of NMDeviceTun. [1] #0 0x00007f0a4173e81b in g_logv (breakpoint=1) at gmessages.c:324 #1 0x00007f0a4173e81b in g_logv (log_domain=0x561e9264ccf6 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffd71a0d4d0) at gmessages.c:1081 #2 0x00007f0a4173e98f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1119 #3 0x0000561e9241ecec in nm_platform_tun_get_properties (self=0x561e9354ba70 [NMLinuxPlatform], ifindex=0, props=0x7ffd71a0d650) at platform/nm-platform.c:2081 #4 0x0000561e923aad9c in reload_tun_properties (self=0x561e937fb080 [NMDeviceTun]) at devices/nm-device-tun.c:68 #5 0x0000561e923aa795 in realize (device=0x561e937fb080 [NMDeviceTun], plink=0x7ffd71a0d818, error=0x7ffd71a0d798) at devices/nm-device-tun.c:225 #6 0x0000561e923bdc06 in nm_device_realize (self=0x561e937fb080 [NMDeviceTun], plink=0x7ffd71a0d818, out_compatible=0x7ffd71a0d77c, error=0x7ffd71a0d798) at devices/nm-device.c:1713 #7 0x0000561e924ad995 in platform_link_added (self=0x561e9356e230 [NMManager], ifindex=33, plink=0x7ffd71a0d818) at nm-manager.c:1947 #8 0x0000561e924ad717 in _platform_link_cb_idle (data=0x561e937eb940) at nm-manager.c:2029 #9 0x00007f0a41737e3a in g_main_context_dispatch (context=0x561e93547530) at gmain.c:3154 #10 0x00007f0a41737e3a in g_main_context_dispatch (context=context@entry=0x561e93547530) at gmain.c:3769 #11 0x00007f0a417381d0 in g_main_context_iterate (context=0x561e93547530, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #12 0x00007f0a417384f2 in g_main_loop_run (loop=0x561e935475f0) at gmain.c:4034 #13 0x0000561e923ba3f3 in main (argc=1, argv=0x7ffd71a0dc68) at main.c:488 Fixes: 4dbaac4ba24ebc8b257fffe5197cc8e362804a58
2015-12-07 11:06:35 +01:00
core/platform: add support for TUN/TAP netlink support and various cleanup Kernel recently got support for exposing TUN/TAP information on netlink [1], [2], [3]. Add support for it to the platform cache. The advantage of using netlink is that querying sysctl bypasses the order of events of the netlink socket. It is out of sync and racy. For example, platform cache might still think that a tun device exists, but a subsequent lookup at sysfs might fail because the device was deleted in the meantime. Another point is, that we don't get change notifications via sysctl and that it requires various extra syscalls to read the device information. If the tun information is present on netlink, put it into the cache. This bypasses checking sysctl while we keep looking at sysctl for backward compatibility until we require support from kernel. Notes: - we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This deviates from the model of how kernel treats TUN/TAP devices, which makes it more complicated. The link type of a NMPlatformLink instance should match what kernel thinks about the device. Point in case, when parsing RTM_NETLINK messages, we very early need to determine the link type (_linktype_get_type()). However, to determine the type of a TUN/TAP at that point, we need to look into nested netlink attributes which in turn depend on the type (IFLA_INFO_KIND and IFLA_INFO_DATA), or even worse, we would need to look into sysctl for older kernel vesions. Now, the TUN/TAP type is a property of the link type NM_LINK_TYPE_TUN, instead of determining two different link types. - various parts of the API (both kernel's sysctl vs. netlink) and NMDeviceTun vs. NMSettingTun disagree whether the PI is positive (NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted (NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way, but prefer the positive form for internal API at NMPlatformLnkTun.pi. - previously NMDeviceTun.mode could not change after initializing the object. Allow for that to happen, because forcing some properties that are reported by kernel to not change is wrong, in case they might change. Of course, in practice kernel doesn't allow the device to ever change its type, but the type property of the NMDeviceTun should not make that assumption, because, if it actually changes, what would it mean? - note that as of now, new netlink API is not yet merged to mainline Linus tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API for now. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457 [2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b [3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818 https://bugzilla.redhat.com/show_bug.cgi?id=1547213 https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
if (!props) {
/* allow passing %NULL to reset all properties. */
props = &props0;
}
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
g_object_freeze_notify (G_OBJECT (self));
#define CHECK_PROPERTY_CHANGED_VALID(field, prop) \
G_STMT_START { \
if ( priv->props.field != props->field \
|| priv->props.field##_valid != props->field##_valid) { \
priv->props.field##_valid = props->field##_valid; \
priv->props.field = props->field; \
_notify (self, prop); \
} \
} G_STMT_END
#define CHECK_PROPERTY_CHANGED(field, prop) \
G_STMT_START { \
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
if (priv->props.field != props->field) { \
priv->props.field = props->field; \
_notify (self, prop); \
} \
} G_STMT_END
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
CHECK_PROPERTY_CHANGED_VALID (owner, PROP_OWNER);
CHECK_PROPERTY_CHANGED_VALID (group, PROP_GROUP);
CHECK_PROPERTY_CHANGED (type, PROP_MODE);
CHECK_PROPERTY_CHANGED (pi, PROP_NO_PI);
CHECK_PROPERTY_CHANGED (vnet_hdr, PROP_VNET_HDR);
CHECK_PROPERTY_CHANGED (multi_queue, PROP_MULTI_QUEUE);
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
g_object_thaw_notify (G_OBJECT (self));
}
static void
update_properties (NMDeviceTun *self)
{
NMPlatformLnkTun props_storage;
const NMPlatformLnkTun *props = NULL;
int ifindex;
ifindex = nm_device_get_ifindex (NM_DEVICE (self));
if ( ifindex > 0
&& nm_platform_link_tun_get_properties (nm_device_get_platform (NM_DEVICE (self)),
ifindex,
&props_storage))
props = &props_storage;
update_properties_from_struct (self, props);
}
static NMDeviceCapabilities
get_generic_capabilities (NMDevice *dev)
{
return NM_DEVICE_CAP_IS_SOFTWARE;
}
static void
link_changed (NMDevice *device,
const NMPlatformLink *pllink)
{
NM_DEVICE_CLASS (nm_device_tun_parent_class)->link_changed (device, pllink);
update_properties (NM_DEVICE_TUN (device));
}
static gboolean
complete_connection (NMDevice *device,
NMConnection *connection,
const char *specific_object,
NMConnection *const*existing_connections,
GError **error)
{
NMSettingTun *s_tun;
nm_utils_complete_generic (nm_device_get_platform (device),
connection,
NM_SETTING_TUN_SETTING_NAME,
existing_connections,
NULL,
_("TUN connection"),
NULL,
NULL,
TRUE);
s_tun = nm_connection_get_setting_tun (connection);
if (!s_tun) {
g_set_error_literal (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_INVALID_CONNECTION,
"A 'tun' setting is required.");
return FALSE;
}
return TRUE;
}
static void
update_connection (NMDevice *device, NMConnection *connection)
{
NMDeviceTun *self = NM_DEVICE_TUN (device);
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
NMDeviceTunPrivate *priv = NM_DEVICE_TUN_GET_PRIVATE (self);
NMSettingTun *s_tun;
NMSettingTunMode mode;
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
char s_buf[100];
const char *str;
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
/* Note: since we read tun properties from sysctl for older kernels,
* we don't get proper change notifications. Make sure that all our
* tun properties are up to date at this point. We should not do this,
* if we would entirely rely on netlink events. */
update_properties (NM_DEVICE_TUN (device));
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
switch (priv->props.type) {
case IFF_TUN: mode = NM_SETTING_TUN_MODE_TUN; break;
case IFF_TAP: mode = NM_SETTING_TUN_MODE_TAP; break;
default:
/* Huh? */
return;
}
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
s_tun = nm_connection_get_setting_tun (connection);
if (!s_tun) {
s_tun = (NMSettingTun *) nm_setting_tun_new ();
nm_connection_add_setting (connection, (NMSetting *) s_tun);
}
if (mode != nm_setting_tun_get_mode (s_tun))
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
g_object_set (G_OBJECT (s_tun), NM_SETTING_TUN_MODE, (guint) mode, NULL);
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
str = priv->props.owner_valid
? nm_sprintf_buf (s_buf, "%" G_GINT32_FORMAT, priv->props.owner)
: NULL;
if (!nm_streq0 (str, nm_setting_tun_get_owner (s_tun)))
g_object_set (G_OBJECT (s_tun), NM_SETTING_TUN_OWNER, str, NULL);
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
str = priv->props.group_valid
? nm_sprintf_buf (s_buf, "%" G_GINT32_FORMAT, priv->props.group)
: NULL;
if (!nm_streq0 (str, nm_setting_tun_get_group (s_tun)))
g_object_set (G_OBJECT (s_tun), NM_SETTING_TUN_GROUP, str, NULL);
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
if (priv->props.pi != nm_setting_tun_get_pi (s_tun))
g_object_set (G_OBJECT (s_tun), NM_SETTING_TUN_PI, (gboolean) priv->props.pi, NULL);
if (priv->props.vnet_hdr != nm_setting_tun_get_vnet_hdr (s_tun))
g_object_set (G_OBJECT (s_tun), NM_SETTING_TUN_VNET_HDR, (gboolean) priv->props.vnet_hdr, NULL);
if (priv->props.multi_queue != nm_setting_tun_get_multi_queue (s_tun))
g_object_set (G_OBJECT (s_tun), NM_SETTING_TUN_MULTI_QUEUE, (gboolean) priv->props.multi_queue, NULL);
}
static gboolean
create_and_realize (NMDevice *device,
NMConnection *connection,
NMDevice *parent,
const NMPlatformLink **out_plink,
GError **error)
{
const char *iface = nm_device_get_iface (device);
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
NMPlatformLnkTun props = { };
NMSettingTun *s_tun;
gint64 owner;
gint64 group;
int r;
s_tun = nm_connection_get_setting_tun (connection);
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
g_return_val_if_fail (s_tun, FALSE);
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
switch (nm_setting_tun_get_mode (s_tun)) {
case NM_SETTING_TUN_MODE_TAP: props.type = IFF_TAP; break;
case NM_SETTING_TUN_MODE_TUN: props.type = IFF_TUN; break;
default:
g_return_val_if_reached (FALSE);
}
owner = _nm_utils_ascii_str_to_int64 (nm_setting_tun_get_owner (s_tun), 10, 0, G_MAXINT32, -1);
if (owner != -1) {
props.owner_valid = TRUE;
props.owner = owner;
}
group = _nm_utils_ascii_str_to_int64 (nm_setting_tun_get_group (s_tun), 10, 0, G_MAXINT32, -1);
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
if (group != -1) {
props.group_valid = TRUE;
props.group = group;
}
props.pi = nm_setting_tun_get_pi (s_tun);
props.vnet_hdr = nm_setting_tun_get_vnet_hdr (s_tun);
props.multi_queue = nm_setting_tun_get_multi_queue (s_tun);
props.persist = TRUE;
r = nm_platform_link_tun_add (nm_device_get_platform (device),
iface,
&props,
out_plink,
NULL);
if (r < 0) {
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_CREATION_FAILED,
"Failed to create TUN/TAP interface '%s' for '%s': %s",
iface,
nm_connection_get_id (connection),
nm_strerror (r));
return FALSE;
}
return TRUE;
}
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
static gboolean
_same_og (const char *str, gboolean og_valid, guint32 og_num)
{
gint64 v;
v = _nm_utils_ascii_str_to_int64 (str, 10, 0, G_MAXINT32, -1);
return (!og_valid && ( v == (gint64) -1))
|| ( og_valid && (((guint32) v) == og_num ));
}
static gboolean
check_connection_compatible (NMDevice *device, NMConnection *connection, GError **error)
{
NMDeviceTun *self = NM_DEVICE_TUN (device);
NMDeviceTunPrivate *priv = NM_DEVICE_TUN_GET_PRIVATE (self);
NMSettingTunMode mode;
NMSettingTun *s_tun;
if (!NM_DEVICE_CLASS (nm_device_tun_parent_class)->check_connection_compatible (device, connection, error))
return FALSE;
if (nm_device_is_real (device)) {
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
switch (priv->props.type) {
case IFF_TUN: mode = NM_SETTING_TUN_MODE_TUN; break;
case IFF_TAP: mode = NM_SETTING_TUN_MODE_TAP; break;
default:
nm_utils_error_set_literal (error, NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
"invalid tun type on device");
return FALSE;
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
}
s_tun = nm_connection_get_setting_tun (connection);
if (mode != nm_setting_tun_get_mode (s_tun)) {
nm_utils_error_set_literal (error, NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
"tun mode setting mismatches");
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
return FALSE;
}
if (!_same_og (nm_setting_tun_get_owner (s_tun), priv->props.owner_valid, priv->props.owner)) {
nm_utils_error_set_literal (error, NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
"tun owner setting mismatches");
return FALSE;
}
if (!_same_og (nm_setting_tun_get_group (s_tun), priv->props.group_valid, priv->props.group)) {
nm_utils_error_set_literal (error, NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
"tun group setting mismatches");
return FALSE;
}
if (nm_setting_tun_get_pi (s_tun) != priv->props.pi) {
nm_utils_error_set_literal (error, NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
"tun pi setting mismatches");
return FALSE;
}
if (nm_setting_tun_get_vnet_hdr (s_tun) != priv->props.vnet_hdr) {
nm_utils_error_set_literal (error, NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
"tun vnet-hdr setting mismatches");
return FALSE;
}
if (nm_setting_tun_get_multi_queue (s_tun) != priv->props.multi_queue) {
nm_utils_error_set_literal (error, NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
"tun multi-queue setting mismatches");
return FALSE;
}
}
return TRUE;
}
static NMActStageReturn
act_stage1_prepare (NMDevice *device, NMDeviceStateReason *out_failure_reason)
{
NMDeviceTun *self = NM_DEVICE_TUN (device);
NMDeviceTunPrivate *priv = NM_DEVICE_TUN_GET_PRIVATE (self);
NMActStageReturn ret;
ret = NM_DEVICE_CLASS (nm_device_tun_parent_class)->act_stage1_prepare (device, out_failure_reason);
if (ret != NM_ACT_STAGE_RETURN_SUCCESS)
return ret;
/* Nothing to do for TUN devices */
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
if (priv->props.type == IFF_TUN)
return NM_ACT_STAGE_RETURN_SUCCESS;
if (!nm_device_hw_addr_set_cloned (device, nm_device_get_applied_connection (device), FALSE))
return NM_ACT_STAGE_RETURN_FAILURE;
return NM_ACT_STAGE_RETURN_SUCCESS;
}
static void
unrealize_notify (NMDevice *device)
{
NM_DEVICE_CLASS (nm_device_tun_parent_class)->unrealize_notify (device);
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
update_properties_from_struct (NM_DEVICE_TUN (device), NULL);
}
/*****************************************************************************/
static void
get_property (GObject *object, guint prop_id,
GValue *value, GParamSpec *pspec)
{
NMDeviceTun *self = NM_DEVICE_TUN (object);
NMDeviceTunPrivate *priv = NM_DEVICE_TUN_GET_PRIVATE (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
const char *s;
switch (prop_id) {
case PROP_OWNER:
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
g_value_set_int64 (value, priv->props.owner_valid ? (gint64) priv->props.owner : (gint64) -1);
break;
case PROP_GROUP:
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
g_value_set_int64 (value, priv->props.group_valid ? (gint64) priv->props.group : (gint64) -1);
break;
case PROP_MODE:
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
switch (priv->props.type) {
case IFF_TUN: s = "tun"; break;
case IFF_TAP: s = "tap"; break;
default: s = NULL; break;
}
g_value_set_static_string (value, s);
break;
case PROP_NO_PI:
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
g_value_set_boolean (value, !priv->props.pi);
break;
case PROP_VNET_HDR:
g_value_set_boolean (value, priv->props.vnet_hdr);
break;
case PROP_MULTI_QUEUE:
g_value_set_boolean (value, priv->props.multi_queue);
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
/*****************************************************************************/
static void
nm_device_tun_init (NMDeviceTun *self)
{
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
static const NMDBusInterfaceInfoExtended interface_info_device_tun = {
.parent = NM_DEFINE_GDBUS_INTERFACE_INFO_INIT (
NM_DBUS_INTERFACE_DEVICE_TUN,
.signals = NM_DEFINE_GDBUS_SIGNAL_INFOS (
&nm_signal_info_property_changed_legacy,
),
.properties = NM_DEFINE_GDBUS_PROPERTY_INFOS (
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("Owner", "x", NM_DEVICE_TUN_OWNER),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("Group", "x", NM_DEVICE_TUN_GROUP),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("Mode", "s", NM_DEVICE_TUN_MODE),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("NoPi", "b", NM_DEVICE_TUN_NO_PI),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("VnetHdr", "b", NM_DEVICE_TUN_VNET_HDR),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("MultiQueue", "b", NM_DEVICE_TUN_MULTI_QUEUE),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("HwAddress", "s", NM_DEVICE_HW_ADDRESS),
),
),
.legacy_property_changed = TRUE,
};
static void
nm_device_tun_class_init (NMDeviceTunClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMDBusObjectClass *dbus_object_class = NM_DBUS_OBJECT_CLASS (klass);
NMDeviceClass *device_class = NM_DEVICE_CLASS (klass);
object_class->get_property = get_property;
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
dbus_object_class->interface_infos = NM_DBUS_INTERFACE_INFOS (&interface_info_device_tun);
device_class->connection_type_supported = NM_SETTING_TUN_SETTING_NAME;
device_class->connection_type_check_compatible = NM_SETTING_TUN_SETTING_NAME;
device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES (NM_LINK_TYPE_TUN);
device_class->link_changed = link_changed;
device_class->complete_connection = complete_connection;
device_class->check_connection_compatible = check_connection_compatible;
device_class->create_and_realize = create_and_realize;
device_class->get_generic_capabilities = get_generic_capabilities;
device_class->unrealize_notify = unrealize_notify;
device_class->update_connection = update_connection;
device_class->act_stage1_prepare = act_stage1_prepare;
device_class->get_configured_mtu = nm_device_get_configured_mtu_for_wired;
obj_properties[PROP_OWNER] =
g_param_spec_int64 (NM_DEVICE_TUN_OWNER, "", "",
-1, G_MAXUINT32, -1,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
obj_properties[PROP_GROUP] =
g_param_spec_int64 (NM_DEVICE_TUN_GROUP, "", "",
-1, G_MAXUINT32, -1,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
obj_properties[PROP_MODE] =
g_param_spec_string (NM_DEVICE_TUN_MODE, "", "",
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
NULL,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
obj_properties[PROP_NO_PI] =
g_param_spec_boolean (NM_DEVICE_TUN_NO_PI, "", "",
FALSE,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
obj_properties[PROP_VNET_HDR] =
g_param_spec_boolean (NM_DEVICE_TUN_VNET_HDR, "", "",
FALSE,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
obj_properties[PROP_MULTI_QUEUE] =
g_param_spec_boolean (NM_DEVICE_TUN_MULTI_QUEUE, "", "",
FALSE,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
g_object_class_install_properties (object_class, _PROPERTY_ENUMS_LAST, obj_properties);
}
2014-09-08 11:50:37 -05:00
/*****************************************************************************/
2014-09-08 11:50:37 -05:00
#define NM_TYPE_TUN_DEVICE_FACTORY (nm_tun_device_factory_get_type ())
#define NM_TUN_DEVICE_FACTORY(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), NM_TYPE_TUN_DEVICE_FACTORY, NMTunDeviceFactory))
2014-09-08 11:50:37 -05:00
static NMDevice *
create_device (NMDeviceFactory *factory,
const char *iface,
const NMPlatformLink *plink,
NMConnection *connection,
gboolean *out_ignore)
2014-09-08 11:50:37 -05:00
{
core/platform: add support for TUN/TAP netlink support and various cleanup Kernel recently got support for exposing TUN/TAP information on netlink [1], [2], [3]. Add support for it to the platform cache. The advantage of using netlink is that querying sysctl bypasses the order of events of the netlink socket. It is out of sync and racy. For example, platform cache might still think that a tun device exists, but a subsequent lookup at sysfs might fail because the device was deleted in the meantime. Another point is, that we don't get change notifications via sysctl and that it requires various extra syscalls to read the device information. If the tun information is present on netlink, put it into the cache. This bypasses checking sysctl while we keep looking at sysctl for backward compatibility until we require support from kernel. Notes: - we had two link types NM_LINK_TYPE_TAP and NM_LINK_TYPE_TUN. This deviates from the model of how kernel treats TUN/TAP devices, which makes it more complicated. The link type of a NMPlatformLink instance should match what kernel thinks about the device. Point in case, when parsing RTM_NETLINK messages, we very early need to determine the link type (_linktype_get_type()). However, to determine the type of a TUN/TAP at that point, we need to look into nested netlink attributes which in turn depend on the type (IFLA_INFO_KIND and IFLA_INFO_DATA), or even worse, we would need to look into sysctl for older kernel vesions. Now, the TUN/TAP type is a property of the link type NM_LINK_TYPE_TUN, instead of determining two different link types. - various parts of the API (both kernel's sysctl vs. netlink) and NMDeviceTun vs. NMSettingTun disagree whether the PI is positive (NM_SETTING_TUN_PI, IFLA_TUN_PI, NMPlatformLnkTun.pi) or inverted (NM_DEVICE_TUN_NO_PI, IFF_NO_PI). There is no consistent way, but prefer the positive form for internal API at NMPlatformLnkTun.pi. - previously NMDeviceTun.mode could not change after initializing the object. Allow for that to happen, because forcing some properties that are reported by kernel to not change is wrong, in case they might change. Of course, in practice kernel doesn't allow the device to ever change its type, but the type property of the NMDeviceTun should not make that assumption, because, if it actually changes, what would it mean? - note that as of now, new netlink API is not yet merged to mainline Linus tree. Shortcut _parse_lnk_tun() to not accidentally use unstable API for now. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1277457 [2] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1ec010e705934c8acbe7dbf31afc81e60e3d828b [3] https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=118eda77d6602616bc523a17ee45171e879d1818 https://bugzilla.redhat.com/show_bug.cgi?id=1547213 https://github.com/NetworkManager/NetworkManager/pull/77
2018-03-13 15:29:03 +01:00
g_return_val_if_fail (!plink || plink->type == NM_LINK_TYPE_TUN, NULL);
g_return_val_if_fail (!connection || nm_streq0 (nm_connection_get_connection_type (connection), NM_SETTING_TUN_SETTING_NAME), NULL);
2014-09-08 11:50:37 -05:00
return (NMDevice *) g_object_new (NM_TYPE_DEVICE_TUN,
NM_DEVICE_IFACE, iface,
2014-09-08 11:50:37 -05:00
NM_DEVICE_TYPE_DESC, "Tun",
NM_DEVICE_DEVICE_TYPE, NM_DEVICE_TYPE_TUN,
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
NM_DEVICE_LINK_TYPE, (guint) NM_LINK_TYPE_TUN,
2014-09-08 11:50:37 -05:00
NULL);
}
NM_DEVICE_FACTORY_DEFINE_INTERNAL (TUN, Tun, tun,
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
NM_DEVICE_FACTORY_DECLARE_LINK_TYPES (NM_LINK_TYPE_TUN)
NM_DEVICE_FACTORY_DECLARE_SETTING_TYPES (NM_SETTING_TUN_SETTING_NAME),
factory_class->create_device = create_device;
);