fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-05-28 09:38:17 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/libnm-core-impl/nm-setting-ip6-config.c

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

1182 lines
45 KiB
C
Raw Normal View History

all: update deprecated SPDX license identifiers These SPDX license identifiers are deprecated ([1]). Update them. [1] https://spdx.org/licenses/ sed \ -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \ -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \ -i \ $(git grep -l SPDX-License-Identifier -- \ ':(exclude)shared/c-*/' \ ':(exclude)shared/n-*/' \ ':(exclude)shared/systemd/src' \ ':(exclude)src/systemd/src')
2020-12-23 22:21:36 +01:00
/* SPDX-License-Identifier: LGPL-2.1-or-later */
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/*
all: unify format of our Copyright source code comments ```bash readarray -d '' FILES < <( git ls-files -z \ ':(exclude)po' \ ':(exclude)shared/c-rbtree' \ ':(exclude)shared/c-list' \ ':(exclude)shared/c-siphash' \ ':(exclude)shared/c-stdaux' \ ':(exclude)shared/n-acd' \ ':(exclude)shared/n-dhcp4' \ ':(exclude)src/systemd/src' \ ':(exclude)shared/systemd/src' \ ':(exclude)m4' \ ':(exclude)COPYING*' ) sed \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \ -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \ -i \ "${FILES[@]}" echo ">>> untouched Copyright lines" git grep Copyright "${FILES[@]}" echo ">>> Copyright lines with unusual extra" git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved sed \ -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \ -i \ "${FILES[@]}" ``` https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/298
2019-10-01 09:20:35 +02:00
* Copyright (C) 2007 - 2014 Red Hat, Inc.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*/
build: move "libnm-core/" to "src/" and split it "libnm-core/" is rather complicated. It provides a static library that is linked into libnm.so and NetworkManager. It also contains public headers (like "nm-setting.h") which are part of public libnm API. Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which only rely on public API of libnm-core, but are themself static libraries that can be used by anybody who uses libnm-core. And "libnm-core/nm-libnm-core-intern" is used by libnm-core itself. Move "libnm-core/" to "src/". But also split it in different directories so that they have a clearer purpose. The goal is to have a flat directory hierarchy. The "src/libnm-core*/" directories correspond to the different modules (static libraries and set of headers that we have). We have different kinds of such modules because of how we combine various code together. The directory layout now reflects this.
2021-02-12 15:01:09 +01:00
#include "libnm-core-impl/nm-default-libnm-core.h"
all: cleanup includes and let "nm-default.h" include "config.h" - All internal source files (except "examples", which are not internal) should include "config.h" first. As also all internal source files should include "nm-default.h", let "config.h" be included by "nm-default.h" and include "nm-default.h" as first in every source file. We already wanted to include "nm-default.h" before other headers because it might contains some fixes (like "nm-glib.h" compatibility) that is required first. - After including "nm-default.h", we optinally allow for including the corresponding header file for the source file at hand. The idea is to ensure that each header file is self contained. - Don't include "config.h" or "nm-default.h" in any header file (except "nm-sd-adapt.h"). Public headers anyway must not include these headers, and internal headers are never included after "nm-default.h", as of the first previous point. - Include all internal headers with quotes instead of angle brackets. In practice it doesn't matter, because in our public headers we must include other headers with angle brackets. As we use our public headers also to compile our interal source files, effectively the result must be the same. Still do it for consistency. - Except for <config.h> itself. Include it with angle brackets as suggested by https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
2016-02-19 14:57:48 +01:00
build: cleanup default includes - "gsystem-local-alloc.h" and <gio/gio.h> are already included via "nm-default.h". No need to include them separately. - include "nm-macros-internal.h" via "nm-default.h" and drop all explict includes. - in the modified files, ensure that we always include "config.h" and "nm-default.h" first. As second, include the header file for the current source file (if applicable). Then follow external includes and finally internal nm includes. - include nm headers inside source code files with quotes - internal header files don't need to include default headers. They can savely assume that "nm-default.h" is already included and with it glib, nm-glib.h, nm-macros-internal.h, etc.
2016-02-12 14:44:52 +01:00
#include "nm-setting-ip6-config.h"
setting-ip6-config: add token property
2016-04-30 16:48:02 +02:00
#include <arpa/inet.h>
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
#include "nm-setting-private.h"
libnm: refactor to_dbus_fcn() for "ipv6.dns" property The goal is to get rid of gprop_to_dbus_fcn() uses. Note that there is a change in behavior. The "dns" GPtrArray in NMSettingIPConfig is never NULL (the default of the boxed property), thus the previous code always serialized the property, even the empty list. Now, empty dns properties are omitted from D-Bus.
2021-06-29 21:53:55 +02:00
#include "nm-utils-private.h"
libnm: make use of GParamSpecFlags and GParamSpecEnum Make enum- and flags-valued properties use GParamSpecEnum and GParamSpecFlags, for better introspectability/bindability. This requires no changes outside libnm-core/libnm since the expected data size is still the same with g_object_get()/g_object_set(), and GLib will internally convert between int/uint and enum/flags GValues when using g_object_get_property()/g_object_set_property().
2014-06-26 16:47:46 -04:00
#include "nm-core-enum-types.h"
build: move "libnm-core/" to "src/" and split it "libnm-core/" is rather complicated. It provides a static library that is linked into libnm.so and NetworkManager. It also contains public headers (like "nm-setting.h") which are part of public libnm API. Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which only rely on public API of libnm-core, but are themself static libraries that can be used by anybody who uses libnm-core. And "libnm-core/nm-libnm-core-intern" is used by libnm-core itself. Move "libnm-core/" to "src/". But also split it in different directories so that they have a clearer purpose. The goal is to have a flat directory hierarchy. The "src/libnm-core*/" directories correspond to the different modules (static libraries and set of headers that we have). We have different kinds of such modules because of how we combine various code together. The directory layout now reflects this.
2021-02-12 15:01:09 +01:00
#include "libnm-core-intern/nm-core-internal.h"
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* SECTION:nm-setting-ip6-config
* @short_description: Describes IPv6 addressing, routing, and name service properties
*
* The #NMSettingIP6Config object is a #NMSetting subclass that describes
* properties related to IPv6 addressing, routing, and Domain Name Service
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
*
* #NMSettingIP6Config has few properties or methods of its own; it inherits
* almost everything from #NMSettingIPConfig.
*
ipv6: add 'disabled' method Add a new ipv6.method value 'disabled' that completely disables IPv6 for the interface. https://bugzilla.redhat.com/show_bug.cgi?id=1643841
2019-04-26 13:25:21 +02:00
* NetworkManager supports 7 values for the #NMSettingIPConfig:method property
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
* for IPv6. If "auto" is specified then the appropriate automatic method (PPP,
* router advertisement, etc) is used for the device and most other properties
* can be left unset. To force the use of DHCP only, specify "dhcp"; this
* method is only valid for Ethernet- based hardware. If "link-local" is
* specified, then an IPv6 link-local address will be assigned to the interface.
* If "manual" is specified, static IP addressing is used and at least one IP
* address must be given in the "addresses" property. If "ignore" is specified,
* IPv6 configuration is not done. Note: the "shared" method is not yet
ipv6: add 'disabled' method Add a new ipv6.method value 'disabled' that completely disables IPv6 for the interface. https://bugzilla.redhat.com/show_bug.cgi?id=1643841
2019-04-26 13:25:21 +02:00
* supported. If "disabled" is specified, IPv6 is disabled completely for the
* interface.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
NM_GOBJECT_PROPERTIES_DEFINE_BASE(PROP_IP6_PRIVACY,
PROP_ADDR_GEN_MODE,
PROP_TOKEN,
PROP_DHCP_DUID,
device: introduce ipv6.mtu property https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1003 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1231
2022-05-19 15:27:38 -06:00
PROP_RA_TIMEOUT,
PROP_MTU, );
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
typedef struct {
libnm: let NMSettingIPConfigPrivate be tracked by subclasses For our property meta data handling we require that all the meta data is associated with one GType. NMSettingIPConfig is a parent class of NMSettingIP[46]Config. Note that we already have _nm_sett_info_property_override_create_array_ip_config() because the meta data must be initialized together at one place. We will require that we can find the offset for properties based on one offset per type. That is cumbersome, if NMSettingIPConfigPrivate is private itself. Simplify that, by internally sharing NMSettingIPConfigPrivate and let the subclasses embed the private data in their own private data. Optimally we would simply embed the private struct as field into NMSettingIPConfig. But that would be an ABI change as that struct was public before 1.32. Don't change ABI for now, so we have to awkwardly place it into the subclasses private data.
2021-06-28 18:14:04 +02:00
NMSettingIPConfigPrivate parent;
device: introduce ipv6.mtu property https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1003 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1231
2022-05-19 15:27:38 -06:00
char *token;
char *dhcp_duid;
int ip6_privacy;
gint32 addr_gen_mode;
gint32 ra_timeout;
guint32 mtu;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
} NMSettingIP6ConfigPrivate;
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
/**
* NMSettingIP6Config:
*
* IPv6 Settings
*/
struct _NMSettingIP6Config {
NMSettingIPConfig parent;
libnm: add code comment about preserving ABI for libnm GObject structs
2021-06-14 09:26:25 +02:00
/* In the past, this struct was public API. Preserve ABI! */
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
};
struct _NMSettingIP6ConfigClass {
NMSettingIPConfigClass parent;
/* In the past, this struct was public API. Preserve ABI! */
gpointer padding[4];
};
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
G_DEFINE_TYPE(NMSettingIP6Config, nm_setting_ip6_config, NM_TYPE_SETTING_IP_CONFIG)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
#define NM_SETTING_IP6_CONFIG_GET_PRIVATE(o) \
(G_TYPE_INSTANCE_GET_PRIVATE((o), NM_TYPE_SETTING_IP6_CONFIG, NMSettingIP6ConfigPrivate))
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* nm_setting_ip6_config_get_ip6_privacy:
* @setting: the #NMSettingIP6Config
*
* Returns the value contained in the #NMSettingIP6Config:ip6-privacy
* property.
*
* Returns: IPv6 Privacy Extensions configuration value (#NMSettingIP6ConfigPrivacy).
**/
NMSettingIP6ConfigPrivacy
nm_setting_ip6_config_get_ip6_privacy(NMSettingIP6Config *setting)
{
g_return_val_if_fail(NM_IS_SETTING_IP6_CONFIG(setting), NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN);
return NM_SETTING_IP6_CONFIG_GET_PRIVATE(setting)->ip6_privacy;
}
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
/**
* nm_setting_ip6_config_get_addr_gen_mode:
* @setting: the #NMSettingIP6Config
*
* Returns the value contained in the #NMSettingIP6Config:addr-gen-mode
* property.
*
* Returns: IPv6 Address Generation Mode.
*
* Since: 1.2
**/
NMSettingIP6ConfigAddrGenMode
nm_setting_ip6_config_get_addr_gen_mode(NMSettingIP6Config *setting)
{
g_return_val_if_fail(NM_IS_SETTING_IP6_CONFIG(setting),
all: make "ipv6.addr-gen-mode" configurable by global default It can be useful to choose a different "ipv6.addr-gen-mode". And it can be useful to override the default for a set of profiles. For example, in cloud or in a data center, stable-privacy might not be the best choice. Add a mechanism to override the default via global defaults in NetworkManager.conf: # /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf [connection-90-ipv6-addr-gen-mode-override] match-device=type:ethernet ipv6.addr-gen-mode=0 "ipv6.addr-gen-mode" is a special property, because its default depends on the component that configures the profile. - when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode key means to default to "eui64". - when configured via D-Bus, a missing addr-gen-mode property means to default to "stable-privacy". - libnm's ip6-config::addr-gen-mode property defaults to "stable-privacy". - when some tool creates a profile, they either can explicitly set the mode, or they get the default of the underlying mechanisms above. - nm-initrd-generator explicitly sets "eui64" for profiles it creates. - nmcli doesn' explicitly set it, but inherits the default form libnm's ip6-config::addr-gen-mode. - when NM creates a auto-default-connection for ethernet ("Wired connection 1"), it inherits the default from libnm's ip6-config::addr-gen-mode. Global connection defaults only take effect when the per-profile value is set to a special default/unset value. To account for the different cases above, we add two such special values: "default" and "default-or-eui64". That's something we didn't do before, but it seams useful and easy to understand. Also, this neatly expresses the current behaviors we already have. E.g. if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64" is a pretty clear thing. Note that usually we cannot change default values, in particular not for libnm's properties. That is because we don't serialize the default values to D-Bus/keyfile, so if we change the default, we change behavior. Here we change from "stable-privacy" to "default" and from "eui64" to "default-or-eui64". That means, the user only experiences a change in behavior, if they have a ".conf" file that overrides the default. https://bugzilla.redhat.com/show_bug.cgi?id=1743161 https://bugzilla.redhat.com/show_bug.cgi?id=2082682 See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
2022-05-06 16:57:51 +02:00
NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_DEFAULT);
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
return NM_SETTING_IP6_CONFIG_GET_PRIVATE(setting)->addr_gen_mode;
}
setting-ip6-config: add token property
2016-04-30 16:48:02 +02:00
/**
* nm_setting_ip6_config_get_token:
* @setting: the #NMSettingIP6Config
*
* Returns the value contained in the #NMSettingIP6Config:token
* property.
*
* Returns: A string.
*
* Since: 1.4
**/
const char *
nm_setting_ip6_config_get_token(NMSettingIP6Config *setting)
{
g_return_val_if_fail(NM_IS_SETTING_IP6_CONFIG(setting), NULL);
return NM_SETTING_IP6_CONFIG_GET_PRIVATE(setting)->token;
}
libnm-core: add ipv6.dhcp-duid property allow to specify the DUID to be used int the DHCPv6 client identifier option: the dhcp-duid property accepts either a hex string or the special values "lease", "llt", "ll", "stable-llt", "stable-ll" and "stable-uuid". "lease": give priority to the DUID available in the lease file if any, otherwise fallback to a global default dependant on the dhcp client used. This is the default and reflects how the DUID was managed previously. "ll": enforce generation and use of LL type DUID based on the current hardware address. "llt": enforce generation and use of LLT type DUID based on the current hardware address and a stable time field. "stable-ll": enforce generation and use of LL type DUID based on a link layer address derived from the stable id. "stable-llt": enforce generation and use of LLT type DUID based on a link layer address and a timestamp both derived from the stable id. "stable-uuid": enforce generation and use of a UUID type DUID based on a uuid generated from the stable id.
2018-03-06 16:10:01 +01:00
/**
* nm_setting_ip6_config_get_dhcp_duid:
* @setting: the #NMSettingIP6Config
*
* Returns the value contained in the #NMSettingIP6Config:dhcp-duid
* property.
*
* Returns: The configured DUID value to be included in the DHCPv6 requests
* sent to the DHCPv6 servers.
*
* Since: 1.12
**/
const char *
nm_setting_ip6_config_get_dhcp_duid(NMSettingIP6Config *setting)
{
g_return_val_if_fail(NM_IS_SETTING_IP6_CONFIG(setting), NULL);
return NM_SETTING_IP6_CONFIG_GET_PRIVATE(setting)->dhcp_duid;
}
libnm,cli,ifcfg-rh: add ipv6.ra-timeout configuration option
2020-02-13 15:41:35 +01:00
/**
* nm_setting_ip6_config_get_ra_timeout:
* @setting: the #NMSettingIP6Config
*
* Returns: The configured %NM_SETTING_IP6_CONFIG_RA_TIMEOUT value with the
* timeout for router advertisements in seconds.
*
* Since: 1.24
**/
gint32
nm_setting_ip6_config_get_ra_timeout(NMSettingIP6Config *setting)
{
g_return_val_if_fail(NM_IS_SETTING_IP6_CONFIG(setting), 0);
return NM_SETTING_IP6_CONFIG_GET_PRIVATE(setting)->ra_timeout;
}
device: introduce ipv6.mtu property https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1003 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1231
2022-05-19 15:27:38 -06:00
/**
* nm_setting_ip6_config_get_mtu:
* @setting: the #NMSettingIP6Config
*
* Returns: The configured %NM_SETTING_IP6_CONFIG_MTU value for the maximum
* transmission unit.
*
* Since: 1.40
**/
guint32
nm_setting_ip6_config_get_mtu(NMSettingIP6Config *setting)
{
g_return_val_if_fail(NM_IS_SETTING_IP6_CONFIG(setting), 0);
return NM_SETTING_IP6_CONFIG_GET_PRIVATE(setting)->mtu;
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
static gboolean
libnm-core: make nm_setting_verify() take an NMConnection nm_setting_verify() took a GSList of other NMSettings, but really it would just be simpler all around to pass the NMConnection instead... This means that several formerly NMSetting-branded functions that operated on lists-of-settings now get replaced with NMConnection-branded functions instead.
2014-10-21 22:30:31 -04:00
verify(NMSetting *setting, NMConnection *connection, GError **error)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
NMSettingIP6ConfigPrivate *priv = NM_SETTING_IP6_CONFIG_GET_PRIVATE(setting);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSettingIPConfig *s_ip = NM_SETTING_IP_CONFIG(setting);
libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway The gateway is a global property of the IPv4/IPv6 configuration, not an attribute of any particular address. So represent it as such in the API; remove the gateway from NMIPAddress, and add it to NMSettingIPConfig. Behind the scenes, the gateway is still serialized along with the first address in NMSettingIPConfig:addresses, and is deserialized from that if the settings dictionary doesn't contain a 'gateway' key. Adjust nmcli's interactive mode to prompt for IP addresses and gateway separately. (Patch partly from Jirka Klimeš.)
2014-10-20 21:30:56 -04:00
NMSettingVerifyResult ret;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *method;
setting-ip6-config: add token property
2016-04-30 16:48:02 +02:00
gboolean token_needs_normalization = FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway The gateway is a global property of the IPv4/IPv6 configuration, not an attribute of any particular address. So represent it as such in the API; remove the gateway from NMIPAddress, and add it to NMSettingIPConfig. Behind the scenes, the gateway is still serialized along with the first address in NMSettingIPConfig:addresses, and is deserialized from that if the settings dictionary doesn't contain a 'gateway' key. Adjust nmcli's interactive mode to prompt for IP addresses and gateway separately. (Patch partly from Jirka Klimeš.)
2014-10-20 21:30:56 -04:00
ret = NM_SETTING_CLASS(nm_setting_ip6_config_parent_class)->verify(setting, connection, error);
if (ret != NM_SETTING_VERIFY_SUCCESS)
return ret;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
method = nm_setting_ip_config_get_method(s_ip);
/* Base class already checked that it exists */
g_assert(method);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
ipv6: add 'disabled' method Add a new ipv6.method value 'disabled' that completely disables IPv6 for the interface. https://bugzilla.redhat.com/show_bug.cgi?id=1643841
2019-04-26 13:25:21 +02:00
if (nm_streq(method, NM_SETTING_IP6_CONFIG_METHOD_MANUAL)) {
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
if (nm_setting_ip_config_get_num_addresses(s_ip) == 0) {
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
g_set_error(error,
libnm-core: merge NMSetting*Error into NMConnectionError Each setting type was defining its own error type, but most of them had exactly the same three errors ("unknown", "missing property", and "invalid property"), and none of the other values was of much use programmatically anyway. So, this commit merges NMSettingError, NMSettingAdslError, etc, all into NMConnectionError. (The reason for merging into NMConnectionError rather than NMSettingError is that we also already have "NMSettingsError", for errors related to the settings service, so "NMConnectionError" is a less-confusable name for settings/connection errors than "NMSettingError".) Also, make sure that all of the affected error messages are localized, and (where appropriate) prefix them with the relevant property name. Renamed error codes: NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET Remapped error codes: NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY Dropped error codes (were previously defined but unused): NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_MISSING_PROPERTY,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
_("this property cannot be empty for '%s=%s'"),
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
NM_SETTING_IP_CONFIG_METHOD,
method);
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP_CONFIG_ADDRESSES);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
return FALSE;
}
ipv6: add 'disabled' method Add a new ipv6.method value 'disabled' that completely disables IPv6 for the interface. https://bugzilla.redhat.com/show_bug.cgi?id=1643841
2019-04-26 13:25:21 +02:00
} else if (NM_IN_STRSET(method,
NM_SETTING_IP6_CONFIG_METHOD_IGNORE,
NM_SETTING_IP6_CONFIG_METHOD_LINK_LOCAL,
NM_SETTING_IP6_CONFIG_METHOD_SHARED,
NM_SETTING_IP6_CONFIG_METHOD_DISABLED)) {
/* Shared allows IP addresses and DNS; other methods do not */
if (!nm_streq(method, NM_SETTING_IP6_CONFIG_METHOD_SHARED)) {
settings: allow method=shared with manual IPv6 configuration IPv4 already allows setting an address, reusing its prefix for the network it shares connection with. Additionally, for IPv6, the NDP can also share the DNS configuration.
2016-11-01 13:43:01 +01:00
if (nm_setting_ip_config_get_num_dns(s_ip) > 0) {
g_set_error(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
_("this property is not allowed for '%s=%s'"),
NM_SETTING_IP_CONFIG_METHOD,
method);
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP_CONFIG_DNS);
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
settings: allow method=shared with manual IPv6 configuration IPv4 already allows setting an address, reusing its prefix for the network it shares connection with. Additionally, for IPv6, the NDP can also share the DNS configuration.
2016-11-01 13:43:01 +01:00
if (nm_setting_ip_config_get_num_dns_searches(s_ip) > 0) {
g_set_error(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
_("this property is not allowed for '%s=%s'"),
NM_SETTING_IP_CONFIG_METHOD,
method);
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP_CONFIG_DNS_SEARCH);
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
settings: allow method=shared with manual IPv6 configuration IPv4 already allows setting an address, reusing its prefix for the network it shares connection with. Additionally, for IPv6, the NDP can also share the DNS configuration.
2016-11-01 13:43:01 +01:00
if (nm_setting_ip_config_get_num_addresses(s_ip) > 0) {
g_set_error(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
_("this property is not allowed for '%s=%s'"),
NM_SETTING_IP_CONFIG_METHOD,
method);
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP_CONFIG_ADDRESSES);
return FALSE;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
ipv6: add 'disabled' method Add a new ipv6.method value 'disabled' that completely disables IPv6 for the interface. https://bugzilla.redhat.com/show_bug.cgi?id=1643841
2019-04-26 13:25:21 +02:00
} else if (NM_IN_STRSET(method,
NM_SETTING_IP6_CONFIG_METHOD_AUTO,
NM_SETTING_IP6_CONFIG_METHOD_DHCP)) {
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/* nothing to do */
} else {
g_set_error_literal(error,
libnm-core: merge NMSetting*Error into NMConnectionError Each setting type was defining its own error type, but most of them had exactly the same three errors ("unknown", "missing property", and "invalid property"), and none of the other values was of much use programmatically anyway. So, this commit merges NMSettingError, NMSettingAdslError, etc, all into NMConnectionError. (The reason for merging into NMConnectionError rather than NMSettingError is that we also already have "NMSettingsError", for errors related to the settings service, so "NMConnectionError" is a less-confusable name for settings/connection errors than "NMSettingError".) Also, make sure that all of the affected error messages are localized, and (where appropriate) prefix them with the relevant property name. Renamed error codes: NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET Remapped error codes: NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY Dropped error codes (were previously defined but unused): NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
_("property is invalid"));
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP_CONFIG_METHOD);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
if (!NM_IN_SET(priv->addr_gen_mode,
NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_EUI64,
all: make "ipv6.addr-gen-mode" configurable by global default It can be useful to choose a different "ipv6.addr-gen-mode". And it can be useful to override the default for a set of profiles. For example, in cloud or in a data center, stable-privacy might not be the best choice. Add a mechanism to override the default via global defaults in NetworkManager.conf: # /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf [connection-90-ipv6-addr-gen-mode-override] match-device=type:ethernet ipv6.addr-gen-mode=0 "ipv6.addr-gen-mode" is a special property, because its default depends on the component that configures the profile. - when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode key means to default to "eui64". - when configured via D-Bus, a missing addr-gen-mode property means to default to "stable-privacy". - libnm's ip6-config::addr-gen-mode property defaults to "stable-privacy". - when some tool creates a profile, they either can explicitly set the mode, or they get the default of the underlying mechanisms above. - nm-initrd-generator explicitly sets "eui64" for profiles it creates. - nmcli doesn' explicitly set it, but inherits the default form libnm's ip6-config::addr-gen-mode. - when NM creates a auto-default-connection for ethernet ("Wired connection 1"), it inherits the default from libnm's ip6-config::addr-gen-mode. Global connection defaults only take effect when the per-profile value is set to a special default/unset value. To account for the different cases above, we add two such special values: "default" and "default-or-eui64". That's something we didn't do before, but it seams useful and easy to understand. Also, this neatly expresses the current behaviors we already have. E.g. if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64" is a pretty clear thing. Note that usually we cannot change default values, in particular not for libnm's properties. That is because we don't serialize the default values to D-Bus/keyfile, so if we change the default, we change behavior. Here we change from "stable-privacy" to "default" and from "eui64" to "default-or-eui64". That means, the user only experiences a change in behavior, if they have a ".conf" file that overrides the default. https://bugzilla.redhat.com/show_bug.cgi?id=1743161 https://bugzilla.redhat.com/show_bug.cgi?id=2082682 See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
2022-05-06 16:57:51 +02:00
NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_STABLE_PRIVACY,
NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_DEFAULT_OR_EUI64,
NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_DEFAULT)) {
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
g_set_error_literal(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
_("property is invalid"));
libnm: fix error message for invalid ipv6.addr-gen-mode
2017-03-28 19:04:26 +02:00
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE);
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
setting-ip6-config: add token property
2016-04-30 16:48:02 +02:00
if (priv->token) {
if (priv->addr_gen_mode == NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_EUI64) {
struct in6_addr i6_token;
glib-aux: rename IP address related helpers from "nm-inet-utils.h" - name things related to `in_addr_t`, `struct in6_addr`, `NMIPAddr` as `nm_ip4_addr_*()`, `nm_ip6_addr_*()`, `nm_ip_addr_*()`, respectively. - we have a wrapper `nm_inet_ntop()` for `inet_ntop()`. This name of our wrapper is chosen to be familiar with the libc underlying function. With this, also name functions that are about string representations of addresses `nm_inet_*()`, `nm_inet4_*()`, `nm_inet6_*()`. For example, `nm_inet_parse_str()`, `nm_inet_is_normalized()`. <<<< R() { git grep -l "$1" | xargs sed -i "s/\<$1\>/$2/g" } R NM_CMP_DIRECT_IN4ADDR_SAME_PREFIX NM_CMP_DIRECT_IP4_ADDR_SAME_PREFIX R NM_CMP_DIRECT_IN6ADDR_SAME_PREFIX NM_CMP_DIRECT_IP6_ADDR_SAME_PREFIX R NM_UTILS_INET_ADDRSTRLEN NM_INET_ADDRSTRLEN R _nm_utils_inet4_ntop nm_inet4_ntop R _nm_utils_inet6_ntop nm_inet6_ntop R _nm_utils_ip4_get_default_prefix nm_ip4_addr_get_default_prefix R _nm_utils_ip4_get_default_prefix0 nm_ip4_addr_get_default_prefix0 R _nm_utils_ip4_netmask_to_prefix nm_ip4_addr_netmask_to_prefix R _nm_utils_ip4_prefix_to_netmask nm_ip4_addr_netmask_from_prefix R nm_utils_inet4_ntop_dup nm_inet4_ntop_dup R nm_utils_inet6_ntop_dup nm_inet6_ntop_dup R nm_utils_inet_ntop nm_inet_ntop R nm_utils_inet_ntop_dup nm_inet_ntop_dup R nm_utils_ip4_address_clear_host_address nm_ip4_addr_clear_host_address R nm_utils_ip4_address_is_link_local nm_ip4_addr_is_link_local R nm_utils_ip4_address_is_loopback nm_ip4_addr_is_loopback R nm_utils_ip4_address_is_zeronet nm_ip4_addr_is_zeronet R nm_utils_ip4_address_same_prefix nm_ip4_addr_same_prefix R nm_utils_ip4_address_same_prefix_cmp nm_ip4_addr_same_prefix_cmp R nm_utils_ip6_address_clear_host_address nm_ip6_addr_clear_host_address R nm_utils_ip6_address_same_prefix nm_ip6_addr_same_prefix R nm_utils_ip6_address_same_prefix_cmp nm_ip6_addr_same_prefix_cmp R nm_utils_ip6_is_ula nm_ip6_addr_is_ula R nm_utils_ip_address_same_prefix nm_ip_addr_same_prefix R nm_utils_ip_address_same_prefix_cmp nm_ip_addr_same_prefix_cmp R nm_utils_ip_is_site_local nm_ip_addr_is_site_local R nm_utils_ipaddr_is_normalized nm_inet_is_normalized R nm_utils_ipaddr_is_valid nm_inet_is_valid R nm_utils_ipx_address_clear_host_address nm_ip_addr_clear_host_address R nm_utils_parse_inaddr nm_inet_parse_str R nm_utils_parse_inaddr_bin nm_inet_parse_bin R nm_utils_parse_inaddr_bin_full nm_inet_parse_bin_full R nm_utils_parse_inaddr_prefix nm_inet_parse_with_prefix_str R nm_utils_parse_inaddr_prefix_bin nm_inet_parse_with_prefix_bin R test_nm_utils_ip6_address_same_prefix test_nm_ip_addr_same_prefix ./contrib/scripts/nm-code-format.sh -F
2022-08-19 13:15:20 +02:00
char s_token[NM_INET_ADDRSTRLEN];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
setting-ip6-config: add token property
2016-04-30 16:48:02 +02:00
if (inet_pton(AF_INET6, priv->token, &i6_token) != 1
|| !_nm_utils_inet6_is_token(&i6_token)) {
g_set_error_literal(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
_("value is not a valid token"));
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP6_CONFIG_TOKEN);
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
glib-aux: rename IP address related helpers from "nm-inet-utils.h" - name things related to `in_addr_t`, `struct in6_addr`, `NMIPAddr` as `nm_ip4_addr_*()`, `nm_ip6_addr_*()`, `nm_ip_addr_*()`, respectively. - we have a wrapper `nm_inet_ntop()` for `inet_ntop()`. This name of our wrapper is chosen to be familiar with the libc underlying function. With this, also name functions that are about string representations of addresses `nm_inet_*()`, `nm_inet4_*()`, `nm_inet6_*()`. For example, `nm_inet_parse_str()`, `nm_inet_is_normalized()`. <<<< R() { git grep -l "$1" | xargs sed -i "s/\<$1\>/$2/g" } R NM_CMP_DIRECT_IN4ADDR_SAME_PREFIX NM_CMP_DIRECT_IP4_ADDR_SAME_PREFIX R NM_CMP_DIRECT_IN6ADDR_SAME_PREFIX NM_CMP_DIRECT_IP6_ADDR_SAME_PREFIX R NM_UTILS_INET_ADDRSTRLEN NM_INET_ADDRSTRLEN R _nm_utils_inet4_ntop nm_inet4_ntop R _nm_utils_inet6_ntop nm_inet6_ntop R _nm_utils_ip4_get_default_prefix nm_ip4_addr_get_default_prefix R _nm_utils_ip4_get_default_prefix0 nm_ip4_addr_get_default_prefix0 R _nm_utils_ip4_netmask_to_prefix nm_ip4_addr_netmask_to_prefix R _nm_utils_ip4_prefix_to_netmask nm_ip4_addr_netmask_from_prefix R nm_utils_inet4_ntop_dup nm_inet4_ntop_dup R nm_utils_inet6_ntop_dup nm_inet6_ntop_dup R nm_utils_inet_ntop nm_inet_ntop R nm_utils_inet_ntop_dup nm_inet_ntop_dup R nm_utils_ip4_address_clear_host_address nm_ip4_addr_clear_host_address R nm_utils_ip4_address_is_link_local nm_ip4_addr_is_link_local R nm_utils_ip4_address_is_loopback nm_ip4_addr_is_loopback R nm_utils_ip4_address_is_zeronet nm_ip4_addr_is_zeronet R nm_utils_ip4_address_same_prefix nm_ip4_addr_same_prefix R nm_utils_ip4_address_same_prefix_cmp nm_ip4_addr_same_prefix_cmp R nm_utils_ip6_address_clear_host_address nm_ip6_addr_clear_host_address R nm_utils_ip6_address_same_prefix nm_ip6_addr_same_prefix R nm_utils_ip6_address_same_prefix_cmp nm_ip6_addr_same_prefix_cmp R nm_utils_ip6_is_ula nm_ip6_addr_is_ula R nm_utils_ip_address_same_prefix nm_ip_addr_same_prefix R nm_utils_ip_address_same_prefix_cmp nm_ip_addr_same_prefix_cmp R nm_utils_ip_is_site_local nm_ip_addr_is_site_local R nm_utils_ipaddr_is_normalized nm_inet_is_normalized R nm_utils_ipaddr_is_valid nm_inet_is_valid R nm_utils_ipx_address_clear_host_address nm_ip_addr_clear_host_address R nm_utils_parse_inaddr nm_inet_parse_str R nm_utils_parse_inaddr_bin nm_inet_parse_bin R nm_utils_parse_inaddr_bin_full nm_inet_parse_bin_full R nm_utils_parse_inaddr_prefix nm_inet_parse_with_prefix_str R nm_utils_parse_inaddr_prefix_bin nm_inet_parse_with_prefix_bin R test_nm_utils_ip6_address_same_prefix test_nm_ip_addr_same_prefix ./contrib/scripts/nm-code-format.sh -F
2022-08-19 13:15:20 +02:00
if (g_strcmp0(priv->token, nm_inet6_ntop(&i6_token, s_token)))
setting-ip6-config: add token property
2016-04-30 16:48:02 +02:00
token_needs_normalization = TRUE;
} else {
g_set_error_literal(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
_("only makes sense with EUI64 address generation mode"));
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP6_CONFIG_TOKEN);
return FALSE;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: add ipv6.dhcp-duid property allow to specify the DUID to be used int the DHCPv6 client identifier option: the dhcp-duid property accepts either a hex string or the special values "lease", "llt", "ll", "stable-llt", "stable-ll" and "stable-uuid". "lease": give priority to the DUID available in the lease file if any, otherwise fallback to a global default dependant on the dhcp client used. This is the default and reflects how the DUID was managed previously. "ll": enforce generation and use of LL type DUID based on the current hardware address. "llt": enforce generation and use of LLT type DUID based on the current hardware address and a stable time field. "stable-ll": enforce generation and use of LL type DUID based on a link layer address derived from the stable id. "stable-llt": enforce generation and use of LLT type DUID based on a link layer address and a timestamp both derived from the stable id. "stable-uuid": enforce generation and use of a UUID type DUID based on a uuid generated from the stable id.
2018-03-06 16:10:01 +01:00
if (priv->dhcp_duid) {
if (!_nm_utils_dhcp_duid_valid(priv->dhcp_duid, NULL)) {
g_set_error_literal(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
_("invalid DUID"));
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP6_CONFIG_DHCP_DUID);
return FALSE;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
setting-ip6-config: add token property
2016-04-30 16:48:02 +02:00
/* Failures from here on, are NORMALIZABLE_ERROR... */
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
setting-ip6-config: add token property
2016-04-30 16:48:02 +02:00
if (token_needs_normalization) {
g_set_error_literal(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
_("token is not in canonical form"));
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP6_CONFIG_TOKEN);
return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: ip-config: normalize may-fail for disabled IP methods Since commit 7d1709d7f649 ("device: check may_fail when progressing to IP_CHECK") NM correctly checks the may-fail properties to decide whether a connection must fail after the completion of IP configuration. But for ipv4.method=disabled and ipv6.method=ignore the IP configuration is always considered failed and thus setting may-fail=no results in a connection that can never succeed. To prevent such wrong configuration, force may-fail to TRUE for those methods during connection normalization. https://bugzilla.redhat.com/show_bug.cgi?id=1334884
2016-07-01 17:05:42 +02:00
/* Failures from here on are NORMALIZABLE... */
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
ipv6: add 'disabled' method Add a new ipv6.method value 'disabled' that completely disables IPv6 for the interface. https://bugzilla.redhat.com/show_bug.cgi?id=1643841
2019-04-26 13:25:21 +02:00
if (NM_IN_STRSET(method,
NM_SETTING_IP6_CONFIG_METHOD_IGNORE,
NM_SETTING_IP6_CONFIG_METHOD_DISABLED)
libnm-core: ip-config: normalize may-fail for disabled IP methods Since commit 7d1709d7f649 ("device: check may_fail when progressing to IP_CHECK") NM correctly checks the may-fail properties to decide whether a connection must fail after the completion of IP configuration. But for ipv4.method=disabled and ipv6.method=ignore the IP configuration is always considered failed and thus setting may-fail=no results in a connection that can never succeed. To prevent such wrong configuration, force may-fail to TRUE for those methods during connection normalization. https://bugzilla.redhat.com/show_bug.cgi?id=1334884
2016-07-01 17:05:42 +02:00
&& !nm_setting_ip_config_get_may_fail(s_ip)) {
g_set_error_literal(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
ipv6: add 'disabled' method Add a new ipv6.method value 'disabled' that completely disables IPv6 for the interface. https://bugzilla.redhat.com/show_bug.cgi?id=1643841
2019-04-26 13:25:21 +02:00
_("property should be TRUE when method is set to ignore or disabled"));
libnm-core: ip-config: normalize may-fail for disabled IP methods Since commit 7d1709d7f649 ("device: check may_fail when progressing to IP_CHECK") NM correctly checks the may-fail properties to decide whether a connection must fail after the completion of IP configuration. But for ipv4.method=disabled and ipv6.method=ignore the IP configuration is always considered failed and thus setting may-fail=no results in a connection that can never succeed. To prevent such wrong configuration, force may-fail to TRUE for those methods during connection normalization. https://bugzilla.redhat.com/show_bug.cgi?id=1334884
2016-07-01 17:05:42 +02:00
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_IP_CONFIG_MAY_FAIL);
return NM_SETTING_VERIFY_NORMALIZABLE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
return TRUE;
}
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
static GVariant *
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
ip6_dns_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
{
libnm: refactor to_dbus_fcn() for "ipv6.dns" property The goal is to get rid of gprop_to_dbus_fcn() uses. Note that there is a change in behavior. The "dns" GPtrArray in NMSettingIPConfig is never NULL (the default of the boxed property), thus the previous code always serialized the property, even the empty list. Now, empty dns properties are omitted from D-Bus.
2021-06-29 21:53:55 +02:00
GPtrArray *dns;
dns = _nm_setting_ip_config_get_dns_array(NM_SETTING_IP_CONFIG(setting));
if (nm_g_ptr_array_len(dns) == 0)
return NULL;
return _nm_utils_ip6_dns_to_variant((const char *const *) dns->pdata, dns->len);
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
}
static void
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
ip6_dns_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_GPROP_FCN_ARGS _nm_nil)
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
{
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
g_value_take_boxed(to, nm_utils_ip6_dns_from_variant(from));
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
}
static GVariant *
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
ip6_addresses_get(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
{
libnm: unify property-to-dbus handling of NMSetting Merge the function pointer get_func() into to_dbus_fcn(). Previously, get_func() as handled separately from to_dbus_fnc() (formerly synth_func()). The notion was that synth-func would syntetize properties that are D-Bus only. But that distinction does not seem very helpful to me. Instaed, we want to convert a property to D-Bus. Period. The implementation should be handled uniformly. Hence, now that is all done by property_to_dbus(). Note that property_to_dbus() is also called as default implementation for compare-property. At least, for properties that are backed by a GObject property.
2019-04-24 17:41:32 +02:00
gs_unref_ptrarray GPtrArray *addrs = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *gateway;
libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway The gateway is a global property of the IPv4/IPv6 configuration, not an attribute of any particular address. So represent it as such in the API; remove the gateway from NMIPAddress, and add it to NMSettingIPConfig. Behind the scenes, the gateway is still serialized along with the first address in NMSettingIPConfig:addresses, and is deserialized from that if the settings dictionary doesn't contain a 'gateway' key. Adjust nmcli's interactive mode to prompt for IP addresses and gateway separately. (Patch partly from Jirka Klimeš.)
2014-10-20 21:30:56 -04:00
libnm: unify property-to-dbus handling of NMSetting Merge the function pointer get_func() into to_dbus_fcn(). Previously, get_func() as handled separately from to_dbus_fnc() (formerly synth_func()). The notion was that synth-func would syntetize properties that are D-Bus only. But that distinction does not seem very helpful to me. Instaed, we want to convert a property to D-Bus. Period. The implementation should be handled uniformly. Hence, now that is all done by property_to_dbus(). Note that property_to_dbus() is also called as default implementation for compare-property. At least, for properties that are backed by a GObject property.
2019-04-24 17:41:32 +02:00
g_object_get(setting, NM_SETTING_IP_CONFIG_ADDRESSES, &addrs, NULL);
libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway The gateway is a global property of the IPv4/IPv6 configuration, not an attribute of any particular address. So represent it as such in the API; remove the gateway from NMIPAddress, and add it to NMSettingIPConfig. Behind the scenes, the gateway is still serialized along with the first address in NMSettingIPConfig:addresses, and is deserialized from that if the settings dictionary doesn't contain a 'gateway' key. Adjust nmcli's interactive mode to prompt for IP addresses and gateway separately. (Patch partly from Jirka Klimeš.)
2014-10-20 21:30:56 -04:00
gateway = nm_setting_ip_config_get_gateway(NM_SETTING_IP_CONFIG(setting));
libnm: unify property-to-dbus handling of NMSetting Merge the function pointer get_func() into to_dbus_fcn(). Previously, get_func() as handled separately from to_dbus_fnc() (formerly synth_func()). The notion was that synth-func would syntetize properties that are D-Bus only. But that distinction does not seem very helpful to me. Instaed, we want to convert a property to D-Bus. Period. The implementation should be handled uniformly. Hence, now that is all done by property_to_dbus(). Note that property_to_dbus() is also called as default implementation for compare-property. At least, for properties that are backed by a GObject property.
2019-04-24 17:41:32 +02:00
return nm_utils_ip6_addresses_to_variant(addrs, gateway);
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
}
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
static gboolean
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
ip6_addresses_set(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
{
libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway The gateway is a global property of the IPv4/IPv6 configuration, not an attribute of any particular address. So represent it as such in the API; remove the gateway from NMIPAddress, and add it to NMSettingIPConfig. Behind the scenes, the gateway is still serialized along with the first address in NMSettingIPConfig:addresses, and is deserialized from that if the settings dictionary doesn't contain a 'gateway' key. Adjust nmcli's interactive mode to prompt for IP addresses and gateway separately. (Patch partly from Jirka Klimeš.)
2014-10-20 21:30:56 -04:00
GPtrArray *addrs;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
char *gateway = NULL;
libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway The gateway is a global property of the IPv4/IPv6 configuration, not an attribute of any particular address. So represent it as such in the API; remove the gateway from NMIPAddress, and add it to NMSettingIPConfig. Behind the scenes, the gateway is still serialized along with the first address in NMSettingIPConfig:addresses, and is deserialized from that if the settings dictionary doesn't contain a 'gateway' key. Adjust nmcli's interactive mode to prompt for IP addresses and gateway separately. (Patch partly from Jirka Klimeš.)
2014-10-20 21:30:56 -04:00
libnm: add out_is_modified argument to from_dbus_fcn() to detect modification Note that most implementations use g_object_set(), and it's not easy to detect modification. In those cases, we assume that modification happened -- just like also the GObject setter will emit a notification (as none of our properties use G_PARAM_EXPLICIT_NOTIFY).
2021-07-27 10:27:44 +02:00
if (!_nm_setting_use_legacy_property(setting, connection_dict, "addresses", "address-data")) {
*out_is_modified = FALSE;
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
return TRUE;
libnm: add out_is_modified argument to from_dbus_fcn() to detect modification Note that most implementations use g_object_set(), and it's not easy to detect modification. In those cases, we assume that modification happened -- just like also the GObject setter will emit a notification (as none of our properties use G_PARAM_EXPLICIT_NOTIFY).
2021-07-27 10:27:44 +02:00
}
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
addrs = nm_utils_ip6_addresses_from_variant(value, &gateway);
libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway The gateway is a global property of the IPv4/IPv6 configuration, not an attribute of any particular address. So represent it as such in the API; remove the gateway from NMIPAddress, and add it to NMSettingIPConfig. Behind the scenes, the gateway is still serialized along with the first address in NMSettingIPConfig:addresses, and is deserialized from that if the settings dictionary doesn't contain a 'gateway' key. Adjust nmcli's interactive mode to prompt for IP addresses and gateway separately. (Patch partly from Jirka Klimeš.)
2014-10-20 21:30:56 -04:00
libnm-core: change how new and legacy properties are serialized Although libnm filters out properties received from the daemon that it doesn't understand, there may be other clients that do not. In particular, a client might call GetSettings() on a connection, update the ipv4.addresses property in the returned dictionary, and then pass the dictionary to Update(). In that case, the updated dictionary would contain ipv4.address-data, but it would not reflect the changes the client intended to make. Fix this by changing the daemon side to prefer the legacy properties to the new ones if both are set, and changing the client side to not send the legacy properties (since we don't support new clients talking to old servers anyway).
2014-11-14 11:46:19 -05:00
g_object_set(setting,
NM_SETTING_IP_CONFIG_ADDRESSES,
addrs,
NM_SETTING_IP_CONFIG_GATEWAY,
gateway,
NULL);
libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway The gateway is a global property of the IPv4/IPv6 configuration, not an attribute of any particular address. So represent it as such in the API; remove the gateway from NMIPAddress, and add it to NMSettingIPConfig. Behind the scenes, the gateway is still serialized along with the first address in NMSettingIPConfig:addresses, and is deserialized from that if the settings dictionary doesn't contain a 'gateway' key. Adjust nmcli's interactive mode to prompt for IP addresses and gateway separately. (Patch partly from Jirka Klimeš.)
2014-10-20 21:30:56 -04:00
g_ptr_array_unref(addrs);
libnm-core: change how new and legacy properties are serialized Although libnm filters out properties received from the daemon that it doesn't understand, there may be other clients that do not. In particular, a client might call GetSettings() on a connection, update the ipv4.addresses property in the returned dictionary, and then pass the dictionary to Update(). In that case, the updated dictionary would contain ipv4.address-data, but it would not reflect the changes the client intended to make. Fix this by changing the daemon side to prefer the legacy properties to the new ones if both are set, and changing the client side to not send the legacy properties (since we don't support new clients talking to old servers anyway).
2014-11-14 11:46:19 -05:00
g_free(gateway);
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
return TRUE;
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
}
static GVariant *
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
ip6_address_data_get(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
{
libnm: pass serialization flags to settings synth_func() We will need access to the serialization flags from within the synth_func(). That will be for WireGuard's peers. Peers are a list of complex, structured elements, and some fields (the peer's preshared-key) are secret and others are not. So when serializing the peers, we need to know whether to include secrets or not. Instead of letting _nm_setting_to_dbus() check the flags, pass them down. While at it, don't pass the property_name argument. Instead, pass the entire meta-data information we have. Most synth functions don't care about the property or the name either way. But we should not pre-filter information that we have at hand. Just pass it to the synth function. If the synth function would be public API, that would be a reason to be careful about what we pass. But it isn't and it only has one caller. So passing it along is fine. Also, do it now when adding the flags argument, as we touch all synth implementations anyway.
2019-01-02 15:54:18 +01:00
gs_unref_ptrarray GPtrArray *addrs = NULL;
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
libnm: Refactor NM_CONNECTION_SERIALIZE_* flags nm-settings-connection.c has code similar to this in two places: /* FIXME: improve NMConnection API so we can avoid the overhead of cloning the connection, * in particular if there are no secrets to begin with. */ connection_cloned = nm_simple_connection_new_clone(new); /* Clear out unwanted secrets */ _nm_connection_clear_secrets_by_secret_flags(connection_cloned, NM_SETTING_SECRET_FLAG_NOT_SAVED | NM_SETTING_SECRET_FLAG_AGENT_OWNED); secrets = nm_g_variant_ref_sink( nm_connection_to_dbus(connection_cloned, NM_CONNECTION_SERIALIZE_ONLY_SECRETS)); It seems the secrets filtering can be done by nm_connection_to_dbus() if the NM_CONNECTION_SERIALIZE_* flags are extended. The current set of flags contains flags that start with NO, ONLY and WITH prefixes, which makes it useless for combining the flags because most combinations of more than one flag don't have a clear interpretation. So they're mostly useful when used alone, i.e. you'd need to add a new enum value for each new subset of settings to be serialized. To get the most flexibility from a small set of flags they should either all be of the WITH_* type or NO_* type. In the former case they could be combined to extend the subset of properties serialized, in the latter case each flag would reduce the subset. After trying both options I found it's easier to adapt the current set of flags to the WITH_* schema while keeping binary and source compatibility. This commit changes the set of flags in the following way: NM_CONNECTION_SERIALIZE_ALL is kept for compatibility but is equivalent to a combination of other flags. NM_CONNECTION_SERIALIZE_WITH_NON_SECRET is added with the same value as NM_CONNECTION_SERIALIZE_NO_SECRETS, it implies that non-secret properties are included but doesn't prevent including other properties. Since it couldn't be meaningfully combined with any other flag this change shouldn't break compatibility. Similarly NM_CONNECTION_SERIALIZE_WITH_SECRETS is added with the same value as existing NM_CONNECTION_SERIALIZE_ONLY_SECRETS with the same consideration about compatibility. NM_CONNECTION_SERIALIZE_WITH_SECRETS_AGENT_OWNED and the new NM_CONNECTION_SERIALIZE_WITH_SECRETS_SYSTEM_OWNED and NM_CONNECTION_SERIALIZE_WITH_SECRETS_NOT_SAVED add only subsets of secrets and can be combined. For backwards compatibility NM_CONNECTION_SERIALIZE_ONLY_SECRETS is basically ignored when either of these three is present, so that the value: ..ONLY_SECRETS | ..AGENT_OWNED works as previously.
2021-03-25 16:39:35 +01:00
if (!_nm_connection_serialize_non_secret(flags))
libnm: pass serialization flags to settings synth_func() We will need access to the serialization flags from within the synth_func(). That will be for WireGuard's peers. Peers are a list of complex, structured elements, and some fields (the peer's preshared-key) are secret and others are not. So when serializing the peers, we need to know whether to include secrets or not. Instead of letting _nm_setting_to_dbus() check the flags, pass them down. While at it, don't pass the property_name argument. Instead, pass the entire meta-data information we have. Most synth functions don't care about the property or the name either way. But we should not pre-filter information that we have at hand. Just pass it to the synth function. If the synth function would be public API, that would be a reason to be careful about what we pass. But it isn't and it only has one caller. So passing it along is fine. Also, do it now when adding the flags argument, as we touch all synth implementations anyway.
2019-01-02 15:54:18 +01:00
return NULL;
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
libnm: pass serialization flags to settings synth_func() We will need access to the serialization flags from within the synth_func(). That will be for WireGuard's peers. Peers are a list of complex, structured elements, and some fields (the peer's preshared-key) are secret and others are not. So when serializing the peers, we need to know whether to include secrets or not. Instead of letting _nm_setting_to_dbus() check the flags, pass them down. While at it, don't pass the property_name argument. Instead, pass the entire meta-data information we have. Most synth functions don't care about the property or the name either way. But we should not pre-filter information that we have at hand. Just pass it to the synth function. If the synth function would be public API, that would be a reason to be careful about what we pass. But it isn't and it only has one caller. So passing it along is fine. Also, do it now when adding the flags argument, as we touch all synth implementations anyway.
2019-01-02 15:54:18 +01:00
g_object_get(setting, NM_SETTING_IP_CONFIG_ADDRESSES, &addrs, NULL);
return nm_utils_ip_addresses_to_variant(addrs);
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
}
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
static gboolean
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
ip6_address_data_set(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
{
GPtrArray *addrs;
libnm-core: change how new and legacy properties are serialized Although libnm filters out properties received from the daemon that it doesn't understand, there may be other clients that do not. In particular, a client might call GetSettings() on a connection, update the ipv4.addresses property in the returned dictionary, and then pass the dictionary to Update(). In that case, the updated dictionary would contain ipv4.address-data, but it would not reflect the changes the client intended to make. Fix this by changing the daemon side to prefer the legacy properties to the new ones if both are set, and changing the client side to not send the legacy properties (since we don't support new clients talking to old servers anyway).
2014-11-14 11:46:19 -05:00
/* Ignore 'address-data' if we're going to process 'addresses' */
libnm: add out_is_modified argument to from_dbus_fcn() to detect modification Note that most implementations use g_object_set(), and it's not easy to detect modification. In those cases, we assume that modification happened -- just like also the GObject setter will emit a notification (as none of our properties use G_PARAM_EXPLICIT_NOTIFY).
2021-07-27 10:27:44 +02:00
if (_nm_setting_use_legacy_property(setting, connection_dict, "addresses", "address-data")) {
*out_is_modified = FALSE;
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
return TRUE;
libnm: add out_is_modified argument to from_dbus_fcn() to detect modification Note that most implementations use g_object_set(), and it's not easy to detect modification. In those cases, we assume that modification happened -- just like also the GObject setter will emit a notification (as none of our properties use G_PARAM_EXPLICIT_NOTIFY).
2021-07-27 10:27:44 +02:00
}
libnm-core: change how new and legacy properties are serialized Although libnm filters out properties received from the daemon that it doesn't understand, there may be other clients that do not. In particular, a client might call GetSettings() on a connection, update the ipv4.addresses property in the returned dictionary, and then pass the dictionary to Update(). In that case, the updated dictionary would contain ipv4.address-data, but it would not reflect the changes the client intended to make. Fix this by changing the daemon side to prefer the legacy properties to the new ones if both are set, and changing the client side to not send the legacy properties (since we don't support new clients talking to old servers anyway).
2014-11-14 11:46:19 -05:00
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
addrs = nm_utils_ip_addresses_from_variant(value, AF_INET6);
g_object_set(setting, NM_SETTING_IP_CONFIG_ADDRESSES, addrs, NULL);
g_ptr_array_unref(addrs);
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
return TRUE;
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
}
static GVariant *
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
ip6_routes_get(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
{
libnm: unify property-to-dbus handling of NMSetting Merge the function pointer get_func() into to_dbus_fcn(). Previously, get_func() as handled separately from to_dbus_fnc() (formerly synth_func()). The notion was that synth-func would syntetize properties that are D-Bus only. But that distinction does not seem very helpful to me. Instaed, we want to convert a property to D-Bus. Period. The implementation should be handled uniformly. Hence, now that is all done by property_to_dbus(). Note that property_to_dbus() is also called as default implementation for compare-property. At least, for properties that are backed by a GObject property.
2019-04-24 17:41:32 +02:00
gs_unref_ptrarray GPtrArray *routes = NULL;
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
libnm: unify property-to-dbus handling of NMSetting Merge the function pointer get_func() into to_dbus_fcn(). Previously, get_func() as handled separately from to_dbus_fnc() (formerly synth_func()). The notion was that synth-func would syntetize properties that are D-Bus only. But that distinction does not seem very helpful to me. Instaed, we want to convert a property to D-Bus. Period. The implementation should be handled uniformly. Hence, now that is all done by property_to_dbus(). Note that property_to_dbus() is also called as default implementation for compare-property. At least, for properties that are backed by a GObject property.
2019-04-24 17:41:32 +02:00
g_object_get(setting, NM_SETTING_IP_CONFIG_ROUTES, &routes, NULL);
return nm_utils_ip6_routes_to_variant(routes);
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
}
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
static gboolean
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
ip6_routes_set(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
{
GPtrArray *routes;
libnm: add out_is_modified argument to from_dbus_fcn() to detect modification Note that most implementations use g_object_set(), and it's not easy to detect modification. In those cases, we assume that modification happened -- just like also the GObject setter will emit a notification (as none of our properties use G_PARAM_EXPLICIT_NOTIFY).
2021-07-27 10:27:44 +02:00
if (!_nm_setting_use_legacy_property(setting, connection_dict, "routes", "route-data")) {
*out_is_modified = FALSE;
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
return TRUE;
libnm: add out_is_modified argument to from_dbus_fcn() to detect modification Note that most implementations use g_object_set(), and it's not easy to detect modification. In those cases, we assume that modification happened -- just like also the GObject setter will emit a notification (as none of our properties use G_PARAM_EXPLICIT_NOTIFY).
2021-07-27 10:27:44 +02:00
}
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
routes = nm_utils_ip6_routes_from_variant(value);
libnm: pass full property meta data to from_dbus_fcn() hook
2021-06-29 23:51:46 +02:00
g_object_set(setting, property_info->name, routes, NULL);
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
g_ptr_array_unref(routes);
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
return TRUE;
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
}
static GVariant *
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
ip6_route_data_get(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
{
libnm: pass serialization flags to settings synth_func() We will need access to the serialization flags from within the synth_func(). That will be for WireGuard's peers. Peers are a list of complex, structured elements, and some fields (the peer's preshared-key) are secret and others are not. So when serializing the peers, we need to know whether to include secrets or not. Instead of letting _nm_setting_to_dbus() check the flags, pass them down. While at it, don't pass the property_name argument. Instead, pass the entire meta-data information we have. Most synth functions don't care about the property or the name either way. But we should not pre-filter information that we have at hand. Just pass it to the synth function. If the synth function would be public API, that would be a reason to be careful about what we pass. But it isn't and it only has one caller. So passing it along is fine. Also, do it now when adding the flags argument, as we touch all synth implementations anyway.
2019-01-02 15:54:18 +01:00
gs_unref_ptrarray GPtrArray *routes = NULL;
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
libnm: Refactor NM_CONNECTION_SERIALIZE_* flags nm-settings-connection.c has code similar to this in two places: /* FIXME: improve NMConnection API so we can avoid the overhead of cloning the connection, * in particular if there are no secrets to begin with. */ connection_cloned = nm_simple_connection_new_clone(new); /* Clear out unwanted secrets */ _nm_connection_clear_secrets_by_secret_flags(connection_cloned, NM_SETTING_SECRET_FLAG_NOT_SAVED | NM_SETTING_SECRET_FLAG_AGENT_OWNED); secrets = nm_g_variant_ref_sink( nm_connection_to_dbus(connection_cloned, NM_CONNECTION_SERIALIZE_ONLY_SECRETS)); It seems the secrets filtering can be done by nm_connection_to_dbus() if the NM_CONNECTION_SERIALIZE_* flags are extended. The current set of flags contains flags that start with NO, ONLY and WITH prefixes, which makes it useless for combining the flags because most combinations of more than one flag don't have a clear interpretation. So they're mostly useful when used alone, i.e. you'd need to add a new enum value for each new subset of settings to be serialized. To get the most flexibility from a small set of flags they should either all be of the WITH_* type or NO_* type. In the former case they could be combined to extend the subset of properties serialized, in the latter case each flag would reduce the subset. After trying both options I found it's easier to adapt the current set of flags to the WITH_* schema while keeping binary and source compatibility. This commit changes the set of flags in the following way: NM_CONNECTION_SERIALIZE_ALL is kept for compatibility but is equivalent to a combination of other flags. NM_CONNECTION_SERIALIZE_WITH_NON_SECRET is added with the same value as NM_CONNECTION_SERIALIZE_NO_SECRETS, it implies that non-secret properties are included but doesn't prevent including other properties. Since it couldn't be meaningfully combined with any other flag this change shouldn't break compatibility. Similarly NM_CONNECTION_SERIALIZE_WITH_SECRETS is added with the same value as existing NM_CONNECTION_SERIALIZE_ONLY_SECRETS with the same consideration about compatibility. NM_CONNECTION_SERIALIZE_WITH_SECRETS_AGENT_OWNED and the new NM_CONNECTION_SERIALIZE_WITH_SECRETS_SYSTEM_OWNED and NM_CONNECTION_SERIALIZE_WITH_SECRETS_NOT_SAVED add only subsets of secrets and can be combined. For backwards compatibility NM_CONNECTION_SERIALIZE_ONLY_SECRETS is basically ignored when either of these three is present, so that the value: ..ONLY_SECRETS | ..AGENT_OWNED works as previously.
2021-03-25 16:39:35 +01:00
if (!_nm_connection_serialize_non_secret(flags))
libnm: pass serialization flags to settings synth_func() We will need access to the serialization flags from within the synth_func(). That will be for WireGuard's peers. Peers are a list of complex, structured elements, and some fields (the peer's preshared-key) are secret and others are not. So when serializing the peers, we need to know whether to include secrets or not. Instead of letting _nm_setting_to_dbus() check the flags, pass them down. While at it, don't pass the property_name argument. Instead, pass the entire meta-data information we have. Most synth functions don't care about the property or the name either way. But we should not pre-filter information that we have at hand. Just pass it to the synth function. If the synth function would be public API, that would be a reason to be careful about what we pass. But it isn't and it only has one caller. So passing it along is fine. Also, do it now when adding the flags argument, as we touch all synth implementations anyway.
2019-01-02 15:54:18 +01:00
return NULL;
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
libnm: pass serialization flags to settings synth_func() We will need access to the serialization flags from within the synth_func(). That will be for WireGuard's peers. Peers are a list of complex, structured elements, and some fields (the peer's preshared-key) are secret and others are not. So when serializing the peers, we need to know whether to include secrets or not. Instead of letting _nm_setting_to_dbus() check the flags, pass them down. While at it, don't pass the property_name argument. Instead, pass the entire meta-data information we have. Most synth functions don't care about the property or the name either way. But we should not pre-filter information that we have at hand. Just pass it to the synth function. If the synth function would be public API, that would be a reason to be careful about what we pass. But it isn't and it only has one caller. So passing it along is fine. Also, do it now when adding the flags argument, as we touch all synth implementations anyway.
2019-01-02 15:54:18 +01:00
g_object_get(setting, NM_SETTING_IP_CONFIG_ROUTES, &routes, NULL);
return nm_utils_ip_routes_to_variant(routes);
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
}
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
static gboolean
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
ip6_route_data_set(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
{
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
GPtrArray *routes;
libnm-core: change how new and legacy properties are serialized Although libnm filters out properties received from the daemon that it doesn't understand, there may be other clients that do not. In particular, a client might call GetSettings() on a connection, update the ipv4.addresses property in the returned dictionary, and then pass the dictionary to Update(). In that case, the updated dictionary would contain ipv4.address-data, but it would not reflect the changes the client intended to make. Fix this by changing the daemon side to prefer the legacy properties to the new ones if both are set, and changing the client side to not send the legacy properties (since we don't support new clients talking to old servers anyway).
2014-11-14 11:46:19 -05:00
/* Ignore 'route-data' if we're going to process 'routes' */
libnm: add out_is_modified argument to from_dbus_fcn() to detect modification Note that most implementations use g_object_set(), and it's not easy to detect modification. In those cases, we assume that modification happened -- just like also the GObject setter will emit a notification (as none of our properties use G_PARAM_EXPLICIT_NOTIFY).
2021-07-27 10:27:44 +02:00
if (_nm_setting_use_legacy_property(setting, connection_dict, "routes", "route-data")) {
*out_is_modified = FALSE;
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
return TRUE;
libnm: add out_is_modified argument to from_dbus_fcn() to detect modification Note that most implementations use g_object_set(), and it's not easy to detect modification. In those cases, we assume that modification happened -- just like also the GObject setter will emit a notification (as none of our properties use G_PARAM_EXPLICIT_NOTIFY).
2021-07-27 10:27:44 +02:00
}
libnm-core: change how new and legacy properties are serialized Although libnm filters out properties received from the daemon that it doesn't understand, there may be other clients that do not. In particular, a client might call GetSettings() on a connection, update the ipv4.addresses property in the returned dictionary, and then pass the dictionary to Update(). In that case, the updated dictionary would contain ipv4.address-data, but it would not reflect the changes the client intended to make. Fix this by changing the daemon side to prefer the legacy properties to the new ones if both are set, and changing the client side to not send the legacy properties (since we don't support new clients talking to old servers anyway).
2014-11-14 11:46:19 -05:00
libnm-core, libnm, core: add AddressData and RouteData properties Add AddressData and RouteData properties to NMSettingIPConfig and NMIP[46]Config. These are like the existing "addresses" and "routes" properties, but using strings and containing additional attributes, like NMIPAddress and NMIPRoute. This only affects the D-Bus representations; there are no API changes to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the additional information is just added to the existing 'addresses' and 'routes' properties. NMSettingIP4Config and NMSettingIP6Config now always generate both old-style data ('addresses', 'address-labels', 'routes') and new-style data ('address-data', 'gateway', 'route-data') when serializing to D-Bus, for backward compatibility. When deserializing, they will fill in the 'addresses' and 'routes' properties from the new-style data if it is present (ignoring the old-style data), or from the old-style data if the new-style isn't present. The daemon-side NMIP4Config and NMIP6Config always emit changes for both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The libnm-side classes initially listen for changes on both properties, but start ignoring the 'Addresses' and 'Routes' properties once they know the daemon is also providing 'AddressData' and 'RouteData'.
2014-10-21 08:33:18 -04:00
routes = nm_utils_ip_routes_from_variant(value, AF_INET6);
g_object_set(setting, NM_SETTING_IP_CONFIG_ROUTES, routes, NULL);
g_ptr_array_unref(routes);
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
return TRUE;
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
}
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
/*****************************************************************************/
static void
nm_setting_ip6_config_init(NMSettingIP6Config *setting)
{
libnm: don't have G_PARAM_CONSTRUCT properties in NMSetting instances G_PARAM_CONSTRUCT cause to explicitly initialize the property during object construction. This is an unnecessary overhead that we can easily avoid. The overhead is because G_PARAM_CONSTRUCT parameters are always set with g_object_set() before calling constructed(). Even if they are not specified during g_object_new(), in which case it calls set with the property's default value. This also requires g_object_new() to iterate all properties to find and sort the construct properties. NMSetting are supposed to be simple classes. They don't need to have their properties initialized before object construction completes. Especially if the default values are NULL or zero, in which case there is nothing to do. If the default value is not NULL or zero, we need to initialize the field instead in the nm_setting*_init() function.
2019-12-12 11:52:11 +01:00
NMSettingIP6ConfigPrivate *priv = NM_SETTING_IP6_CONFIG_GET_PRIVATE(setting);
libnm: let NMSettingIPConfigPrivate be tracked by subclasses For our property meta data handling we require that all the meta data is associated with one GType. NMSettingIPConfig is a parent class of NMSettingIP[46]Config. Note that we already have _nm_sett_info_property_override_create_array_ip_config() because the meta data must be initialized together at one place. We will require that we can find the offset for properties based on one offset per type. That is cumbersome, if NMSettingIPConfigPrivate is private itself. Simplify that, by internally sharing NMSettingIPConfigPrivate and let the subclasses embed the private data in their own private data. Optimally we would simply embed the private struct as field into NMSettingIPConfig. But that would be an ABI change as that struct was public before 1.32. Don't change ABI for now, so we have to awkwardly place it into the subclasses private data.
2021-06-28 18:14:04 +02:00
_nm_setting_ip_config_private_init(setting, &priv->parent);
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
}
/**
* nm_setting_ip6_config_new:
*
* Creates a new #NMSettingIP6Config object with default values.
*
* Returns: (transfer full): the new empty #NMSettingIP6Config object
**/
NMSetting *
nm_setting_ip6_config_new(void)
{
all: drop unnecessary cast for return value of g_object_new() C casts unconditionally force the type, and as such they don't necessarily improve type safety, but rather overcome restrictions from the compiler when necessary. Casting a void pointer is unnecessary (in C), it does not make the code more readable nor more safe. In particular for g_object_new(), which is known to return a void pointer of the right type. Drop such casts. sed 's/([A-Za-z_0-9]\+ *\* *) *g_object_new/g_object_new/g' $(git grep -l g_object_new) -i ./contrib/scripts/nm-code-format-container.sh
2020-11-12 15:57:06 +01:00
return g_object_new(NM_TYPE_SETTING_IP6_CONFIG, NULL);
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
static void
libnm/trivial: cleanup variable names in settings' class-init functions - Don't use @parent_class name. This local variable (and @object_class) is the class instance up-cast to the pointer types of the parents. The point here is not that it is the direct parent. The point is, that it's the NMSettingClass type. Also, it can only be used inconsistently, in face of NMSettingIP4Config, who's parent type is NMSettingIPConfig. Clearly, inside nm-setting-ip4-config.c we wouldn't want to use the "parent_class" name. Consistently rename @parent_class to @setting_class. - Also rename the pointer to the own class to @klass. "setting_class" is also the wrong name for that, because the right name would be something like "setting_6lowpan_class". However, "klass" is preferred over the latter, because we commonly create new GObject implementations by copying an existing one. Generic names like "klass" and "self" inside a type implementation make that simpler. - drop useless comments like /* virtual functions */ /* Properties */ It's better to logically and visually structure the code, and avoid trival remarks about that. They only end up being used inconsistently. If you even need a stronger visual separator, then an 80 char /****/ line should be preferred.
2018-07-28 10:43:21 +02:00
nm_setting_ip6_config_class_init(NMSettingIP6ConfigClass *klass)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GObjectClass *object_class = G_OBJECT_CLASS(klass);
NMSettingClass *setting_class = NM_SETTING_CLASS(klass);
libnm: let NMSettingIPConfigPrivate be tracked by subclasses For our property meta data handling we require that all the meta data is associated with one GType. NMSettingIPConfig is a parent class of NMSettingIP[46]Config. Note that we already have _nm_sett_info_property_override_create_array_ip_config() because the meta data must be initialized together at one place. We will require that we can find the offset for properties based on one offset per type. That is cumbersome, if NMSettingIPConfigPrivate is private itself. Simplify that, by internally sharing NMSettingIPConfigPrivate and let the subclasses embed the private data in their own private data. Optimally we would simply embed the private struct as field into NMSettingIPConfig. But that would be an ABI change as that struct was public before 1.32. Don't change ABI for now, so we have to awkwardly place it into the subclasses private data.
2021-06-28 18:14:04 +02:00
NMSettingIPConfigClass *setting_ip_config_class = NM_SETTING_IP_CONFIG_CLASS(klass);
libnm: implement special setter for direct string property for ip address This is a normalization employed by NMSettingIPConfig.gateway. Also rework NMSettingIPConfig.set_property() to no longer assert against valid input. We want to pass there untrusted strings from D-Bus, asserting is a horrible idea. Instead, either normalize the string or keep the invalid text that will be rejected by verify().
2021-07-14 07:40:35 +02:00
GArray *properties_override = _nm_sett_info_property_override_create_array_ip_config(AF_INET6);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm/trivial: cleanup variable names in settings' class-init functions - Don't use @parent_class name. This local variable (and @object_class) is the class instance up-cast to the pointer types of the parents. The point here is not that it is the direct parent. The point is, that it's the NMSettingClass type. Also, it can only be used inconsistently, in face of NMSettingIP4Config, who's parent type is NMSettingIPConfig. Clearly, inside nm-setting-ip4-config.c we wouldn't want to use the "parent_class" name. Consistently rename @parent_class to @setting_class. - Also rename the pointer to the own class to @klass. "setting_class" is also the wrong name for that, because the right name would be something like "setting_6lowpan_class". However, "klass" is preferred over the latter, because we commonly create new GObject implementations by copying an existing one. Generic names like "klass" and "self" inside a type implementation make that simpler. - drop useless comments like /* virtual functions */ /* Properties */ It's better to logically and visually structure the code, and avoid trival remarks about that. They only end up being used inconsistently. If you even need a stronger visual separator, then an 80 char /****/ line should be preferred.
2018-07-28 10:43:21 +02:00
g_type_class_add_private(klass, sizeof(NMSettingIP6ConfigPrivate));
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: cleanup redundant code for direct properties of NMSetting
2022-01-05 16:12:09 +01:00
object_class->get_property = _nm_setting_property_get_property_direct;
object_class->set_property = _nm_setting_property_set_property_direct;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
setting_class->verify = verify;
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
libnm: let NMSettingIPConfigPrivate be tracked by subclasses For our property meta data handling we require that all the meta data is associated with one GType. NMSettingIPConfig is a parent class of NMSettingIP[46]Config. Note that we already have _nm_sett_info_property_override_create_array_ip_config() because the meta data must be initialized together at one place. We will require that we can find the offset for properties based on one offset per type. That is cumbersome, if NMSettingIPConfigPrivate is private itself. Simplify that, by internally sharing NMSettingIPConfigPrivate and let the subclasses embed the private data in their own private data. Optimally we would simply embed the private struct as field into NMSettingIPConfig. But that would be an ABI change as that struct was public before 1.32. Don't change ABI for now, so we have to awkwardly place it into the subclasses private data.
2021-06-28 18:14:04 +02:00
setting_ip_config_class->private_offset = g_type_class_get_instance_private_offset(klass);
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
/* ---ifcfg-rh---
* property: method
ipv6: add 'disabled' method Add a new ipv6.method value 'disabled' that completely disables IPv6 for the interface. https://bugzilla.redhat.com/show_bug.cgi?id=1643841
2019-04-26 13:25:21 +02:00
* variable: IPV6INIT, IPV6FORWARDING, IPV6_AUTOCONF, DHCPV6C, IPV6_DISABLED
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* default: IPV6INIT=yes; IPV6FORWARDING=no; IPV6_AUTOCONF=!IPV6FORWARDING, DHCPV6=no
* description: Method used for IPv6 protocol configuration.
ipv6: add 'disabled' method Add a new ipv6.method value 'disabled' that completely disables IPv6 for the interface. https://bugzilla.redhat.com/show_bug.cgi?id=1643841
2019-04-26 13:25:21 +02:00
* ignore ~ IPV6INIT=no; auto ~ IPV6_AUTOCONF=yes; dhcp ~ IPV6_AUTOCONF=no and DHCPV6C=yes;
* disabled ~ IPV6_DISABLED=yes
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* ---end---
*/
/* ---keyfile---
* property: dns
* format: list of DNS IP addresses
* description: List of DNS servers.
* example: dns=2001:4860:4860::8888;2001:4860:4860::8844;
* ---end---
libnm: style cleanups for property annotations The parser will become stricter, and expect certain things. The strictness should help, to avoid writing wrong annotations. Adjust for that.
2022-08-29 15:05:39 +02:00
*/
/* ---ifcfg-rh---
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* property: dns
* variable: DNS1, DNS2, ...
* format: string
* description: List of DNS servers. NetworkManager uses the variables both
* for IPv4 and IPv6.
* ---end---
*/
/* ---ifcfg-rh---
* property: dns-search
ifcfg-rh: add missing NM-only annotations Add the (+) annotation to NM-only variables.
2018-05-28 18:13:42 +02:00
* variable: IPV6_DOMAIN(+)
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* format: string (space-separated domains)
* description: List of DNS search domains.
* ---end---
*/
/* ---keyfile---
* property: addresses
* variable: address1, address2, ...
libnm-core: update documentation of addresses and gateway properties
2014-11-18 20:19:11 +01:00
* format: address/plen
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* description: List of static IP addresses.
libnm-core: update documentation of addresses and gateway properties
2014-11-18 20:19:11 +01:00
* example: address1=abbe::cafe/96 address2=2001::1234
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* ---end---
libnm: style cleanups for property annotations The parser will become stricter, and expect certain things. The strictness should help, to avoid writing wrong annotations. Adjust for that.
2022-08-29 15:05:39 +02:00
*/
/* ---ifcfg-rh---
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* property: addresses
libnm-core: update documentation of addresses and gateway properties
2014-11-18 20:19:11 +01:00
* variable: IPV6ADDR, IPV6ADDR_SECONDARIES
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* description: List of static IP addresses.
libnm-core: update documentation of addresses and gateway properties
2014-11-18 20:19:11 +01:00
* example: IPV6ADDR=ab12:9876::1
* IPV6ADDR_SECONDARIES="ab12:9876::2 ab12:9876::3"
* ---end---
*/
/* ---keyfile---
* property: gateway
* variable: gateway
* format: string
* description: Gateway IP addresses as a string.
* example: gateway=abbe::1
* ---end---
libnm: style cleanups for property annotations The parser will become stricter, and expect certain things. The strictness should help, to avoid writing wrong annotations. Adjust for that.
2022-08-29 15:05:39 +02:00
*/
/* ---ifcfg-rh---
libnm-core: update documentation of addresses and gateway properties
2014-11-18 20:19:11 +01:00
* property: gateway
* variable: IPV6_DEFAULTGW
* description: Gateway IP address.
* example: IPV6_DEFAULTGW=abbe::1
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* ---end---
*/
/* ---keyfile---
* property: routes
* variable: route1, route2, ...
* format: route/plen[,gateway,metric]
* description: List of IP routes.
* example: route1=2001:4860:4860::/64,2620:52:0:2219:222:68ff:fe11:5403
* ---end---
libnm: style cleanups for property annotations The parser will become stricter, and expect certain things. The strictness should help, to avoid writing wrong annotations. Adjust for that.
2022-08-29 15:05:39 +02:00
*/
/* ---ifcfg-rh---
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* property: routes
* variable: (none)
* description: List of static routes. They are not stored in ifcfg-* file,
* but in route6-* file instead in the form of command line for 'ip route add'.
* ---end---
*/
/* ---ifcfg-rh---
* property: ignore-auto-routes
* variable: IPV6_PEERROUTES(+)
* default: yes
* description: IPV6_PEERROUTES has the opposite meaning as 'ignore-auto-routes' property.
* ---end---
*/
/* ---ifcfg-rh---
* property: ignore-auto-dns
* variable: IPV6_PEERDNS(+)
* default: yes
* description: IPV6_PEERDNS has the opposite meaning as 'ignore-auto-dns' property.
* ---end---
*/
/* ---ifcfg-rh---
* property: dhcp-hostname
libnm-core: fix ifcfg-rh variable name for DHCPv6 hostname Fixes: 2852b509456d ('ifcfg-rh: add DHCPV6_HOSTNAME and DHCPV6_SEND_HOSTNAME vars') (cherry picked from commit 657b8b31b020938674e220c4e76ce0428285ba96)
2019-08-05 11:01:30 +02:00
* variable: DHCPV6_HOSTNAME
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* description: Hostname to send the DHCP server.
* ---end---
*/
ifcfg-rh: belatedly add support for "ipv6.dhcp-timeout" setting
2020-02-14 15:37:28 +01:00
/* ---ifcfg-rh---
* property: dhcp-timeout
* variable: IPV6_DHCP_TIMEOUT(+)
* description: A timeout after which the DHCP transaction fails in case of no response.
* example: IPV6_DHCP_TIMEOUT=10
* ---end---
*/
ifcfg-rh: add support for DHCP hostname flags
2019-07-09 14:23:58 +02:00
/* ---ifcfg-rh---
* property: dhcp-hostname-flags
* variable: DHCPV6_HOSTNAME_FLAGS
* description: flags for the DHCP hostname property
* example: DHCPV6_HOSTNAME_FLAGS=5
libnm: add missing "---end---" tag for ifcfg-rh's "dhcp-hostname-flags" doc This missing tag confuses the parser and it results in an error in `man nm-settings-ifcfg-rh`.
2021-05-03 10:27:42 +02:00
* ---end---
ifcfg-rh: add support for DHCP hostname flags
2019-07-09 14:23:58 +02:00
*/
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
/* ---ifcfg-rh---
* property: never-default
* variable: IPV6_DEFROUTE(+), (and IPV6_DEFAULTGW, IPV6_DEFAULTDEV in /etc/sysconfig/network)
* default: IPV6_DEFROUTE=yes (when no variable specified)
* description: IPV6_DEFROUTE=no tells NetworkManager that this connection
* should not be assigned the default IPv6 route. IPV6_DEFROUTE has the opposite
* meaning as 'never-default' property.
* ---end---
*/
/* ---ifcfg-rh---
* property: may-fail
* variable: IPV6_FAILURE_FATAL(+)
* default: no
* description: IPV6_FAILURE_FATAL has the opposite meaning as 'may-fail' property.
* ---end---
*/
ifcfg-rh: support ipvx.route-metric property as IPVX_ROUTE_METRIC Write ipv4.route-metric and ipv6.route-metric property of NMSettingConnection as IPV4_ROUTE_METRIC and IPV6_ROUTE_METRIC, respectively.
2014-12-22 15:10:22 +01:00
/* ---ifcfg-rh---
* property: route-metric
* variable: IPV6_ROUTE_METRIC(+)
* default: -1
* description: IPV6_ROUTE_METRIC is the default IPv6 metric for routes on this connection.
* If set to -1, a default metric based on the device type is used.
* ---end---
*/
libnm,cli: add IP setting "route-table-sync"
2017-09-21 19:03:08 +02:00
/* ---ifcfg-rh---
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
* property: route-table
* variable: IPV6_ROUTE_TABLE(+)
libnm,cli: add IP setting "route-table-sync"
2017-09-21 19:03:08 +02:00
* default: 0
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
* description: IPV6_ROUTE_TABLE enables policy-routing and sets the default routing table.
libnm,cli: add IP setting "route-table-sync"
2017-09-21 19:03:08 +02:00
* ---end---
*/
ifcfg-rh: add support for DNS priority
2016-04-23 15:57:07 +02:00
/* ---ifcfg-rh---
* property: dns-priority
* variable: IPV6_DNS_PRIORITY(+)
* description: The priority for DNS servers of this connection. Lower values have higher priority.
* If zero, the default value will be used (50 for VPNs, 100 for other connections).
* A negative value prevents DNS from other connections with greater values to be used.
* default: 0
* example: IPV6_DNS_PRIORITY=20
* ---end---
*/
ifcfg-rh: use different variables for IPv4 and IPv6 DNS options Until now the ifcfg-rh plugin merged the values of 'ipv4.dns-options' and 'ipv6.dns-options' and wrote the result to the RES_OPTIONS variable. This is wrong because writing a connection and reading it back gives a different connection compared to the original. This behavior existed since when DNS options were introduced, but it became more evident now that we reread the connection after write, because after doing a: $ nmcli connection modify ethie ipv4.dns-options ndots:2 the connection has both ipv4.dns-options and ipv6.dns-options set. In order to delete the option, an user has to delete it from both settings: $ nmcli connection modify ethie ipv4.dns-options "" ipv6.dns-options "" To improve this let's use different variables for IPv4 and IPv6. To keep backwards compatibility IPv4 still uses RES_OPTIONS, while IPv6 uses a new IPV6_RES_OPTIONS variable. https://bugzilla.redhat.com/show_bug.cgi?id=1517794
2017-11-23 09:39:29 +01:00
/* ---ifcfg-rh---
* property: dns-options
* variable: IPV6_RES_OPTIONS(+)
* description: List of DNS options to be added to /etc/resolv.conf
* example: IPV6_RES_OPTIONS=ndots:2 timeout:3
* ---end---
*/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMSettingIP6Config:ip6-privacy:
*
* Configure IPv6 Privacy Extensions for SLAAC, described in RFC4941. If
* enabled, it makes the kernel generate a temporary IPv6 address in
* addition to the public one generated from MAC address via modified
* EUI-64. This enhances privacy, but could cause problems in some
libnm/doc: document behavior of setting ip6-privacy in /etc/sysctl.conf https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:35:32 +02:00
* applications, on the other hand. The permitted values are: -1: unknown,
* 0: disabled, 1: enabled (prefer public address), 2: enabled (prefer temporary
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* addresses).
libnm/doc: document behavior of setting ip6-privacy in /etc/sysctl.conf https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:35:32 +02:00
*
device: remove reading ipv6 privacy setting from sysctl Since introduction for support of ip6-privacy (use_tempaddr, RFC4941) with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, the sysctl value from /etc was always read first. This is problematic, because an explicit setting in the connection should not be ignored over a global configuration. Drop that old behavior. It was also problematic, because we did not read any files under /etc/sysctl.d (except for sysctl.conf). Also, we did not honor per-interface configurations. Now we also use as last fallback the value from /proc/sys/net/ipv6/conf/default/use_tempaddr That has the advantage of falling back to the system default value so that NM doesn't need to have it's own default policy (Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525). This is a change in behavior.
2015-06-02 17:38:07 +02:00
* Having a per-connection setting set to "-1" (unknown) means fallback to
* global configuration "ipv6.ip6-privacy".
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
*
device: remove reading ipv6 privacy setting from sysctl Since introduction for support of ip6-privacy (use_tempaddr, RFC4941) with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, the sysctl value from /etc was always read first. This is problematic, because an explicit setting in the connection should not be ignored over a global configuration. Drop that old behavior. It was also problematic, because we did not read any files under /etc/sysctl.d (except for sysctl.conf). Also, we did not honor per-interface configurations. Now we also use as last fallback the value from /proc/sys/net/ipv6/conf/default/use_tempaddr That has the advantage of falling back to the system default value so that NM doesn't need to have it's own default policy (Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525). This is a change in behavior.
2015-06-02 17:38:07 +02:00
* If also global configuration is unspecified or set to "-1", fallback to read
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
* "/proc/sys/net/ipv6/conf/default/use_tempaddr".
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
*
* Note that this setting is distinct from the Stable Privacy addresses
* that can be enabled with the "addr-gen-mode" property's "stable-privacy"
* setting as another way of avoiding host tracking with IPv6 addresses.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
/* ---ifcfg-rh---
* property: ip6-privacy
* variable: IPV6_PRIVACY, IPV6_PRIVACY_PREFER_PUBLIC_IP(+)
libnm-core: update ip6-privacy ifcfg-rh description
2014-11-19 09:57:20 +01:00
* values: IPV6_PRIVACY: no, yes (rfc3041 or rfc4941);
* IPV6_PRIVACY_PREFER_PUBLIC_IP: yes, no
* default: no
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* description: Configure IPv6 Privacy Extensions for SLAAC (RFC4941).
libnm-core: update ip6-privacy ifcfg-rh description
2014-11-19 09:57:20 +01:00
* example: IPV6_PRIVACY=rfc3041 IPV6_PRIVACY_PREFER_PUBLIC_IP=yes
libnm, libnm-util: move settings doc generation to libnm-core Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
* ---end---
*/
libnm: refactor some NMSetting to use direct properties for enum/flags https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1033
2021-11-24 09:43:37 +01:00
_nm_setting_property_define_direct_enum(properties_override,
obj_properties,
NM_SETTING_IP6_CONFIG_IP6_PRIVACY,
PROP_IP6_PRIVACY,
NM_TYPE_SETTING_IP6_CONFIG_PRIVACY,
NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN,
NM_SETTING_PARAM_NONE,
NMSettingIP6ConfigPrivate,
ip6_privacy);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
/**
* NMSettingIP6Config:addr-gen-mode:
*
* Configure method for creating the address for use with RFC4862 IPv6
libnm-core: specify enum values in NMSettingIP6Config:addr-gen-mode doc So that the man page will display: The permitted values are: NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_EUI64 (0) or NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_STABLE_PRIVACY (1). instead of The permitted values are: "eui64" or "stable-privacy". since the latter is not useful at all for a int32 property. Unfortunately the enum names are quite long and don't look very well in a table, but that's another problem.
2017-10-13 11:52:09 +02:00
* Stateless Address Autoconfiguration. The permitted values are:
all: make "ipv6.addr-gen-mode" configurable by global default It can be useful to choose a different "ipv6.addr-gen-mode". And it can be useful to override the default for a set of profiles. For example, in cloud or in a data center, stable-privacy might not be the best choice. Add a mechanism to override the default via global defaults in NetworkManager.conf: # /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf [connection-90-ipv6-addr-gen-mode-override] match-device=type:ethernet ipv6.addr-gen-mode=0 "ipv6.addr-gen-mode" is a special property, because its default depends on the component that configures the profile. - when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode key means to default to "eui64". - when configured via D-Bus, a missing addr-gen-mode property means to default to "stable-privacy". - libnm's ip6-config::addr-gen-mode property defaults to "stable-privacy". - when some tool creates a profile, they either can explicitly set the mode, or they get the default of the underlying mechanisms above. - nm-initrd-generator explicitly sets "eui64" for profiles it creates. - nmcli doesn' explicitly set it, but inherits the default form libnm's ip6-config::addr-gen-mode. - when NM creates a auto-default-connection for ethernet ("Wired connection 1"), it inherits the default from libnm's ip6-config::addr-gen-mode. Global connection defaults only take effect when the per-profile value is set to a special default/unset value. To account for the different cases above, we add two such special values: "default" and "default-or-eui64". That's something we didn't do before, but it seams useful and easy to understand. Also, this neatly expresses the current behaviors we already have. E.g. if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64" is a pretty clear thing. Note that usually we cannot change default values, in particular not for libnm's properties. That is because we don't serialize the default values to D-Bus/keyfile, so if we change the default, we change behavior. Here we change from "stable-privacy" to "default" and from "eui64" to "default-or-eui64". That means, the user only experiences a change in behavior, if they have a ".conf" file that overrides the default. https://bugzilla.redhat.com/show_bug.cgi?id=1743161 https://bugzilla.redhat.com/show_bug.cgi?id=2082682 See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
2022-05-06 16:57:51 +02:00
* %NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_EUI64,
libnm-core: specify enum values in NMSettingIP6Config:addr-gen-mode doc So that the man page will display: The permitted values are: NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_EUI64 (0) or NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_STABLE_PRIVACY (1). instead of The permitted values are: "eui64" or "stable-privacy". since the latter is not useful at all for a int32 property. Unfortunately the enum names are quite long and don't look very well in a table, but that's another problem.
2017-10-13 11:52:09 +02:00
* %NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_STABLE_PRIVACY.
all: make "ipv6.addr-gen-mode" configurable by global default It can be useful to choose a different "ipv6.addr-gen-mode". And it can be useful to override the default for a set of profiles. For example, in cloud or in a data center, stable-privacy might not be the best choice. Add a mechanism to override the default via global defaults in NetworkManager.conf: # /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf [connection-90-ipv6-addr-gen-mode-override] match-device=type:ethernet ipv6.addr-gen-mode=0 "ipv6.addr-gen-mode" is a special property, because its default depends on the component that configures the profile. - when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode key means to default to "eui64". - when configured via D-Bus, a missing addr-gen-mode property means to default to "stable-privacy". - libnm's ip6-config::addr-gen-mode property defaults to "stable-privacy". - when some tool creates a profile, they either can explicitly set the mode, or they get the default of the underlying mechanisms above. - nm-initrd-generator explicitly sets "eui64" for profiles it creates. - nmcli doesn' explicitly set it, but inherits the default form libnm's ip6-config::addr-gen-mode. - when NM creates a auto-default-connection for ethernet ("Wired connection 1"), it inherits the default from libnm's ip6-config::addr-gen-mode. Global connection defaults only take effect when the per-profile value is set to a special default/unset value. To account for the different cases above, we add two such special values: "default" and "default-or-eui64". That's something we didn't do before, but it seams useful and easy to understand. Also, this neatly expresses the current behaviors we already have. E.g. if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64" is a pretty clear thing. Note that usually we cannot change default values, in particular not for libnm's properties. That is because we don't serialize the default values to D-Bus/keyfile, so if we change the default, we change behavior. Here we change from "stable-privacy" to "default" and from "eui64" to "default-or-eui64". That means, the user only experiences a change in behavior, if they have a ".conf" file that overrides the default. https://bugzilla.redhat.com/show_bug.cgi?id=1743161 https://bugzilla.redhat.com/show_bug.cgi?id=2082682 See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
2022-05-06 16:57:51 +02:00
* %NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_DEFAULT_OR_EUI64
* or %NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_DEFAULT.
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
*
libnm-core: specify enum values in NMSettingIP6Config:addr-gen-mode doc So that the man page will display: The permitted values are: NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_EUI64 (0) or NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_STABLE_PRIVACY (1). instead of The permitted values are: "eui64" or "stable-privacy". since the latter is not useful at all for a int32 property. Unfortunately the enum names are quite long and don't look very well in a table, but that's another problem.
2017-10-13 11:52:09 +02:00
* If the property is set to EUI64, the addresses will be generated
docs: fix spelling errors in tranlated strings and documentation https://bugzilla.gnome.org/show_bug.cgi?id=786131
2017-08-11 11:05:12 +02:00
* using the interface tokens derived from hardware address. This makes
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
* the host part of the address to stay constant, making it possible
* to track host's presence when it changes networks. The address changes
* when the interface hardware is replaced.
*
libnm-core: specify enum values in NMSettingIP6Config:addr-gen-mode doc So that the man page will display: The permitted values are: NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_EUI64 (0) or NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_STABLE_PRIVACY (1). instead of The permitted values are: "eui64" or "stable-privacy". since the latter is not useful at all for a int32 property. Unfortunately the enum names are quite long and don't look very well in a table, but that's another problem.
2017-10-13 11:52:09 +02:00
* The value of stable-privacy enables use of cryptographically
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
* secure hash of a secret host-specific key along with the connection's
* stable-id and the network address as specified by RFC7217.
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
* This makes it impossible to use the address track host's presence,
* and makes the address stable when the network interface hardware is
* replaced.
*
all: make "ipv6.addr-gen-mode" configurable by global default It can be useful to choose a different "ipv6.addr-gen-mode". And it can be useful to override the default for a set of profiles. For example, in cloud or in a data center, stable-privacy might not be the best choice. Add a mechanism to override the default via global defaults in NetworkManager.conf: # /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf [connection-90-ipv6-addr-gen-mode-override] match-device=type:ethernet ipv6.addr-gen-mode=0 "ipv6.addr-gen-mode" is a special property, because its default depends on the component that configures the profile. - when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode key means to default to "eui64". - when configured via D-Bus, a missing addr-gen-mode property means to default to "stable-privacy". - libnm's ip6-config::addr-gen-mode property defaults to "stable-privacy". - when some tool creates a profile, they either can explicitly set the mode, or they get the default of the underlying mechanisms above. - nm-initrd-generator explicitly sets "eui64" for profiles it creates. - nmcli doesn' explicitly set it, but inherits the default form libnm's ip6-config::addr-gen-mode. - when NM creates a auto-default-connection for ethernet ("Wired connection 1"), it inherits the default from libnm's ip6-config::addr-gen-mode. Global connection defaults only take effect when the per-profile value is set to a special default/unset value. To account for the different cases above, we add two such special values: "default" and "default-or-eui64". That's something we didn't do before, but it seams useful and easy to understand. Also, this neatly expresses the current behaviors we already have. E.g. if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64" is a pretty clear thing. Note that usually we cannot change default values, in particular not for libnm's properties. That is because we don't serialize the default values to D-Bus/keyfile, so if we change the default, we change behavior. Here we change from "stable-privacy" to "default" and from "eui64" to "default-or-eui64". That means, the user only experiences a change in behavior, if they have a ".conf" file that overrides the default. https://bugzilla.redhat.com/show_bug.cgi?id=1743161 https://bugzilla.redhat.com/show_bug.cgi?id=2082682 See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
2022-05-06 16:57:51 +02:00
* The special values "default" and "default-or-eui64" will fallback to the global
* connection default in as documented in NetworkManager.conf(5) manual. If the
* global default is not specified, the fallback value is "stable-privacy"
* or "eui64", respectively.
*
* For libnm, the property defaults to "default" since 1.40.
* Previously it defaulted to "stable-privacy".
* On D-Bus, the absence of an addr-gen-mode setting equals
* "default". For keyfile plugin, the absence of the setting
* on disk means "default-or-eui64" so that the property doesn't change on upgrade
libnm/doc: fix documentation of NMSettingIP6Config:addr-gen-mode The value cannot be unset. It must be set to one of the two currently supported values.
2016-04-25 16:14:41 +02:00
* from older versions.
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
*
* Note that this setting is distinct from the Privacy Extensions as
* configured by "ip6-privacy" property and it does not affect the
* temporary addresses configured with this option.
*
* Since: 1.2
**/
/* ---ifcfg-rh---
* property: addr-gen-mode
* variable: IPV6_ADDR_GEN_MODE
all: make "ipv6.addr-gen-mode" configurable by global default It can be useful to choose a different "ipv6.addr-gen-mode". And it can be useful to override the default for a set of profiles. For example, in cloud or in a data center, stable-privacy might not be the best choice. Add a mechanism to override the default via global defaults in NetworkManager.conf: # /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf [connection-90-ipv6-addr-gen-mode-override] match-device=type:ethernet ipv6.addr-gen-mode=0 "ipv6.addr-gen-mode" is a special property, because its default depends on the component that configures the profile. - when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode key means to default to "eui64". - when configured via D-Bus, a missing addr-gen-mode property means to default to "stable-privacy". - libnm's ip6-config::addr-gen-mode property defaults to "stable-privacy". - when some tool creates a profile, they either can explicitly set the mode, or they get the default of the underlying mechanisms above. - nm-initrd-generator explicitly sets "eui64" for profiles it creates. - nmcli doesn' explicitly set it, but inherits the default form libnm's ip6-config::addr-gen-mode. - when NM creates a auto-default-connection for ethernet ("Wired connection 1"), it inherits the default from libnm's ip6-config::addr-gen-mode. Global connection defaults only take effect when the per-profile value is set to a special default/unset value. To account for the different cases above, we add two such special values: "default" and "default-or-eui64". That's something we didn't do before, but it seams useful and easy to understand. Also, this neatly expresses the current behaviors we already have. E.g. if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64" is a pretty clear thing. Note that usually we cannot change default values, in particular not for libnm's properties. That is because we don't serialize the default values to D-Bus/keyfile, so if we change the default, we change behavior. Here we change from "stable-privacy" to "default" and from "eui64" to "default-or-eui64". That means, the user only experiences a change in behavior, if they have a ".conf" file that overrides the default. https://bugzilla.redhat.com/show_bug.cgi?id=1743161 https://bugzilla.redhat.com/show_bug.cgi?id=2082682 See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
2022-05-06 16:57:51 +02:00
* values: IPV6_ADDR_GEN_MODE: default, default-or-eui64, eui64, stable-privacy
* default: "default-or-eui64"
setting-ip6-config: add addr-gen-mode property
2015-09-08 20:22:17 +02:00
* description: Configure IPv6 Stable Privacy addressing for SLAAC (RFC7217).
* example: IPV6_ADDR_GEN_MODE=stable-privacy
* ---end---
*/
libnm: refactor some NMSetting to use direct properties for int32
2021-12-24 12:01:35 +01:00
_nm_setting_property_define_direct_int32(properties_override,
obj_properties,
NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE,
PROP_ADDR_GEN_MODE,
G_MININT32,
G_MAXINT32,
all: make "ipv6.addr-gen-mode" configurable by global default It can be useful to choose a different "ipv6.addr-gen-mode". And it can be useful to override the default for a set of profiles. For example, in cloud or in a data center, stable-privacy might not be the best choice. Add a mechanism to override the default via global defaults in NetworkManager.conf: # /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf [connection-90-ipv6-addr-gen-mode-override] match-device=type:ethernet ipv6.addr-gen-mode=0 "ipv6.addr-gen-mode" is a special property, because its default depends on the component that configures the profile. - when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode key means to default to "eui64". - when configured via D-Bus, a missing addr-gen-mode property means to default to "stable-privacy". - libnm's ip6-config::addr-gen-mode property defaults to "stable-privacy". - when some tool creates a profile, they either can explicitly set the mode, or they get the default of the underlying mechanisms above. - nm-initrd-generator explicitly sets "eui64" for profiles it creates. - nmcli doesn' explicitly set it, but inherits the default form libnm's ip6-config::addr-gen-mode. - when NM creates a auto-default-connection for ethernet ("Wired connection 1"), it inherits the default from libnm's ip6-config::addr-gen-mode. Global connection defaults only take effect when the per-profile value is set to a special default/unset value. To account for the different cases above, we add two such special values: "default" and "default-or-eui64". That's something we didn't do before, but it seams useful and easy to understand. Also, this neatly expresses the current behaviors we already have. E.g. if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64" is a pretty clear thing. Note that usually we cannot change default values, in particular not for libnm's properties. That is because we don't serialize the default values to D-Bus/keyfile, so if we change the default, we change behavior. Here we change from "stable-privacy" to "default" and from "eui64" to "default-or-eui64". That means, the user only experiences a change in behavior, if they have a ".conf" file that overrides the default. https://bugzilla.redhat.com/show_bug.cgi?id=1743161 https://bugzilla.redhat.com/show_bug.cgi?id=2082682 See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
2022-05-06 16:57:51 +02:00
NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_DEFAULT,
libnm: refactor some NMSetting to use direct properties for int32
2021-12-24 12:01:35 +01:00
NM_SETTING_PARAM_NONE,
NMSettingIP6ConfigPrivate,
all: make "ipv6.addr-gen-mode" configurable by global default It can be useful to choose a different "ipv6.addr-gen-mode". And it can be useful to override the default for a set of profiles. For example, in cloud or in a data center, stable-privacy might not be the best choice. Add a mechanism to override the default via global defaults in NetworkManager.conf: # /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf [connection-90-ipv6-addr-gen-mode-override] match-device=type:ethernet ipv6.addr-gen-mode=0 "ipv6.addr-gen-mode" is a special property, because its default depends on the component that configures the profile. - when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode key means to default to "eui64". - when configured via D-Bus, a missing addr-gen-mode property means to default to "stable-privacy". - libnm's ip6-config::addr-gen-mode property defaults to "stable-privacy". - when some tool creates a profile, they either can explicitly set the mode, or they get the default of the underlying mechanisms above. - nm-initrd-generator explicitly sets "eui64" for profiles it creates. - nmcli doesn' explicitly set it, but inherits the default form libnm's ip6-config::addr-gen-mode. - when NM creates a auto-default-connection for ethernet ("Wired connection 1"), it inherits the default from libnm's ip6-config::addr-gen-mode. Global connection defaults only take effect when the per-profile value is set to a special default/unset value. To account for the different cases above, we add two such special values: "default" and "default-or-eui64". That's something we didn't do before, but it seams useful and easy to understand. Also, this neatly expresses the current behaviors we already have. E.g. if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64" is a pretty clear thing. Note that usually we cannot change default values, in particular not for libnm's properties. That is because we don't serialize the default values to D-Bus/keyfile, so if we change the default, we change behavior. Here we change from "stable-privacy" to "default" and from "eui64" to "default-or-eui64". That means, the user only experiences a change in behavior, if they have a ".conf" file that overrides the default. https://bugzilla.redhat.com/show_bug.cgi?id=1743161 https://bugzilla.redhat.com/show_bug.cgi?id=2082682 See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
2022-05-06 16:57:51 +02:00
addr_gen_mode,
.to_dbus_including_default = TRUE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
setting-ip6-config: add token property
2016-04-30 16:48:02 +02:00
/**
* NMSettingIP6Config:token:
*
* Configure the token for draft-chown-6man-tokenised-ipv6-identifiers-02
* IPv6 tokenized interface identifiers. Useful with eui64 addr-gen-mode.
*
* Since: 1.4
**/
/* ---ifcfg-rh---
* property: token
* variable: IPV6_TOKEN
* description: The IPv6 tokenized interface identifier token
* example: IPV6_TOKEN=::53
* ---end---
*/
libnm: use _nm_setting_property_define_direct_string()
2021-06-28 17:28:21 +02:00
_nm_setting_property_define_direct_string(properties_override,
obj_properties,
NM_SETTING_IP6_CONFIG_TOKEN,
PROP_TOKEN,
NM_SETTING_PARAM_INFERRABLE,
NMSettingIP6ConfigPrivate,
token);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm,cli,ifcfg-rh: add ipv6.ra-timeout configuration option
2020-02-13 15:41:35 +01:00
/**
* NMSettingIP6Config:ra-timeout:
*
* A timeout for waiting Router Advertisements in seconds. If zero (the default), a
* globally configured default is used. If still unspecified, the timeout depends on the
* sysctl settings of the device.
*
* Set to 2147483647 (MAXINT32) for infinity.
*
* Since: 1.24
**/
/* ---ifcfg-rh---
libnm: fix documentation annotations for ifcfg-rh plugin
2022-08-29 11:27:17 +02:00
* property: ra-timeout
libnm,cli,ifcfg-rh: add ipv6.ra-timeout configuration option
2020-02-13 15:41:35 +01:00
* variable: IPV6_RA_TIMEOUT(+)
* description: A timeout for waiting Router Advertisements in seconds.
* example: IPV6_RA_TIMEOUT=10
* ---end---
*/
libnm: refactor some NMSetting to use direct properties for int32
2021-12-24 12:01:35 +01:00
_nm_setting_property_define_direct_int32(properties_override,
obj_properties,
NM_SETTING_IP6_CONFIG_RA_TIMEOUT,
PROP_RA_TIMEOUT,
0,
G_MAXINT32,
0,
NM_SETTING_PARAM_FUZZY_IGNORE,
NMSettingIP6ConfigPrivate,
ra_timeout);
libnm,cli,ifcfg-rh: add ipv6.ra-timeout configuration option
2020-02-13 15:41:35 +01:00
device: introduce ipv6.mtu property https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1003 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1231
2022-05-19 15:27:38 -06:00
/**
* NMSettingIP6Config:mtu:
*
* Maximum transmission unit size, in bytes. If zero (the default), the MTU
* is set automatically from router advertisements or is left equal to the
* link-layer MTU. If greater than the link-layer MTU, or greater than zero
* but less than the minimum IPv6 MTU of 1280, this value has no effect.
*
* Since: 1.40
**/
_nm_setting_property_define_direct_uint32(properties_override,
obj_properties,
NM_SETTING_IP6_CONFIG_MTU,
PROP_MTU,
0,
G_MAXUINT32,
0,
NM_SETTING_PARAM_FUZZY_IGNORE,
NMSettingIP6ConfigPrivate,
mtu);
libnm-core: add ipv6.dhcp-duid property allow to specify the DUID to be used int the DHCPv6 client identifier option: the dhcp-duid property accepts either a hex string or the special values "lease", "llt", "ll", "stable-llt", "stable-ll" and "stable-uuid". "lease": give priority to the DUID available in the lease file if any, otherwise fallback to a global default dependant on the dhcp client used. This is the default and reflects how the DUID was managed previously. "ll": enforce generation and use of LL type DUID based on the current hardware address. "llt": enforce generation and use of LLT type DUID based on the current hardware address and a stable time field. "stable-ll": enforce generation and use of LL type DUID based on a link layer address derived from the stable id. "stable-llt": enforce generation and use of LLT type DUID based on a link layer address and a timestamp both derived from the stable id. "stable-uuid": enforce generation and use of a UUID type DUID based on a uuid generated from the stable id.
2018-03-06 16:10:01 +01:00
/**
* NMSettingIP6Config:dhcp-duid:
*
* A string containing the DHCPv6 Unique Identifier (DUID) used by the dhcp
* client to identify itself to DHCPv6 servers (RFC 3315). The DUID is carried
* in the Client Identifier option.
* If the property is a hex string ('aa:bb:cc') it is interpreted as a binary
* DUID and filled as an opaque value in the Client Identifier option.
*
* The special value "lease" will retrieve the DUID previously used from the
* lease file belonging to the connection. If no DUID is found and "dhclient"
* is the configured dhcp client, the DUID is searched in the system-wide
* dhclient lease file. If still no DUID is found, or another dhcp client is
* used, a global and permanent DUID-UUID (RFC 6355) will be generated based
* on the machine-id.
*
* The special values "llt" and "ll" will generate a DUID of type LLT or LL
* (see RFC 3315) based on the current MAC address of the device. In order to
* try providing a stable DUID-LLT, the time field will contain a constant
* timestamp that is used globally (for all profiles) and persisted to disk.
*
* The special values "stable-llt", "stable-ll" and "stable-uuid" will generate
* a DUID of the corresponding type, derived from the connection's stable-id and
doc: add hint about ipv4.dhcp-client-id=stable
2018-11-02 11:44:05 +01:00
* a per-host unique key. You may want to include the "${DEVICE}" or "${MAC}" specifier
* in the stable-id, in case this profile gets activated on multiple devices.
libnm-core: add ipv6.dhcp-duid property allow to specify the DUID to be used int the DHCPv6 client identifier option: the dhcp-duid property accepts either a hex string or the special values "lease", "llt", "ll", "stable-llt", "stable-ll" and "stable-uuid". "lease": give priority to the DUID available in the lease file if any, otherwise fallback to a global default dependant on the dhcp client used. This is the default and reflects how the DUID was managed previously. "ll": enforce generation and use of LL type DUID based on the current hardware address. "llt": enforce generation and use of LLT type DUID based on the current hardware address and a stable time field. "stable-ll": enforce generation and use of LL type DUID based on a link layer address derived from the stable id. "stable-llt": enforce generation and use of LLT type DUID based on a link layer address and a timestamp both derived from the stable id. "stable-uuid": enforce generation and use of a UUID type DUID based on a uuid generated from the stable id.
2018-03-06 16:10:01 +01:00
* So, the link-layer address of "stable-ll" and "stable-llt" will be a generated
* address derived from the stable id. The DUID-LLT time value in the "stable-llt"
* option will be picked among a static timespan of three years (the upper bound
* of the interval is the same constant timestamp used in "llt").
*
* When the property is unset, the global value provided for "ipv6.dhcp-duid" is
* used. If no global value is provided, the default "lease" value is assumed.
*
* Since: 1.12
**/
ifcfg: introduce DHCPV6_DUID to map ipv6.dhcp-duid property
2018-04-06 18:25:06 +02:00
/* ---ifcfg-rh---
* property: dhcp-duid
* variable: DHCPV6_DUID(+)
* description: A string sent to the DHCPv6 server to identify the local machine.
* Apart from the special values "lease", "stable-llt", "stable-ll", "stable-uuid",
* "llt" and "ll" a binary value in hex format is expected. An hex string where
* each octet is separated by a colon is also accepted.
* example: DHCPV6_DUID=LL; DHCPV6_DUID=0301deadbeef0001; DHCPV6_DUID=03:01:de:ad:be:ef:00:01
* ---end---
*/
libnm: use _nm_setting_property_define_direct_string()
2021-06-28 17:28:21 +02:00
_nm_setting_property_define_direct_string(properties_override,
obj_properties,
NM_SETTING_IP6_CONFIG_DHCP_DUID,
PROP_DHCP_DUID,
NM_SETTING_PARAM_NONE,
NMSettingIP6ConfigPrivate,
dhcp_duid);
libnm-core: add ipv6.dhcp-duid property allow to specify the DUID to be used int the DHCPv6 client identifier option: the dhcp-duid property accepts either a hex string or the special values "lease", "llt", "ll", "stable-llt", "stable-ll" and "stable-uuid". "lease": give priority to the DUID available in the lease file if any, otherwise fallback to a global default dependant on the dhcp client used. This is the default and reflects how the DUID was managed previously. "ll": enforce generation and use of LL type DUID based on the current hardware address. "llt": enforce generation and use of LLT type DUID based on the current hardware address and a stable time field. "stable-ll": enforce generation and use of LL type DUID based on a link layer address derived from the stable id. "stable-llt": enforce generation and use of LLT type DUID based on a link layer address and a timestamp both derived from the stable id. "stable-uuid": enforce generation and use of a UUID type DUID based on a uuid generated from the stable id.
2018-03-06 16:10:01 +01:00
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
/* IP6-specific property overrides */
libnm: Override parts of nm-setting-docs.xml Add "---dbus---" sections to the NMSetting property docs, in the same style as the plugin docs, parse them out into a file "nm-setting-docs-overrides.xml", and use them to override the GObject property docs in nm-setting-docs.xml. This lets us put more D-Bus-specific information in the setting docs, without cluttering up the property docs, and it also lets us document dbus-only properties.
2014-11-16 15:36:18 -05:00
/* ---dbus---
* property: dns
* format: array of byte array
* description: Array of IP addresses of DNS servers (in network byte order)
* ---end---
*/
libnm/trivial: rename _properties_override_add_*() to _nm_properties_override_*() These macros/functions are in a header file. Everything in a header file should have an "nm" prefix. Rename.
2019-09-22 15:32:04 +02:00
_nm_properties_override_gobj(
properties_override,
g_object_class_find_property(G_OBJECT_CLASS(setting_class), NM_SETTING_IP_CONFIG_DNS),
libnm: refactor to_dbus_fcn() for "ipv6.dns" property The goal is to get rid of gprop_to_dbus_fcn() uses. Note that there is a change in behavior. The "dns" GPtrArray in NMSettingIPConfig is never NULL (the default of the boxed property), thus the previous code always serialized the property, even the empty list. Now, empty dns properties are omitted from D-Bus.
2021-06-29 21:53:55 +02:00
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("aay"),
.compare_fcn = _nm_setting_property_compare_fcn_default,
.to_dbus_fcn = ip6_dns_to_dbus,
libnm: always set from_dbus_fcn() property hook When looking at a property, it should always be clear how it is handled. Also the "default" action should be an explicit hook. Add _nm_setting_property_from_dbus_fcn_gprop() and set that as from_dbus_fcn() callback to handle the "default" case which us build around g_object_set_property(). While this adds lines of code, I think it makes the code easier to understand. Basically, to convert a GVariant to a property, now all properties call their from_dbus_fcn() handler, there is no special casing. And the gprop-hook is only called for properties that are using _nm_setting_property_from_dbus_fcn_gprop(). So, you can reason about these two functions at separate layers.
2021-06-30 00:05:49 +02:00
.typdata_from_dbus.gprop_fcn = ip6_dns_from_dbus,
.from_dbus_fcn = _nm_setting_property_from_dbus_fcn_gprop,
.from_dbus_is_full = TRUE));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: Override parts of nm-setting-docs.xml Add "---dbus---" sections to the NMSetting property docs, in the same style as the plugin docs, parse them out into a file "nm-setting-docs-overrides.xml", and use them to override the GObject property docs in nm-setting-docs.xml. This lets us put more D-Bus-specific information in the setting docs, without cluttering up the property docs, and it also lets us document dbus-only properties.
2014-11-16 15:36:18 -05:00
/* ---dbus---
* property: addresses
* format: array of legacy IPv6 address struct (a(ayuay))
* description: Deprecated in favor of the 'address-data' and 'gateway'
* properties, but this can be used for backward-compatibility with older
* daemons. Note that if you send this property the daemon will ignore
* 'address-data' and 'gateway'.
*
* Array of IPv6 address structures. Each IPv6 address structure is
libnm: allow manually specified IP addresses to have prefix length 0 In IPv4, /0 prevents the creation of a device route, making it effectively the same as /32. However, in IPv6, /0 makes the device route an all-encompassing default route. This allows, for example, an 'fe80::' link-local address to be used to communicate with any public or private address on the local network without any additional configuration. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1006 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1232
2022-05-25 13:54:33 -06:00
* composed of an IPv6 address, a prefix length (0 - 128), and an IPv6
libnm: Override parts of nm-setting-docs.xml Add "---dbus---" sections to the NMSetting property docs, in the same style as the plugin docs, parse them out into a file "nm-setting-docs-overrides.xml", and use them to override the GObject property docs in nm-setting-docs.xml. This lets us put more D-Bus-specific information in the setting docs, without cluttering up the property docs, and it also lets us document dbus-only properties.
2014-11-16 15:36:18 -05:00
* gateway address. The gateway may be zeroed out if no gateway exists for
* that subnet.
* ---end---
*/
nmcli/docs: better describe ipv[46].addresses in `man nm-settings-nmcli`
2021-08-17 12:12:40 +02:00
/* ---nmcli---
* property: addresses
* format: a comma separated list of addresses
* description: A list of IPv6 addresses and their prefix length. Multiple addresses
* can be separated by comma. For example "2001:db8:85a3::8a2e:370:7334/64, 2001:db8:85a3::5/64".
core: change the priority order in static "ipv6.addresses" The order of addresses matters. For "ipv4.addresses", the list contains the primary address first. For "ipv6.addresses", the order was reverted. This was also documented behavior. The previous patch just changed behavior with respect to relative order of static IPv6 addresses and autoconf6/DHCPv6. As we seem in the mood for changing behavior, here is another one. Now the addresses are interpreted in an order consistent with IPv4 and how one might expect: preferred addresses first. (cherry picked from commit 3d6b6aa31728a36af491ebcd4964a0e1a3ada27d)
2022-03-31 16:48:28 +02:00
* The addresses are listed in decreasing priority, meaning the first address will
* be the primary address. This can make a difference with IPv6 source address selection
* (RFC 6724, section 5).
nmcli/docs: better describe ipv[46].addresses in `man nm-settings-nmcli`
2021-08-17 12:12:40 +02:00
* ---end---
*/
libnm/trivial: rename _properties_override_add_*() to _nm_properties_override_*() These macros/functions are in a header file. Everything in a header file should have an "nm" prefix. Rename.
2019-09-22 15:32:04 +02:00
_nm_properties_override_gobj(
properties_override,
g_object_class_find_property(G_OBJECT_CLASS(setting_class), NM_SETTING_IP_CONFIG_ADDRESSES),
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("a(ayuay)"),
.to_dbus_fcn = ip6_addresses_get,
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
2021-06-29 14:37:16 +02:00
.compare_fcn = _nm_setting_ip_config_compare_fcn_addresses,
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
.from_dbus_fcn = ip6_addresses_set, ));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: Override parts of nm-setting-docs.xml Add "---dbus---" sections to the NMSetting property docs, in the same style as the plugin docs, parse them out into a file "nm-setting-docs-overrides.xml", and use them to override the GObject property docs in nm-setting-docs.xml. This lets us put more D-Bus-specific information in the setting docs, without cluttering up the property docs, and it also lets us document dbus-only properties.
2014-11-16 15:36:18 -05:00
/* ---dbus---
* property: address-data
* format: array of vardict
* description: Array of IPv6 addresses. Each address dictionary contains at
* least 'address' and 'prefix' entries, containing the IP address as a
* string, and the prefix length as a uint32. Additional attributes may
* also exist on some addresses.
* ---end---
*/
libnm/trivial: rename _properties_override_add_*() to _nm_properties_override_*() These macros/functions are in a header file. Everything in a header file should have an "nm" prefix. Rename.
2019-09-22 15:32:04 +02:00
_nm_properties_override_dbus(
properties_override,
"address-data",
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("aa{sv}"),
.to_dbus_fcn = ip6_address_data_get,
libnm: add special ignore function for NMSettInfoPropertType.compare_fcn()
2021-06-29 17:03:37 +02:00
.compare_fcn = _nm_setting_property_compare_fcn_ignore,
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
.from_dbus_fcn = ip6_address_data_set, ));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: Override parts of nm-setting-docs.xml Add "---dbus---" sections to the NMSetting property docs, in the same style as the plugin docs, parse them out into a file "nm-setting-docs-overrides.xml", and use them to override the GObject property docs in nm-setting-docs.xml. This lets us put more D-Bus-specific information in the setting docs, without cluttering up the property docs, and it also lets us document dbus-only properties.
2014-11-16 15:36:18 -05:00
/* ---dbus---
* property: routes
* format: array of legacy IPv6 route struct (a(ayuayu))
* description: Deprecated in favor of the 'route-data' property, but this
* can be used for backward-compatibility with older daemons. Note that if
* you send this property the daemon will ignore 'route-data'.
*
* Array of IPv6 route structures. Each IPv6 route structure is
libnm: allow manually specified IP addresses to have prefix length 0 In IPv4, /0 prevents the creation of a device route, making it effectively the same as /32. However, in IPv6, /0 makes the device route an all-encompassing default route. This allows, for example, an 'fe80::' link-local address to be used to communicate with any public or private address on the local network without any additional configuration. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1006 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1232
2022-05-25 13:54:33 -06:00
* composed of an IPv6 address, a prefix length (0 - 128), an IPv6
libnm: Override parts of nm-setting-docs.xml Add "---dbus---" sections to the NMSetting property docs, in the same style as the plugin docs, parse them out into a file "nm-setting-docs-overrides.xml", and use them to override the GObject property docs in nm-setting-docs.xml. This lets us put more D-Bus-specific information in the setting docs, without cluttering up the property docs, and it also lets us document dbus-only properties.
2014-11-16 15:36:18 -05:00
* next hop address (which may be zeroed out if there is no next hop),
* and a metric. If the metric is 0, NM will choose an appropriate
* default metric for the device.
* ---end---
*/
libnm/doc: list route attributes in `man nm-settings-nmcli` IPv4: routes A list of IPv4 destination addresses, prefix length, optional IPv4 next hop addresses, optional route metric, optional attribute. The valid syntax is: "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]". For example "192.0.2.0/24 10.1.1.1 77, 198.51.100.0/24". Various attributes are supported: • "cwnd" - an unsigned 32 bit integer. • "initcwnd" - an unsigned 32 bit integer. • "initrwnd" - an unsigned 32 bit integer. • "lock-cwnd" - a boolean value. • "lock-initcwnd" - a boolean value. • "lock-initrwnd" - a boolean value. • "lock-mtu" - a boolean value. • "lock-window" - a boolean value. • "mtu" - an unsigned 32 bit integer. • "onlink" - a boolean value. • "scope" - an unsigned 8 bit integer. IPv4 only. • "src" - an IPv4 address. • "table" - an unsigned 32 bit integer. The default depends on ipv4.route-table. • "tos" - an unsigned 8 bit integer. IPv4 only. • "type" - one of unicast, local, blackhole, unavailable, prohibit. The default is unicast. • "window" - an unsigned 32 bit integer. For details see also `man ip-route`. Format: a comma separated list of routes IPv6: routes A list of IPv6 destination addresses, prefix length, optional IPv6 next hop addresses, optional route metric, optional attribute. The valid syntax is: "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]". Various attributes are supported: • "cwnd" - an unsigned 32 bit integer. • "from" - an IPv6 address with optional prefix. IPv6 only. • "initcwnd" - an unsigned 32 bit integer. • "initrwnd" - an unsigned 32 bit integer. • "lock-cwnd" - a boolean value. • "lock-initcwnd" - a boolean value. • "lock-initrwnd" - a boolean value. • "lock-mtu" - a boolean value. • "lock-window" - a boolean value. • "mtu" - an unsigned 32 bit integer. • "onlink" - a boolean value. • "src" - an IPv6 address. • "table" - an unsigned 32 bit integer. The default depends on ipv6.route-table. • "type" - one of unicast, local, blackhole, unavailable, prohibit. The default is unicast. • "window" - an unsigned 32 bit integer. For details see also `man ip-route`. Format: a comma separated list of routes (cherry picked from commit 7b1e9a5c3d146c7ddd83f552c290fc841388cfda)
2022-02-09 19:04:05 +01:00
/* ---nmcli---
* property: routes
* format: a comma separated list of routes
* description-docbook:
* <para>
* A list of IPv6 destination addresses, prefix length, optional IPv6
* next hop addresses, optional route metric, optional attribute. The valid syntax is:
* "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]".
* </para>
* <para>
* Various attributes are supported:
* <itemizedlist>
* <listitem>
libnm,core: add support for {rto_min,quickack,advmss} route attributes
2022-06-23 22:01:12 +02:00
* <para><literal>"advmss"</literal> - an unsigned 32 bit integer.</para>
* </listitem>
* <listitem>
libnm/doc: list route attributes in `man nm-settings-nmcli` IPv4: routes A list of IPv4 destination addresses, prefix length, optional IPv4 next hop addresses, optional route metric, optional attribute. The valid syntax is: "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]". For example "192.0.2.0/24 10.1.1.1 77, 198.51.100.0/24". Various attributes are supported: • "cwnd" - an unsigned 32 bit integer. • "initcwnd" - an unsigned 32 bit integer. • "initrwnd" - an unsigned 32 bit integer. • "lock-cwnd" - a boolean value. • "lock-initcwnd" - a boolean value. • "lock-initrwnd" - a boolean value. • "lock-mtu" - a boolean value. • "lock-window" - a boolean value. • "mtu" - an unsigned 32 bit integer. • "onlink" - a boolean value. • "scope" - an unsigned 8 bit integer. IPv4 only. • "src" - an IPv4 address. • "table" - an unsigned 32 bit integer. The default depends on ipv4.route-table. • "tos" - an unsigned 8 bit integer. IPv4 only. • "type" - one of unicast, local, blackhole, unavailable, prohibit. The default is unicast. • "window" - an unsigned 32 bit integer. For details see also `man ip-route`. Format: a comma separated list of routes IPv6: routes A list of IPv6 destination addresses, prefix length, optional IPv6 next hop addresses, optional route metric, optional attribute. The valid syntax is: "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]". Various attributes are supported: • "cwnd" - an unsigned 32 bit integer. • "from" - an IPv6 address with optional prefix. IPv6 only. • "initcwnd" - an unsigned 32 bit integer. • "initrwnd" - an unsigned 32 bit integer. • "lock-cwnd" - a boolean value. • "lock-initcwnd" - a boolean value. • "lock-initrwnd" - a boolean value. • "lock-mtu" - a boolean value. • "lock-window" - a boolean value. • "mtu" - an unsigned 32 bit integer. • "onlink" - a boolean value. • "src" - an IPv6 address. • "table" - an unsigned 32 bit integer. The default depends on ipv6.route-table. • "type" - one of unicast, local, blackhole, unavailable, prohibit. The default is unicast. • "window" - an unsigned 32 bit integer. For details see also `man ip-route`. Format: a comma separated list of routes (cherry picked from commit 7b1e9a5c3d146c7ddd83f552c290fc841388cfda)
2022-02-09 19:04:05 +01:00
* <para><literal>"cwnd"</literal> - an unsigned 32 bit integer.</para>
* </listitem>
* <listitem>
* <para><literal>"from"</literal> - an IPv6 address with optional prefix. IPv6 only.</para>
* </listitem>
* <listitem>
* <para><literal>"initcwnd"</literal> - an unsigned 32 bit integer.</para>
* </listitem>
* <listitem>
* <para><literal>"initrwnd"</literal> - an unsigned 32 bit integer.</para>
* </listitem>
* <listitem>
libnm,core: add support for {rto_min,quickack,advmss} route attributes
2022-06-23 22:01:12 +02:00
* <para><literal>"lock-advmss"</literal> - a boolean value.</para>
* </listitem>
* <listitem>
libnm/doc: list route attributes in `man nm-settings-nmcli` IPv4: routes A list of IPv4 destination addresses, prefix length, optional IPv4 next hop addresses, optional route metric, optional attribute. The valid syntax is: "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]". For example "192.0.2.0/24 10.1.1.1 77, 198.51.100.0/24". Various attributes are supported: • "cwnd" - an unsigned 32 bit integer. • "initcwnd" - an unsigned 32 bit integer. • "initrwnd" - an unsigned 32 bit integer. • "lock-cwnd" - a boolean value. • "lock-initcwnd" - a boolean value. • "lock-initrwnd" - a boolean value. • "lock-mtu" - a boolean value. • "lock-window" - a boolean value. • "mtu" - an unsigned 32 bit integer. • "onlink" - a boolean value. • "scope" - an unsigned 8 bit integer. IPv4 only. • "src" - an IPv4 address. • "table" - an unsigned 32 bit integer. The default depends on ipv4.route-table. • "tos" - an unsigned 8 bit integer. IPv4 only. • "type" - one of unicast, local, blackhole, unavailable, prohibit. The default is unicast. • "window" - an unsigned 32 bit integer. For details see also `man ip-route`. Format: a comma separated list of routes IPv6: routes A list of IPv6 destination addresses, prefix length, optional IPv6 next hop addresses, optional route metric, optional attribute. The valid syntax is: "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]". Various attributes are supported: • "cwnd" - an unsigned 32 bit integer. • "from" - an IPv6 address with optional prefix. IPv6 only. • "initcwnd" - an unsigned 32 bit integer. • "initrwnd" - an unsigned 32 bit integer. • "lock-cwnd" - a boolean value. • "lock-initcwnd" - a boolean value. • "lock-initrwnd" - a boolean value. • "lock-mtu" - a boolean value. • "lock-window" - a boolean value. • "mtu" - an unsigned 32 bit integer. • "onlink" - a boolean value. • "src" - an IPv6 address. • "table" - an unsigned 32 bit integer. The default depends on ipv6.route-table. • "type" - one of unicast, local, blackhole, unavailable, prohibit. The default is unicast. • "window" - an unsigned 32 bit integer. For details see also `man ip-route`. Format: a comma separated list of routes (cherry picked from commit 7b1e9a5c3d146c7ddd83f552c290fc841388cfda)
2022-02-09 19:04:05 +01:00
* <para><literal>"lock-cwnd"</literal> - a boolean value.</para>
* </listitem>
* <listitem>
* <para><literal>"lock-initcwnd"</literal> - a boolean value.</para>
* </listitem>
* <listitem>
* <para><literal>"lock-initrwnd"</literal> - a boolean value.</para>
* </listitem>
* <listitem>
* <para><literal>"lock-mtu"</literal> - a boolean value.</para>
* </listitem>
* <listitem>
* <para><literal>"lock-window"</literal> - a boolean value.</para>
* </listitem>
* <listitem>
* <para><literal>"mtu"</literal> - an unsigned 32 bit integer.</para>
* </listitem>
* <listitem>
* <para><literal>"onlink"</literal> - a boolean value.</para>
* </listitem>
* <listitem>
libnm,core: add support for {rto_min,quickack,advmss} route attributes
2022-06-23 22:01:12 +02:00
* <para><literal>"quickack"</literal> - a boolean value.</para>
* </listitem>
* <listitem>
* <para><literal>"rto_min"</literal> - an unsigned 32 bit integer.
* The value is in milliseconds.</para>
* </listitem>
* <listitem>
libnm/doc: list route attributes in `man nm-settings-nmcli` IPv4: routes A list of IPv4 destination addresses, prefix length, optional IPv4 next hop addresses, optional route metric, optional attribute. The valid syntax is: "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]". For example "192.0.2.0/24 10.1.1.1 77, 198.51.100.0/24". Various attributes are supported: • "cwnd" - an unsigned 32 bit integer. • "initcwnd" - an unsigned 32 bit integer. • "initrwnd" - an unsigned 32 bit integer. • "lock-cwnd" - a boolean value. • "lock-initcwnd" - a boolean value. • "lock-initrwnd" - a boolean value. • "lock-mtu" - a boolean value. • "lock-window" - a boolean value. • "mtu" - an unsigned 32 bit integer. • "onlink" - a boolean value. • "scope" - an unsigned 8 bit integer. IPv4 only. • "src" - an IPv4 address. • "table" - an unsigned 32 bit integer. The default depends on ipv4.route-table. • "tos" - an unsigned 8 bit integer. IPv4 only. • "type" - one of unicast, local, blackhole, unavailable, prohibit. The default is unicast. • "window" - an unsigned 32 bit integer. For details see also `man ip-route`. Format: a comma separated list of routes IPv6: routes A list of IPv6 destination addresses, prefix length, optional IPv6 next hop addresses, optional route metric, optional attribute. The valid syntax is: "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]". Various attributes are supported: • "cwnd" - an unsigned 32 bit integer. • "from" - an IPv6 address with optional prefix. IPv6 only. • "initcwnd" - an unsigned 32 bit integer. • "initrwnd" - an unsigned 32 bit integer. • "lock-cwnd" - a boolean value. • "lock-initcwnd" - a boolean value. • "lock-initrwnd" - a boolean value. • "lock-mtu" - a boolean value. • "lock-window" - a boolean value. • "mtu" - an unsigned 32 bit integer. • "onlink" - a boolean value. • "src" - an IPv6 address. • "table" - an unsigned 32 bit integer. The default depends on ipv6.route-table. • "type" - one of unicast, local, blackhole, unavailable, prohibit. The default is unicast. • "window" - an unsigned 32 bit integer. For details see also `man ip-route`. Format: a comma separated list of routes (cherry picked from commit 7b1e9a5c3d146c7ddd83f552c290fc841388cfda)
2022-02-09 19:04:05 +01:00
* <para><literal>"src"</literal> - an IPv6 address.</para>
* </listitem>
* <listitem>
* <para><literal>"table"</literal> - an unsigned 32 bit integer. The default depends on ipv6.route-table.</para>
* </listitem>
* <listitem>
* <para><literal>"type"</literal> - one of <literal>unicast</literal>, <literal>local</literal>, <literal>blackhole</literal>,
all: add support for route type "throw" After adding support for "blackhole", "unreachable" and "prohibit" route types, let's also add support for "throw" type. It works basically the same as the other types, so supporting it seems very straight forward. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1124
2022-02-25 21:01:04 +01:00
* <literal>unavailable</literal>, <literal>prohibit</literal>, <literal>throw</literal>.
* The default is <literal>unicast</literal>.</para>
libnm/doc: list route attributes in `man nm-settings-nmcli` IPv4: routes A list of IPv4 destination addresses, prefix length, optional IPv4 next hop addresses, optional route metric, optional attribute. The valid syntax is: "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]". For example "192.0.2.0/24 10.1.1.1 77, 198.51.100.0/24". Various attributes are supported: • "cwnd" - an unsigned 32 bit integer. • "initcwnd" - an unsigned 32 bit integer. • "initrwnd" - an unsigned 32 bit integer. • "lock-cwnd" - a boolean value. • "lock-initcwnd" - a boolean value. • "lock-initrwnd" - a boolean value. • "lock-mtu" - a boolean value. • "lock-window" - a boolean value. • "mtu" - an unsigned 32 bit integer. • "onlink" - a boolean value. • "scope" - an unsigned 8 bit integer. IPv4 only. • "src" - an IPv4 address. • "table" - an unsigned 32 bit integer. The default depends on ipv4.route-table. • "tos" - an unsigned 8 bit integer. IPv4 only. • "type" - one of unicast, local, blackhole, unavailable, prohibit. The default is unicast. • "window" - an unsigned 32 bit integer. For details see also `man ip-route`. Format: a comma separated list of routes IPv6: routes A list of IPv6 destination addresses, prefix length, optional IPv6 next hop addresses, optional route metric, optional attribute. The valid syntax is: "ip[/prefix] [next-hop] [metric] [attribute=val]...[,ip[/prefix]...]". Various attributes are supported: • "cwnd" - an unsigned 32 bit integer. • "from" - an IPv6 address with optional prefix. IPv6 only. • "initcwnd" - an unsigned 32 bit integer. • "initrwnd" - an unsigned 32 bit integer. • "lock-cwnd" - a boolean value. • "lock-initcwnd" - a boolean value. • "lock-initrwnd" - a boolean value. • "lock-mtu" - a boolean value. • "lock-window" - a boolean value. • "mtu" - an unsigned 32 bit integer. • "onlink" - a boolean value. • "src" - an IPv6 address. • "table" - an unsigned 32 bit integer. The default depends on ipv6.route-table. • "type" - one of unicast, local, blackhole, unavailable, prohibit. The default is unicast. • "window" - an unsigned 32 bit integer. For details see also `man ip-route`. Format: a comma separated list of routes (cherry picked from commit 7b1e9a5c3d146c7ddd83f552c290fc841388cfda)
2022-02-09 19:04:05 +01:00
* </listitem>
* <listitem>
* <para><literal>"window"</literal> - an unsigned 32 bit integer.</para>
* </listitem>
* </itemizedlist>
* </para>
* <para>
* For details see also `man ip-route`.
* </para>
* ---end---
*/
libnm/trivial: rename _properties_override_add_*() to _nm_properties_override_*() These macros/functions are in a header file. Everything in a header file should have an "nm" prefix. Rename.
2019-09-22 15:32:04 +02:00
_nm_properties_override_gobj(
properties_override,
g_object_class_find_property(G_OBJECT_CLASS(setting_class), NM_SETTING_IP_CONFIG_ROUTES),
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("a(ayuayu)"),
.to_dbus_fcn = ip6_routes_get,
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
2021-06-29 14:37:16 +02:00
.compare_fcn = _nm_setting_ip_config_compare_fcn_routes,
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
.from_dbus_fcn = ip6_routes_set, ));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: Override parts of nm-setting-docs.xml Add "---dbus---" sections to the NMSetting property docs, in the same style as the plugin docs, parse them out into a file "nm-setting-docs-overrides.xml", and use them to override the GObject property docs in nm-setting-docs.xml. This lets us put more D-Bus-specific information in the setting docs, without cluttering up the property docs, and it also lets us document dbus-only properties.
2014-11-16 15:36:18 -05:00
/* ---dbus---
* property: route-data
* format: array of vardict
* description: Array of IPv6 routes. Each route dictionary contains at
* least 'dest' and 'prefix' entries, containing the destination IP
* address as a string, and the prefix length as a uint32. Most routes
* will also have a 'next-hop' entry, containing the next hop IP address as
* a string. If the route has a 'metric' entry (containing a uint32), that
* will be used as the metric for the route (otherwise NM will pick a
* default value appropriate to the device). Additional attributes may
* also exist on some routes.
* ---end---
*/
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
_nm_properties_override_dbus(
properties_override,
"route-data",
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("aa{sv}"),
.to_dbus_fcn = ip6_route_data_get,
libnm: add special ignore function for NMSettInfoPropertType.compare_fcn()
2021-06-29 17:03:37 +02:00
.compare_fcn = _nm_setting_property_compare_fcn_ignore,
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
.from_dbus_fcn = ip6_route_data_set, ));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm/doc: describe routing-rules in `man nm-settings-nmcli` (cherry picked from commit 948c2b0fb1c6a51b03ac6cfeb79febf19a234f20)
2022-02-09 20:31:47 +01:00
/* ---nmcli---
* property: routing-rules
* format: a comma separated list of routing rules
* description: A comma separated list of routing rules for policy routing.
* description-docbook:
* <para>
* A comma separated list of routing rules for policy routing. The format
* is based on <command>ip rule add</command> syntax and mostly compatible.
* One difference is that routing rules in NetworkManager always need a
* fixed priority.
* </para>
* <para>
* Example: <literal>priority 5 from 1:2:3::5/128 table 45</literal>
* </para>
* ---end---
*/
libnm-core: cleanup NMSetting's class initialization Unify the coding style for class-init functions in libnm-core. Also make use of obj_properties, NM_GOBJECT_PROPERTIES_DEFINE(), and _notify().
2019-01-11 08:28:26 +01:00
g_object_class_install_properties(object_class, _PROPERTY_ENUMS_LAST, obj_properties);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: extend NMSettInfoSetting with an offset to the private data NMSetting instances either have no private data, they use g_type_add_class_private(), or they embed the private data in the NMSetting struct. In all cases, we can find the private data at a fixed offset. Track that offset in the NMSettInfoSetting meta data. This will be useful, because properties really are stored in simple fields, like a boolean property can be stored in a "bool" field. We will extend the property meta data to track the offset of this property field, but we also need to know where the offset starts.
2021-06-28 14:53:16 +02:00
_nm_setting_class_commit(setting_class,
NM_META_SETTING_TYPE_IP6_CONFIG,
NULL,
properties_override,
libnm: let NMSettingIPConfigPrivate be tracked by subclasses For our property meta data handling we require that all the meta data is associated with one GType. NMSettingIPConfig is a parent class of NMSettingIP[46]Config. Note that we already have _nm_sett_info_property_override_create_array_ip_config() because the meta data must be initialized together at one place. We will require that we can find the offset for properties based on one offset per type. That is cumbersome, if NMSettingIPConfigPrivate is private itself. Simplify that, by internally sharing NMSettingIPConfigPrivate and let the subclasses embed the private data in their own private data. Optimally we would simply embed the private struct as field into NMSettingIPConfig. But that would be an ABI change as that struct was public before 1.32. Don't change ABI for now, so we have to awkwardly place it into the subclasses private data.
2021-06-28 18:14:04 +02:00
setting_ip_config_class->private_offset);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
Reference in a new issue Copy permalink