2020-12-23 22:21:36 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1-or-later */
|
2014-07-24 08:53:33 -04:00
|
|
|
/*
|
2019-10-01 09:20:35 +02:00
|
|
|
* Copyright (C) 2014 Red Hat, Inc.
|
2014-07-24 08:53:33 -04:00
|
|
|
*/
|
|
|
|
|
|
2021-02-12 15:01:09 +01:00
|
|
|
#include "libnm-core-impl/nm-default-libnm-core.h"
|
2014-11-13 10:07:02 -05:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
#include "nm-setting-ip4-config.h"
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
#include "nm-setting-private.h"
|
2021-06-29 21:53:55 +02:00
|
|
|
#include "nm-utils-private.h"
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* SECTION:nm-setting-ip4-config
|
|
|
|
|
* @short_description: Describes IPv4 addressing, routing, and name service properties
|
|
|
|
|
*
|
|
|
|
|
* The #NMSettingIP4Config object is a #NMSetting subclass that describes
|
2014-10-19 17:30:10 -04:00
|
|
|
* properties related to IPv4 addressing, routing, and Domain Name Service.
|
|
|
|
|
*
|
|
|
|
|
* #NMSettingIP4Config has few properties or methods of its own; it inherits
|
|
|
|
|
* almost everything from #NMSettingIPConfig.
|
|
|
|
|
*
|
|
|
|
|
* NetworkManager supports 5 values for the #NMSettingIPConfig:method property
|
|
|
|
|
* for IPv4. If "auto" is specified then the appropriate automatic method
|
|
|
|
|
* (DHCP, PPP, etc) is used for the interface and most other properties can be
|
|
|
|
|
* left unset. If "link-local" is specified, then a link-local address in the
|
|
|
|
|
* 169.254/16 range 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 "shared" is specified (indicating that
|
|
|
|
|
* this connection will provide network access to other computers) then the
|
|
|
|
|
* interface is assigned an address in the 10.42.x.1/24 range and a DHCP and
|
|
|
|
|
* forwarding DNS server are started, and the interface is NAT-ed to the current
|
|
|
|
|
* default network connection. "disabled" means IPv4 will not be used on this
|
|
|
|
|
* connection.
|
|
|
|
|
**/
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
NM_GOBJECT_PROPERTIES_DEFINE_BASE(PROP_DHCP_CLIENT_ID,
|
|
|
|
|
PROP_DHCP_FQDN,
|
settings: add ipv4.link-local flag
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
2022-04-08 13:11:56 +02:00
|
|
|
PROP_DHCP_VENDOR_CLASS_IDENTIFIER,
|
|
|
|
|
PROP_LINK_LOCAL, );
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
typedef struct {
|
2021-06-28 18:14:04 +02:00
|
|
|
NMSettingIPConfigPrivate parent;
|
|
|
|
|
|
settings: add ipv4.link-local flag
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
2022-04-08 13:11:56 +02:00
|
|
|
char *dhcp_client_id;
|
|
|
|
|
char *dhcp_fqdn;
|
|
|
|
|
char *dhcp_vendor_class_identifier;
|
|
|
|
|
gint32 link_local;
|
2014-07-24 08:53:33 -04:00
|
|
|
} NMSettingIP4ConfigPrivate;
|
|
|
|
|
|
2021-06-11 00:27:31 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingIP4Config:
|
|
|
|
|
*
|
|
|
|
|
* IPv4 Settings
|
|
|
|
|
*/
|
|
|
|
|
struct _NMSettingIP4Config {
|
libnm: embed private structure in NMSetting and avoid g_type_class_add_private()
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
|
|
|
NMSettingIPConfig parent;
|
|
|
|
|
NMSettingIP4ConfigPrivate _priv;
|
2021-06-11 00:27:31 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _NMSettingIP4ConfigClass {
|
|
|
|
|
NMSettingIPConfigClass parent;
|
|
|
|
|
};
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
G_DEFINE_TYPE(NMSettingIP4Config, nm_setting_ip4_config, NM_TYPE_SETTING_IP_CONFIG)
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
#define NM_SETTING_IP4_CONFIG_GET_PRIVATE(o) \
|
libnm: embed private structure in NMSetting and avoid g_type_class_add_private()
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
|
|
|
_NM_GET_PRIVATE(o, NMSettingIP4Config, NM_IS_SETTING_IP4_CONFIG, NMSettingIPConfig, NMSetting)
|
2019-01-11 08:32:54 +01:00
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_ip4_config_get_dhcp_client_id:
|
|
|
|
|
* @setting: the #NMSettingIP4Config
|
|
|
|
|
*
|
|
|
|
|
* Returns the value contained in the #NMSettingIP4Config:dhcp-client-id
|
|
|
|
|
* property.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the configured Client ID to send to the DHCP server when requesting
|
|
|
|
|
* addresses via DHCP.
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_ip4_config_get_dhcp_client_id(NMSettingIP4Config *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_IP4_CONFIG(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_IP4_CONFIG_GET_PRIVATE(setting)->dhcp_client_id;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-13 14:10:01 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_ip4_config_get_dhcp_fqdn:
|
|
|
|
|
* @setting: the #NMSettingIP4Config
|
|
|
|
|
*
|
|
|
|
|
* Returns the value contained in the #NMSettingIP4Config:dhcp-fqdn
|
|
|
|
|
* property.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the configured FQDN to send to the DHCP server
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.2
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_ip4_config_get_dhcp_fqdn(NMSettingIP4Config *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_IP4_CONFIG(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_IP4_CONFIG_GET_PRIVATE(setting)->dhcp_fqdn;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-24 18:01:42 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_ip4_config_get_dhcp_vendor_class_identifier:
|
|
|
|
|
* @setting: the #NMSettingIP4Config
|
|
|
|
|
*
|
|
|
|
|
* Returns the value contained in the #NMSettingIP4Config:dhcp_vendor_class_identifier
|
|
|
|
|
* property.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the vendor class identifier option to send to the DHCP server
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.28
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_ip4_config_get_dhcp_vendor_class_identifier(NMSettingIP4Config *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_IP4_CONFIG(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_IP4_CONFIG_GET_PRIVATE(setting)->dhcp_vendor_class_identifier;
|
|
|
|
|
}
|
|
|
|
|
|
settings: add ipv4.link-local flag
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
2022-04-08 13:11:56 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_ip4_config_get_link_local:
|
|
|
|
|
* @setting: the #NMSettingIP4Config
|
|
|
|
|
*
|
|
|
|
|
* Returns the value contained in the #NMSettingIP4Config:link_local
|
|
|
|
|
* property.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the link-local configuration
|
|
|
|
|
*
|
2022-11-07 20:29:12 +01:00
|
|
|
* Since: 1.42
|
settings: add ipv4.link-local flag
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
2022-04-08 13:11:56 +02:00
|
|
|
**/
|
|
|
|
|
NMSettingIP4LinkLocal
|
|
|
|
|
nm_setting_ip4_config_get_link_local(NMSettingIP4Config *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_IP4_CONFIG(setting), NM_SETTING_IP4_LL_DEFAULT);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_IP4_CONFIG_GET_PRIVATE(setting)->link_local;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
static gboolean
|
2014-10-21 22:30:31 -04:00
|
|
|
verify(NMSetting *setting, NMConnection *connection, GError **error)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
|
|
|
|
NMSettingIP4ConfigPrivate *priv = NM_SETTING_IP4_CONFIG_GET_PRIVATE(setting);
|
2021-11-09 13:28:54 +01:00
|
|
|
NMSettingIPConfig *s_ip = NM_SETTING_IP_CONFIG(setting);
|
2014-10-20 21:30:56 -04:00
|
|
|
NMSettingVerifyResult ret;
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *method;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-10-20 21:30:56 -04:00
|
|
|
ret = NM_SETTING_CLASS(nm_setting_ip4_config_parent_class)->verify(setting, connection, error);
|
|
|
|
|
if (ret != NM_SETTING_VERIFY_SUCCESS)
|
|
|
|
|
return ret;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
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);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-10-19 17:30:10 -04:00
|
|
|
if (!strcmp(method, NM_SETTING_IP4_CONFIG_METHOD_MANUAL)) {
|
|
|
|
|
if (nm_setting_ip_config_get_num_addresses(s_ip) == 0) {
|
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,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("this property cannot be empty for '%s=%s'"),
|
2014-10-19 17:30:10 -04:00
|
|
|
NM_SETTING_IP_CONFIG_METHOD,
|
|
|
|
|
method);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP_CONFIG_ADDRESSES);
|
2014-07-24 08:53:33 -04:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
2014-10-19 17:30:10 -04:00
|
|
|
} else if (!strcmp(method, NM_SETTING_IP4_CONFIG_METHOD_LINK_LOCAL)
|
|
|
|
|
|| !strcmp(method, NM_SETTING_IP4_CONFIG_METHOD_SHARED)
|
|
|
|
|
|| !strcmp(method, NM_SETTING_IP4_CONFIG_METHOD_DISABLED)) {
|
|
|
|
|
if (nm_setting_ip_config_get_num_dns(s_ip) > 0) {
|
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_INVALID_PROPERTY,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("this property is not allowed for '%s=%s'"),
|
2014-10-19 17:30:10 -04:00
|
|
|
NM_SETTING_IP_CONFIG_METHOD,
|
|
|
|
|
method);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP_CONFIG_DNS);
|
2014-07-24 08:53:33 -04:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-10-19 17:30:10 -04:00
|
|
|
if (nm_setting_ip_config_get_num_dns_searches(s_ip) > 0) {
|
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_INVALID_PROPERTY,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("this property is not allowed for '%s=%s'"),
|
2014-10-19 17:30:10 -04:00
|
|
|
NM_SETTING_IP_CONFIG_METHOD,
|
|
|
|
|
method);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP_CONFIG_DNS_SEARCH);
|
2014-07-24 08:53:33 -04:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/* Shared allows IP addresses; link-local and disabled do not */
|
2014-10-19 17:30:10 -04:00
|
|
|
if (strcmp(method, NM_SETTING_IP4_CONFIG_METHOD_SHARED) != 0) {
|
|
|
|
|
if (nm_setting_ip_config_get_num_addresses(s_ip) > 0) {
|
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_INVALID_PROPERTY,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("this property is not allowed for '%s=%s'"),
|
2014-10-19 17:30:10 -04:00
|
|
|
NM_SETTING_IP_CONFIG_METHOD,
|
|
|
|
|
method);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP_CONFIG_ADDRESSES);
|
2014-07-24 08:53:33 -04:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
}
|
2014-10-19 17:30:10 -04:00
|
|
|
} else if (!strcmp(method, NM_SETTING_IP4_CONFIG_METHOD_AUTO)) {
|
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,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("property is invalid"));
|
2014-10-19 17:30:10 -04:00
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP_CONFIG_METHOD);
|
2014-07-24 08:53:33 -04:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
settings: add ipv4.link-local flag
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
2022-04-08 13:11:56 +02:00
|
|
|
if (!NM_IN_SET(priv->link_local,
|
|
|
|
|
NM_SETTING_IP4_LL_AUTO,
|
|
|
|
|
NM_SETTING_IP4_LL_DEFAULT,
|
|
|
|
|
NM_SETTING_IP4_LL_DISABLED,
|
|
|
|
|
NM_SETTING_IP4_LL_ENABLED)) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("property is invalid"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_LINK_LOCAL);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
if (priv->link_local == NM_SETTING_IP4_LL_ENABLED
|
|
|
|
|
&& nm_streq(method, NM_SETTING_IP4_CONFIG_METHOD_DISABLED)) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("cannot enable ipv4.link-local with ipv4.method=disabled"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_LINK_LOCAL);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
if (priv->link_local == NM_SETTING_IP4_LL_DISABLED
|
|
|
|
|
&& nm_streq(method, NM_SETTING_IP4_CONFIG_METHOD_LINK_LOCAL)) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("cannot disable ipv4.link-local with ipv4.method=link-local"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_LINK_LOCAL);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-04 16:12:40 +01:00
|
|
|
if (priv->dhcp_client_id && !priv->dhcp_client_id[0]) {
|
2014-07-24 08:53:33 -04:00
|
|
|
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,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("property is empty"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_DHCP_CLIENT_ID);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-10-13 14:10:01 +02:00
|
|
|
if (priv->dhcp_fqdn && !*priv->dhcp_fqdn) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("property is empty"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_DHCP_FQDN);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-10-13 14:10:01 +02:00
|
|
|
if (priv->dhcp_fqdn && !strchr(priv->dhcp_fqdn, '.')) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("'%s' is not a valid FQDN"),
|
|
|
|
|
priv->dhcp_fqdn);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_DHCP_FQDN);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-10-13 14:10:01 +02:00
|
|
|
if (priv->dhcp_fqdn && nm_setting_ip_config_get_dhcp_hostname(s_ip)) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("property cannot be set when dhcp-hostname is also set"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_DHCP_FQDN);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-07-09 11:26:02 +02:00
|
|
|
if (NM_FLAGS_ANY(nm_setting_ip_config_get_dhcp_hostname_flags(s_ip),
|
|
|
|
|
NM_DHCP_HOSTNAME_FLAGS_FQDN_MASK)
|
|
|
|
|
&& !priv->dhcp_fqdn) {
|
2020-07-01 17:20:40 -04:00
|
|
|
/* Currently, we send a FQDN option only when ipv4.dhcp-fqdn is set */
|
2019-07-09 11:26:02 +02:00
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("FQDN flags requires a FQDN set"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP_CONFIG_DHCP_HOSTNAME_FLAGS);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-08-27 18:18:31 +02:00
|
|
|
if (priv->dhcp_vendor_class_identifier
|
|
|
|
|
&& !nm_utils_validate_dhcp4_vendor_class_id(priv->dhcp_vendor_class_identifier, error))
|
|
|
|
|
return FALSE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-09-12 18:51:00 +02:00
|
|
|
/* Failures from here on are NORMALIZABLE_ERROR... */
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-09-12 18:51:00 +02:00
|
|
|
if (nm_streq(method, NM_SETTING_IP4_CONFIG_METHOD_SHARED)
|
|
|
|
|
&& nm_setting_ip_config_get_num_addresses(s_ip) > 1) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("multiple addresses are not allowed for '%s=%s'"),
|
|
|
|
|
NM_SETTING_IP_CONFIG_METHOD,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_METHOD_SHARED);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP_CONFIG_ADDRESSES);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-07-01 17:05:42 +02:00
|
|
|
/* Failures from here on are NORMALIZABLE... */
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-07-01 17:05:42 +02:00
|
|
|
if (!strcmp(method, NM_SETTING_IP4_CONFIG_METHOD_DISABLED)
|
|
|
|
|
&& !nm_setting_ip_config_get_may_fail(s_ip)) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("property should be TRUE when method is set to disabled"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_SETTING_IP_CONFIG_MAY_FAIL);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
ip4_dns_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
|
2014-08-16 10:09:48 -04:00
|
|
|
{
|
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;
|
|
|
|
|
|
2022-10-24 18:36:29 +02:00
|
|
|
return nm_utils_dns_to_variant(AF_INET, (const char *const *) dns->pdata, dns->len);
|
2014-08-16 10:09:48 -04:00
|
|
|
}
|
|
|
|
|
|
libnm: add "dns-data" replacement for "ipv[46].dns" properties on D-Bus
On D-Bus, the properties "ipv[46].dns" are of type "au" and "aay",
respectively.
Btw, in particular "au" is bad, because we put there a big-endian
number. There is no D-Bus type to represent big endian numbers, so "u"
is bad because it can cause endianess problem when trying to remote
the D-Bus communication to another host (without explicitly
understanding which "u" properties need to swap for endinness).
Anyway. The plain addresses are not enough. We soon will also support
the DNS-over-TLS server name, or maybe a DoT port number. The previous
property was not extensible, so deprecate it and replace it by
"dns-data".
This one is just a list of strings. That is unlike "address-data" or
"route-data", which do a similar thing but are "a{sv}" dictionaries.
Here a string is supposed to be sufficient also for the future. Also,
because in nmcli and keyfile will will simply have a string format for
representing the extra data, not a structure (unlike for routes or
addresses).
2022-10-21 14:50:32 +02:00
|
|
|
static gboolean
|
|
|
|
|
ip4_dns_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
|
2014-08-16 10:09:48 -04:00
|
|
|
{
|
libnm: add "dns-data" replacement for "ipv[46].dns" properties on D-Bus
On D-Bus, the properties "ipv[46].dns" are of type "au" and "aay",
respectively.
Btw, in particular "au" is bad, because we put there a big-endian
number. There is no D-Bus type to represent big endian numbers, so "u"
is bad because it can cause endianess problem when trying to remote
the D-Bus communication to another host (without explicitly
understanding which "u" properties need to swap for endinness).
Anyway. The plain addresses are not enough. We soon will also support
the DNS-over-TLS server name, or maybe a DoT port number. The previous
property was not extensible, so deprecate it and replace it by
"dns-data".
This one is just a list of strings. That is unlike "address-data" or
"route-data", which do a similar thing but are "a{sv}" dictionaries.
Here a string is supposed to be sufficient also for the future. Also,
because in nmcli and keyfile will will simply have a string format for
representing the extra data, not a structure (unlike for routes or
addresses).
2022-10-21 14:50:32 +02:00
|
|
|
gs_strfreev char **strv = NULL;
|
|
|
|
|
|
|
|
|
|
if (!_nm_setting_use_legacy_property(setting, connection_dict, "dns", "dns-data")) {
|
|
|
|
|
*out_is_modified = FALSE;
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
strv = nm_utils_ip4_dns_from_variant(value);
|
|
|
|
|
g_object_set(setting, NM_SETTING_IP_CONFIG_DNS, strv, NULL);
|
|
|
|
|
return TRUE;
|
2014-08-16 10:09:48 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static GVariant *
|
2022-10-21 14:50:27 +02:00
|
|
|
ip4_addresses_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
|
2014-08-16 10:09:48 -04:00
|
|
|
{
|
2019-04-24 17:41:32 +02:00
|
|
|
gs_unref_ptrarray GPtrArray *addrs = NULL;
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *gateway;
|
2014-09-16 16:38:04 -04:00
|
|
|
|
2019-04-24 17:41:32 +02:00
|
|
|
g_object_get(setting, NM_SETTING_IP_CONFIG_ADDRESSES, &addrs, NULL);
|
2014-10-20 21:30:56 -04:00
|
|
|
gateway = nm_setting_ip_config_get_gateway(NM_SETTING_IP_CONFIG(setting));
|
2019-04-24 17:41:32 +02:00
|
|
|
return nm_utils_ip4_addresses_to_variant(addrs, gateway);
|
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
|
2022-10-21 14:50:27 +02:00
|
|
|
ip4_addresses_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
|
2014-08-16 10:09:48 -04:00
|
|
|
{
|
2022-10-21 14:55:15 +02:00
|
|
|
gs_unref_ptrarray GPtrArray *addrs = NULL;
|
|
|
|
|
gs_unref_variant GVariant *s_ip4 = NULL;
|
|
|
|
|
gs_free const char **labels = NULL;
|
|
|
|
|
gs_free char *gateway = NULL;
|
|
|
|
|
guint i;
|
2020-09-28 16:03:33 +02: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
|
|
|
/* FIXME: properly handle errors */
|
2020-09-28 16:03:33 +02:00
|
|
|
|
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;
|
2021-07-27 10:27:44 +02:00
|
|
|
}
|
2020-09-28 16:03:33 +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_ip4_addresses_from_variant(value, &gateway);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-11-14 11:46:19 -05:00
|
|
|
s_ip4 = g_variant_lookup_value(connection_dict,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_SETTING_NAME,
|
|
|
|
|
NM_VARIANT_TYPE_SETTING);
|
2022-10-21 14:55:15 +02:00
|
|
|
if (g_variant_lookup(s_ip4, "address-labels", "^a&s", &labels)) {
|
|
|
|
|
for (i = 0; i < addrs->len && labels[i]; i++) {
|
|
|
|
|
if (*labels[i]) {
|
2017-12-11 14:06:10 +01:00
|
|
|
nm_ip_address_set_attribute(addrs->pdata[i],
|
|
|
|
|
NM_IP_ADDRESS_ATTRIBUTE_LABEL,
|
|
|
|
|
g_variant_new_string(labels[i]));
|
2022-10-21 14:55:15 +02:00
|
|
|
}
|
|
|
|
|
}
|
2014-09-16 16:38:04 -04:00
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
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: 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;
|
2014-09-16 16:38:04 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static GVariant *
|
2022-10-21 14:50:27 +02:00
|
|
|
ip4_address_labels_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
|
2014-09-16 16:38:04 -04:00
|
|
|
{
|
2014-10-19 17:30:10 -04:00
|
|
|
NMSettingIPConfig *s_ip = NM_SETTING_IP_CONFIG(setting);
|
2014-10-28 12:49:56 -04:00
|
|
|
gboolean have_labels = FALSE;
|
2022-10-21 14:55:15 +02:00
|
|
|
gs_free GVariant **labels_free = NULL;
|
|
|
|
|
GVariant *s_empty;
|
|
|
|
|
GVariant **labels;
|
|
|
|
|
guint num_addrs;
|
|
|
|
|
guint i;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-03-25 16:39:35 +01:00
|
|
|
if (!_nm_connection_serialize_non_secret(flags))
|
2019-01-02 15:54:18 +01:00
|
|
|
return NULL;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-10-19 17:30:10 -04:00
|
|
|
num_addrs = nm_setting_ip_config_get_num_addresses(s_ip);
|
2022-10-21 14:55:15 +02:00
|
|
|
if (num_addrs == 0)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
labels = nm_malloc_maybe_a(500, sizeof(gpointer) * num_addrs, &labels_free);
|
|
|
|
|
|
|
|
|
|
s_empty = nm_g_variant_singleton_s_empty();
|
|
|
|
|
|
2014-10-19 17:30:10 -04:00
|
|
|
for (i = 0; i < num_addrs; i++) {
|
|
|
|
|
NMIPAddress *addr = nm_setting_ip_config_get_address(s_ip, i);
|
2021-11-09 13:28:54 +01:00
|
|
|
GVariant *label = nm_ip_address_get_attribute(addr, NM_IP_ADDRESS_ATTRIBUTE_LABEL);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-10-28 12:49:56 -04:00
|
|
|
if (label) {
|
|
|
|
|
have_labels = TRUE;
|
2022-10-21 14:55:15 +02:00
|
|
|
labels[i] = label;
|
|
|
|
|
} else
|
|
|
|
|
labels[i] = s_empty;
|
2014-10-28 12:49:56 -04:00
|
|
|
}
|
2022-10-21 14:55:15 +02:00
|
|
|
|
2014-10-28 12:49:56 -04:00
|
|
|
if (!have_labels)
|
|
|
|
|
return NULL;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-10-21 14:55:15 +02:00
|
|
|
return g_variant_new_array(G_VARIANT_TYPE_STRING, labels, num_addrs);
|
2014-08-16 10:09:48 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static GVariant *
|
2022-10-21 14:50:27 +02:00
|
|
|
ip4_address_data_to_dbus(_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
|
|
|
{
|
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
|
|
|
|
2021-03-25 16:39:35 +01:00
|
|
|
if (!_nm_connection_serialize_non_secret(flags))
|
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
|
|
|
|
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
|
2022-10-21 14:50:27 +02:00
|
|
|
ip4_address_data_from_dbus(_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
|
|
|
{
|
2022-10-21 14:55:15 +02: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-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
|
|
|
/* FIXME: properly handle errors */
|
|
|
|
|
|
2014-11-14 11:46:19 -05:00
|
|
|
/* Ignore 'address-data' if we're going to process 'addresses' */
|
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;
|
2021-07-27 10:27:44 +02:00
|
|
|
}
|
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_INET);
|
|
|
|
|
g_object_set(setting, NM_SETTING_IP_CONFIG_ADDRESSES, addrs, NULL);
|
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 *
|
2022-10-21 14:50:27 +02:00
|
|
|
ip4_routes_to_dbus(_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
|
|
|
{
|
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
|
|
|
|
2019-04-24 17:41:32 +02:00
|
|
|
g_object_get(setting, NM_SETTING_IP_CONFIG_ROUTES, &routes, NULL);
|
|
|
|
|
return nm_utils_ip4_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
|
2022-10-21 14:50:27 +02:00
|
|
|
ip4_routes_from_dbus(_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
|
|
|
{
|
2022-10-21 14:55:15 +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-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
|
|
|
/* FIXME: properly handle errors */
|
|
|
|
|
|
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;
|
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_ip4_routes_from_variant(value);
|
2021-06-29 23:51:46 +02:00
|
|
|
g_object_set(setting, property_info->name, routes, NULL);
|
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 *
|
2022-10-21 14:50:27 +02:00
|
|
|
ip4_route_data_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
|
2014-08-16 10:09:48 -04:00
|
|
|
{
|
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
|
|
|
|
2021-03-25 16:39:35 +01:00
|
|
|
if (!_nm_connection_serialize_non_secret(flags))
|
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
|
|
|
|
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);
|
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
|
2022-10-21 14:50:27 +02:00
|
|
|
ip4_route_data_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
|
2014-08-16 10:09:48 -04:00
|
|
|
{
|
2022-10-21 14:55:15 +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-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
|
|
|
/* FIXME: properly handle errors */
|
|
|
|
|
|
2014-11-14 11:46:19 -05:00
|
|
|
/* Ignore 'route-data' if we're going to process 'routes' */
|
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;
|
2021-07-27 10:27:44 +02:00
|
|
|
}
|
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_INET);
|
|
|
|
|
g_object_set(setting, NM_SETTING_IP_CONFIG_ROUTES, routes, NULL);
|
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;
|
2014-08-16 10:09:48 -04:00
|
|
|
}
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
nm_setting_ip4_config_init(NMSettingIP4Config *setting)
|
2021-06-28 18:14:04 +02:00
|
|
|
{
|
|
|
|
|
NMSettingIP4ConfigPrivate *priv = NM_SETTING_IP4_CONFIG_GET_PRIVATE(setting);
|
|
|
|
|
|
|
|
|
|
_nm_setting_ip_config_private_init(setting, &priv->parent);
|
|
|
|
|
}
|
2019-01-11 08:32:54 +01:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_ip4_config_new:
|
|
|
|
|
*
|
|
|
|
|
* Creates a new #NMSettingIP4Config object with default values.
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the new empty #NMSettingIP4Config object
|
|
|
|
|
**/
|
|
|
|
|
NMSetting *
|
|
|
|
|
nm_setting_ip4_config_new(void)
|
|
|
|
|
{
|
2020-11-12 15:57:06 +01:00
|
|
|
return g_object_new(NM_TYPE_SETTING_IP4_CONFIG, NULL);
|
2019-01-11 08:32:54 +01:00
|
|
|
}
|
|
|
|
|
|
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_ip4_config_class_init(NMSettingIP4ConfigClass *klass)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS(klass);
|
|
|
|
|
NMSettingClass *setting_class = NM_SETTING_CLASS(klass);
|
2021-06-28 18:14:04 +02:00
|
|
|
NMSettingIPConfigClass *setting_ip_config_class = NM_SETTING_IP_CONFIG_CLASS(klass);
|
2021-07-14 07:40:35 +02:00
|
|
|
GArray *properties_override = _nm_sett_info_property_override_create_array_ip_config(AF_INET);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
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;
|
2014-10-19 17:30:10 -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;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
libnm: embed private structure in NMSetting and avoid g_type_class_add_private()
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
|
|
|
setting_ip_config_class->private_offset = G_STRUCT_OFFSET(NMSettingIP4Config, _priv);
|
2022-09-26 21:50:42 +02:00
|
|
|
setting_ip_config_class->is_ipv4 = TRUE;
|
|
|
|
|
setting_ip_config_class->addr_family = AF_INET;
|
2021-06-28 18:14:04 +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: method
|
|
|
|
|
* variable: BOOTPROTO
|
2022-10-04 11:20:48 +02:00
|
|
|
* format: string
|
|
|
|
|
* values: none, dhcp (bootp), static, ibft, autoip, shared
|
|
|
|
|
* default: none
|
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: Method used for IPv4 protocol configuration.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* ---keyfile---
|
|
|
|
|
* property: dns
|
|
|
|
|
* format: list of DNS IP addresses
|
|
|
|
|
* description: List of DNS servers.
|
|
|
|
|
* example: dns=1.2.3.4;8.8.8.8;8.8.4.4;
|
|
|
|
|
* ---end---
|
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, ...
|
2022-10-04 11:20:48 +02:00
|
|
|
* format: string
|
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 DNS servers. Even if NetworkManager supports many DNS
|
|
|
|
|
* servers, initscripts and resolver only care about the first three, usually.
|
|
|
|
|
* example: DNS1=1.2.3.4 DNS2=10.0.0.254 DNS3=8.8.8.8
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: dns-search
|
|
|
|
|
* variable: DOMAIN
|
2022-10-04 11:20:48 +02:00
|
|
|
* format: string (space-separated domains)
|
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 DNS search domains.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* ---keyfile---
|
|
|
|
|
* property: addresses
|
|
|
|
|
* variable: address1, address2, ...
|
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.
|
2014-11-18 20:19:11 +01:00
|
|
|
* example: address1=192.168.100.100/24 address2=10.1.1.5/24
|
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---
|
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
|
2021-02-08 08:44:04 +01:00
|
|
|
* variable: IPADDR, PREFIX (NETMASK), IPADDR1, PREFIX1 (NETMASK1), ...
|
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.
|
2014-11-18 20:19:11 +01:00
|
|
|
* example: IPADDR=10.5.5.23 PREFIX=24 IPADDR1=1.1.1.2 PREFIX1=16
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* ---keyfile---
|
|
|
|
|
* property: gateway
|
|
|
|
|
* variable: gateway
|
|
|
|
|
* format: string
|
|
|
|
|
* description: Gateway IP addresses as a string.
|
|
|
|
|
* example: gateway=192.168.100.1
|
|
|
|
|
* ---end---
|
2022-08-29 15:05:39 +02:00
|
|
|
*/
|
|
|
|
|
/* ---ifcfg-rh---
|
2014-11-18 20:19:11 +01:00
|
|
|
* property: gateway
|
|
|
|
|
* variable: GATEWAY
|
|
|
|
|
* description: Gateway IP address.
|
|
|
|
|
* example: GATEWAY=10.5.5.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=8.8.8.0/24,10.1.1.1,77
|
|
|
|
|
* route2=7.7.0.0/16
|
|
|
|
|
* ---end---
|
2022-08-29 15:05:39 +02:00
|
|
|
*/
|
2023-08-29 15:47:10 +02:00
|
|
|
/* ---keyfile---
|
|
|
|
|
* property: routes (attributes)
|
|
|
|
|
* variable: route1_options, route2_options, ...
|
|
|
|
|
* format: key=val[,key=val...]
|
|
|
|
|
* description: Attributes defined for the routes, if any. The supported
|
|
|
|
|
* attributes are explained in ipv4.routes entry in `man nm-settings-nmcli`.
|
|
|
|
|
* example: route1_options=mtu=1000,onlink=true
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
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
|
2017-02-16 14:30:16 +01:00
|
|
|
* variable: ADDRESS1, NETMASK1, GATEWAY1, METRIC1, OPTIONS1, ...
|
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 routes. They are not stored in ifcfg-* file,
|
|
|
|
|
* but in route-* file instead.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2023-08-29 15:47:10 +02:00
|
|
|
/* ---keyfile---
|
|
|
|
|
* property: routing-rules
|
|
|
|
|
* variable: routing-rule1, routing-rule2, ...
|
|
|
|
|
* format: routing rule string
|
|
|
|
|
* description: Routing rules as defined with `ip rule add`, but with mandatory
|
|
|
|
|
* fixed priority.
|
|
|
|
|
* example: routing-rule1=priority 5 from 192.167.4.0/24 table 45
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
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: ignore-auto-routes
|
|
|
|
|
* variable: PEERROUTES(+)
|
|
|
|
|
* default: yes
|
|
|
|
|
* description: PEERROUTES has the opposite meaning as 'ignore-auto-routes' property.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: ignore-auto-dns
|
|
|
|
|
* variable: PEERDNS
|
|
|
|
|
* default: yes
|
|
|
|
|
* description: PEERDNS has the opposite meaning as 'ignore-auto-dns' property.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: dhcp-send-hostname
|
|
|
|
|
* variable: DHCP_SEND_HOSTNAME(+)
|
|
|
|
|
* default: yes
|
|
|
|
|
* description: Whether DHCP_HOSTNAME should be sent to the DHCP server.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: dhcp-hostname
|
|
|
|
|
* variable: DHCP_HOSTNAME
|
2015-10-16 11:55:58 +02:00
|
|
|
* description: Hostname to send to the DHCP server. When both DHCP_HOSTNAME and
|
|
|
|
|
* DHCP_FQDN are specified only the latter is used.
|
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---
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: never-default
|
|
|
|
|
* variable: DEFROUTE (GATEWAYDEV in /etc/sysconfig/network)
|
|
|
|
|
* default: yes
|
|
|
|
|
* description: DEFROUTE=no tells NetworkManager that this connection
|
|
|
|
|
* should not be assigned the default route. DEFROUTE has the opposite
|
|
|
|
|
* meaning as 'never-default' property.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: may-fail
|
|
|
|
|
* variable: IPV4_FAILURE_FATAL(+)
|
|
|
|
|
* default: no
|
|
|
|
|
* description: IPV4_FAILURE_FATAL has the opposite meaning as 'may-fail' property.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2014-12-22 15:10:22 +01:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: route-metric
|
|
|
|
|
* variable: IPV4_ROUTE_METRIC(+)
|
|
|
|
|
* default: -1
|
|
|
|
|
* description: IPV4_ROUTE_METRIC is the default IPv4 metric for routes on this connection.
|
|
|
|
|
* If set to -1, a default metric based on the device type is used.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
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: IPV4_ROUTE_TABLE(+)
|
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: IPV4_ROUTE_TABLE enables policy-routing and sets the default routing table.
|
2017-09-21 19:03:08 +02:00
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2023-06-08 19:14:19 +02:00
|
|
|
/* ---nmcli---
|
|
|
|
|
* property: dns-options
|
|
|
|
|
* format: a comma separated list of DNS options
|
|
|
|
|
* description:
|
|
|
|
|
* DNS options for /etc/resolv.conf as described in resolv.conf(5) manual.
|
|
|
|
|
*
|
|
|
|
|
* The currently supported options are "attempts", "debug", "edns0",
|
|
|
|
|
* "ndots", "no-aaaa", "no-check-names", "no-reload", "no-tld-query",
|
|
|
|
|
* "rotate", "single-request", "single-request-reopen", "timeout",
|
|
|
|
|
* "trust-ad", "use-vc". See the resolv.conf(5) manual.
|
|
|
|
|
*
|
|
|
|
|
* Note that there is a distinction between an unset (default) list
|
|
|
|
|
* and an empty list. In nmcli, to unset the list set the value to
|
|
|
|
|
* "". To set an empty list, set it to " ". Currently, an unset list
|
|
|
|
|
* has the same meaning as an empty list. That might change in the future.
|
|
|
|
|
*
|
|
|
|
|
* The "trust-ad" setting is only honored if the profile contributes
|
|
|
|
|
* name servers to resolv.conf, and if all contributing profiles have
|
|
|
|
|
* "trust-ad" enabled.
|
|
|
|
|
*
|
|
|
|
|
* When using a caching DNS plugin (dnsmasq or systemd-resolved in
|
|
|
|
|
* NetworkManager.conf) then "edns0" and "trust-ad" are automatically
|
|
|
|
|
* added.
|
|
|
|
|
*
|
|
|
|
|
* The valid "ipv4.dns-options" and "ipv6.dns-options" get merged together.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2017-11-23 09:39:29 +01:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: dns-options
|
|
|
|
|
* variable: RES_OPTIONS(+)
|
|
|
|
|
* description: List of DNS options to be added to /etc/resolv.conf
|
|
|
|
|
* example: RES_OPTIONS=ndots:2 timeout:3
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2016-04-23 15:57:07 +02:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: dns-priority
|
|
|
|
|
* variable: IPV4_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: IPV4_DNS_PRIORITY=20
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2023-01-03 13:33:49 +01:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: auto-route-ext-gw
|
|
|
|
|
* variable: IPV4_AUTO_ROUTE_EXT_GW(+)
|
|
|
|
|
* default: yes
|
|
|
|
|
* description: VPN connections will default to add the route automatically unless this
|
|
|
|
|
* setting is set to %FALSE.
|
|
|
|
|
* For other connection types, adding such an automatic route is currently
|
|
|
|
|
* not supported and setting this to %TRUE has no effect.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2023-02-20 12:05:04 +01:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: replace-local-rule
|
|
|
|
|
* variable: IPV4_REPLACE_LOCAL_RULE(+)
|
|
|
|
|
* default: no
|
|
|
|
|
* description: Connections will default to keep the autogenerated priority
|
|
|
|
|
* 0 local rule unless this setting is set to %TRUE.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
2014-10-19 17:30:10 -04:00
|
|
|
* NMSettingIP4Config:dhcp-client-id:
|
2014-07-24 08:53:33 -04:00
|
|
|
*
|
2014-10-19 17:30:10 -04:00
|
|
|
* A string sent to the DHCP server to identify the local machine which the
|
|
|
|
|
* DHCP server may use to customize the DHCP lease and options.
|
2017-07-19 15:03:09 +02:00
|
|
|
* When the property is a hex string ('aa:bb:cc') it is interpreted as a
|
|
|
|
|
* binary client ID, in which case the first byte is assumed to be the
|
|
|
|
|
* 'type' field as per RFC 2132 section 9.14 and the remaining bytes may be
|
|
|
|
|
* an hardware address (e.g. '01:xx:xx:xx:xx:xx:xx' where 1 is the Ethernet
|
|
|
|
|
* ARP type and the rest is a MAC address).
|
|
|
|
|
* If the property is not a hex string it is considered as a
|
|
|
|
|
* non-hardware-address client ID and the 'type' field is set to 0.
|
2018-02-14 15:45:29 +01:00
|
|
|
*
|
2018-02-14 17:01:56 +01:00
|
|
|
* The special values "mac" and "perm-mac" are supported, which use the
|
|
|
|
|
* current or permanent MAC address of the device to generate a client identifier
|
2018-08-19 13:06:56 +02:00
|
|
|
* with type ethernet (01). Currently, these options only work for ethernet
|
2018-02-14 17:01:56 +01:00
|
|
|
* type of links.
|
|
|
|
|
*
|
2021-01-04 17:32:47 +01:00
|
|
|
* The special value "ipv6-duid" uses the DUID from "ipv6.dhcp-duid" property as
|
|
|
|
|
* an RFC4361-compliant client identifier. As IAID it uses "ipv4.dhcp-iaid"
|
|
|
|
|
* and falls back to "ipv6.dhcp-iaid" if unset.
|
|
|
|
|
*
|
2018-11-02 17:05:03 +01:00
|
|
|
* The special value "duid" generates a RFC4361-compliant client identifier based
|
2021-01-04 17:32:47 +01:00
|
|
|
* on "ipv4.dhcp-iaid" and uses a DUID generated by hashing /etc/machine-id.
|
2018-11-02 17:05:03 +01:00
|
|
|
*
|
2018-02-14 17:01:56 +01:00
|
|
|
* The special value "stable" is supported to generate a type 0 client identifier based
|
2018-11-02 11:44:05 +01:00
|
|
|
* on the stable-id (see connection.stable-id) and a per-host key. If you set the
|
2018-12-10 15:39:53 +01:00
|
|
|
* stable-id, you may want to include the "${DEVICE}" or "${MAC}" specifier to get a
|
2018-11-02 11:44:05 +01:00
|
|
|
* per-device key.
|
2018-02-14 17:01:56 +01:00
|
|
|
*
|
2023-09-27 16:15:48 +02:00
|
|
|
* The special value "none" prevents any client identifier from being sent. Note that
|
|
|
|
|
* this is normally not recommended.
|
|
|
|
|
*
|
|
|
|
|
* If unset, a globally configured default from NetworkManager.conf is used. If still
|
|
|
|
|
* unset, the default depends on the DHCP plugin. The internal dhcp client will
|
|
|
|
|
* generate a default value and the dhclient plugin will try to use one from its
|
|
|
|
|
* config file if present, or won't sent any client-id otherwise.
|
2014-07-24 08:53:33 -04:00
|
|
|
**/
|
2023-09-26 12:40:52 +02:00
|
|
|
/* ---nmcli---
|
|
|
|
|
* property: dhcp-client-id
|
|
|
|
|
* special-values: mac, perm-mac, duid, ipv6-duid, stable, none
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
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: dhcp-client-id
|
|
|
|
|
* variable: DHCP_CLIENT_ID(+)
|
|
|
|
|
* description: A string sent to the DHCP server to identify the local machine.
|
2017-07-19 15:03:09 +02:00
|
|
|
* A binary value can be specified using hex notation ('aa:bb:cc').
|
2018-04-06 18:32:55 +02:00
|
|
|
* example: DHCP_CLIENT_ID=ax-srv-1; DHCP_CLIENT_ID=01:44:44:44:44:44:44
|
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---
|
|
|
|
|
*/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_DHCP_CLIENT_ID,
|
|
|
|
|
PROP_DHCP_CLIENT_ID,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingIP4ConfigPrivate,
|
|
|
|
|
dhcp_client_id);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-09-08 10:55:11 +02:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: dad-timeout
|
2018-05-28 18:13:42 +02:00
|
|
|
* variable: ACD_TIMEOUT(+), ARPING_WAIT
|
2018-04-01 15:41:45 +02:00
|
|
|
* default: missing variable means global default (config override or zero)
|
2018-03-31 15:30:51 +02:00
|
|
|
* description: Timeout (in milliseconds for ACD_TIMEOUT or in seconds
|
|
|
|
|
* for ARPING_WAIT) for address conflict detection before configuring
|
|
|
|
|
* IPv4 addresses. 0 turns off the ACD completely, -1 means default value.
|
|
|
|
|
* example: ACD_TIMEOUT=2000 or ARPING_WAIT=2
|
2015-09-08 10:55:11 +02:00
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2015-09-28 19:19:13 +02:00
|
|
|
/* ---ifcfg-rh---
|
2015-10-13 15:34:48 +02:00
|
|
|
* property: dhcp-timeout
|
2016-02-16 11:32:46 +01:00
|
|
|
* variable: IPV4_DHCP_TIMEOUT(+)
|
2015-09-28 19:19:13 +02:00
|
|
|
* description: A timeout after which the DHCP transaction fails in case of no response.
|
2016-02-16 11:32:46 +01:00
|
|
|
* example: IPV4_DHCP_TIMEOUT=10
|
2015-09-28 19:19:13 +02:00
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2019-07-09 14:23:58 +02:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: dhcp-hostname-flags
|
|
|
|
|
* variable: DHCP_HOSTNAME_FLAGS
|
|
|
|
|
* description: flags for the DHCP hostname and FQDN properties
|
|
|
|
|
* example: DHCP_HOSTNAME_FLAGS=5
|
2022-08-29 15:52:23 +02:00
|
|
|
* ---end---
|
2019-07-09 14:23:58 +02:00
|
|
|
*/
|
|
|
|
|
|
2015-10-13 14:10:01 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingIP4Config:dhcp-fqdn:
|
|
|
|
|
*
|
|
|
|
|
* If the #NMSettingIPConfig:dhcp-send-hostname property is %TRUE, then the
|
|
|
|
|
* specified FQDN will be sent to the DHCP server when acquiring a lease. This
|
|
|
|
|
* property and #NMSettingIPConfig:dhcp-hostname are mutually exclusive and
|
|
|
|
|
* cannot be set at the same time.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.2
|
|
|
|
|
*/
|
2015-10-16 11:55:58 +02:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: dhcp-fqdn
|
|
|
|
|
* variable: DHCP_FQDN
|
|
|
|
|
* description: FQDN to send to the DHCP server. When both DHCP_HOSTNAME and
|
|
|
|
|
* DHCP_FQDN are specified only the latter is used.
|
|
|
|
|
* example: DHCP_FQDN=foo.bar.com
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_DHCP_FQDN,
|
|
|
|
|
PROP_DHCP_FQDN,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingIP4ConfigPrivate,
|
|
|
|
|
dhcp_fqdn);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-08-24 18:01:42 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingIP4Config:dhcp-vendor-class-identifier:
|
|
|
|
|
*
|
|
|
|
|
* The Vendor Class Identifier DHCP option (60).
|
|
|
|
|
* Special characters in the data string may be escaped using C-style escapes,
|
|
|
|
|
* nevertheless this property cannot contain nul bytes.
|
|
|
|
|
* If the per-profile value is unspecified (the default),
|
|
|
|
|
* a global connection default gets consulted.
|
|
|
|
|
* If still unspecified, the DHCP option is not sent to the server.
|
|
|
|
|
*
|
2022-11-07 21:13:28 +01:00
|
|
|
* Since: 1.28
|
2020-08-24 18:01:42 +02:00
|
|
|
*/
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: dhcp-vendor-class-identifier
|
|
|
|
|
* variable: DHCP_VENDOR_CLASS_IDENTIFIER(+)
|
|
|
|
|
* description: The Vendor Class Identifier DHCP option (60).
|
|
|
|
|
* example: DHCP_VENDOR_CLASS_IDENTIFIER=foo
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_DHCP_VENDOR_CLASS_IDENTIFIER,
|
|
|
|
|
PROP_DHCP_VENDOR_CLASS_IDENTIFIER,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingIP4ConfigPrivate,
|
|
|
|
|
dhcp_vendor_class_identifier);
|
2020-08-24 18:01:42 +02:00
|
|
|
|
settings: add ipv4.link-local flag
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
2022-04-08 13:11:56 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingIP4Config:link-local:
|
|
|
|
|
*
|
|
|
|
|
* Enable and disable the IPv4 link-local configuration independently of the
|
|
|
|
|
* ipv4.method configuration. This allows a link-local address (169.254.x.y/16)
|
|
|
|
|
* to be obtained in addition to other addresses, such as those manually
|
|
|
|
|
* configured or obtained from a DHCP server.
|
|
|
|
|
*
|
|
|
|
|
* When set to "auto", the value is dependent on "ipv4.method".
|
|
|
|
|
* When set to "default", it honors the global connection default, before
|
|
|
|
|
* falling back to "auto". Note that if "ipv4.method" is "disabled", then
|
|
|
|
|
* link local addressing is always disabled too. The default is "default".
|
|
|
|
|
*
|
2022-11-07 21:13:28 +01:00
|
|
|
* Since: 1.40
|
settings: add ipv4.link-local flag
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
2022-04-08 13:11:56 +02:00
|
|
|
*/
|
2022-05-12 19:43:54 +02:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: link-local
|
|
|
|
|
* variable: IPV4_LINK_LOCAL(+)
|
|
|
|
|
* description: Configure link-local IP address in interaction with method
|
|
|
|
|
* example: IPV4_LINK_LOCAL=auto
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
settings: add ipv4.link-local flag
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
2022-04-08 13:11:56 +02:00
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_IP4_CONFIG_LINK_LOCAL,
|
|
|
|
|
PROP_LINK_LOCAL,
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
NM_SETTING_IP4_LL_DEFAULT,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingIP4ConfigPrivate,
|
|
|
|
|
link_local);
|
|
|
|
|
|
2014-10-19 17:30:10 -04:00
|
|
|
/* IP4-specific property overrides */
|
2014-11-16 15:36:18 -05:00
|
|
|
|
|
|
|
|
/* ---dbus---
|
|
|
|
|
* property: dns
|
|
|
|
|
* format: array of uint32
|
|
|
|
|
* description: Array of IP addresses of DNS servers (as network-byte-order
|
|
|
|
|
* integers)
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
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),
|
2021-06-29 21:53:55 +02:00
|
|
|
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("au"),
|
2022-10-27 21:10:45 +02:00
|
|
|
.compare_fcn = _nm_setting_ip_config_compare_fcn_dns,
|
libnm: add "dns-data" replacement for "ipv[46].dns" properties on D-Bus
On D-Bus, the properties "ipv[46].dns" are of type "au" and "aay",
respectively.
Btw, in particular "au" is bad, because we put there a big-endian
number. There is no D-Bus type to represent big endian numbers, so "u"
is bad because it can cause endianess problem when trying to remote
the D-Bus communication to another host (without explicitly
understanding which "u" properties need to swap for endinness).
Anyway. The plain addresses are not enough. We soon will also support
the DNS-over-TLS server name, or maybe a DoT port number. The previous
property was not extensible, so deprecate it and replace it by
"dns-data".
This one is just a list of strings. That is unlike "address-data" or
"route-data", which do a similar thing but are "a{sv}" dictionaries.
Here a string is supposed to be sufficient also for the future. Also,
because in nmcli and keyfile will will simply have a string format for
representing the extra data, not a structure (unlike for routes or
addresses).
2022-10-21 14:50:32 +02:00
|
|
|
.to_dbus_fcn = ip4_dns_to_dbus,
|
|
|
|
|
.from_dbus_fcn = ip4_dns_from_dbus, ),
|
|
|
|
|
.to_dbus_only_in_manager_process = TRUE,
|
|
|
|
|
.dbus_deprecated = TRUE, );
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-11-16 15:36:18 -05:00
|
|
|
/* ---dbus---
|
|
|
|
|
* property: addresses
|
|
|
|
|
* format: array of array of uint32
|
|
|
|
|
* 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 IPv4 address structures. Each IPv4 address structure is
|
|
|
|
|
* composed of 3 32-bit values; the first being the IPv4 address (network
|
|
|
|
|
* byte order), the second the prefix (1 - 32), and last the IPv4 gateway
|
|
|
|
|
* (network byte order). The gateway may be left as 0 if no gateway exists
|
|
|
|
|
* for that subnet.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-01-30 10:27:57 -05:00
|
|
|
/* ---nmcli---
|
|
|
|
|
* property: addresses
|
|
|
|
|
* format: a comma separated list of addresses
|
|
|
|
|
* description: A list of IPv4 addresses and their prefix length. Multiple addresses
|
|
|
|
|
* can be separated by comma. For example "192.168.1.5/24, 10.1.0.5/24".
|
2021-08-19 13:53:29 +02:00
|
|
|
* The addresses are listed in decreasing priority, meaning the first address will
|
2021-08-17 12:12:40 +02:00
|
|
|
* be the primary address.
|
2021-01-30 10:27:57 -05:00
|
|
|
* ---end---
|
|
|
|
|
*/
|
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),
|
2021-06-18 09:44:46 +02:00
|
|
|
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("aau"),
|
2022-10-21 14:50:27 +02:00
|
|
|
.to_dbus_fcn = ip4_addresses_to_dbus,
|
2021-06-29 14:37:16 +02:00
|
|
|
.compare_fcn = _nm_setting_ip_config_compare_fcn_addresses,
|
2022-10-24 11:01:15 +02:00
|
|
|
.from_dbus_fcn = ip4_addresses_from_dbus, ),
|
libnm: refactor to-dbus on the client skipping to serialize legacy properties
We have 4 legacy properties ("ipv[46].addresses", "ipv[46].routes") that
got replaced by newer variants ("ipv[46].address-data", "ipv[46].route-data").
When the client side of libnm (_nm_utils_is_manager_process) serializes
those properties, it must only serialize the newer version. That is so
that the forward/backward compatibility works as intended.
Previously, there was the NM_SETTING_PARAM_LEGACY GObject property flag.
That was fine, but not very clear.
For one, the legacy part of those properties is only about D-Bus. In
particular, they are not deprecated in libnm, keyfile, or nmcli. Thus
the name wasn't very clear.
Also, in the meantime we have more elaborate property meta data, that
goes beyond the meta data of the GObject property.
Move NM_SETTING_PARAM_LEGACY to NMSettInfoProperty.to_dbus_only_in_manager_process.
I think, this is a better name. It's also right at
```
_nm_properties_override_gobj(
properties_override,
g_object_class_find_property(G_OBJECT_CLASS(setting_class), NM_SETTING_IP_CONFIG_ROUTES),
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("a(ayuayu)"),
.to_dbus_fcn = ip6_routes_to_dbus,
.compare_fcn = _nm_setting_ip_config_compare_fcn_routes,
.from_dbus_fcn = ip6_routes_from_dbus, ),
.to_dbus_only_in_manager_process = TRUE,
.dbus_deprecated = TRUE, );
```
that is, directly at the place where we describe how the D-Bus property behaves.
2022-10-24 13:22:40 +02:00
|
|
|
.to_dbus_only_in_manager_process = TRUE,
|
|
|
|
|
.dbus_deprecated = TRUE, );
|
2019-09-22 15:32:04 +02:00
|
|
|
_nm_properties_override_dbus(
|
|
|
|
|
properties_override,
|
|
|
|
|
"address-labels",
|
2021-06-18 09:44:46 +02:00
|
|
|
NM_SETT_INFO_PROPERT_TYPE_DBUS(G_VARIANT_TYPE_STRING_ARRAY,
|
2022-10-21 14:50:27 +02:00
|
|
|
.to_dbus_fcn = ip4_address_labels_to_dbus,
|
|
|
|
|
.compare_fcn = _nm_setting_property_compare_fcn_ignore,
|
2022-10-24 11:01:15 +02:00
|
|
|
/* from_dbus() is handled by ip4_addresses_from_dbus(). */),
|
|
|
|
|
.dbus_deprecated = TRUE, );
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-11-16 15:36:18 -05:00
|
|
|
/* ---dbus---
|
|
|
|
|
* property: address-data
|
|
|
|
|
* format: array of vardict
|
|
|
|
|
* description: Array of IPv4 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---
|
|
|
|
|
*/
|
2019-09-22 15:32:04 +02:00
|
|
|
_nm_properties_override_dbus(
|
|
|
|
|
properties_override,
|
|
|
|
|
"address-data",
|
2021-06-18 09:44:46 +02:00
|
|
|
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("aa{sv}"),
|
2022-10-21 14:50:27 +02:00
|
|
|
.to_dbus_fcn = ip4_address_data_to_dbus,
|
2021-06-29 17:03:37 +02:00
|
|
|
.compare_fcn = _nm_setting_property_compare_fcn_ignore,
|
2022-10-21 14:50:27 +02:00
|
|
|
.from_dbus_fcn = ip4_address_data_from_dbus, ));
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-11-16 15:36:18 -05:00
|
|
|
/* ---dbus---
|
|
|
|
|
* property: routes
|
|
|
|
|
* format: array of array of uint32
|
|
|
|
|
* 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 IPv4 route structures. Each IPv4 route structure is composed
|
|
|
|
|
* of 4 32-bit values; the first being the destination IPv4 network or
|
|
|
|
|
* address (network byte order), the second the destination network or
|
|
|
|
|
* address prefix (1 - 32), the third being the next-hop (network byte
|
|
|
|
|
* order) if any, and the fourth being the route metric. If the metric is
|
|
|
|
|
* 0, NM will choose an appropriate default metric for the device. (There
|
|
|
|
|
* is no way to explicitly specify an actual metric of 0 with this
|
|
|
|
|
* property.)
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-02-17 20:31:47 -05:00
|
|
|
/* ---nmcli---
|
|
|
|
|
* property: routes
|
|
|
|
|
* format: a comma separated list of routes
|
|
|
|
|
* description: A list of IPv4 destination addresses, prefix length, optional IPv4
|
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
|
|
|
* 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".
|
|
|
|
|
* description-docbook:
|
|
|
|
|
* <para>
|
|
|
|
|
* 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".
|
|
|
|
|
* </para>
|
|
|
|
|
* <para>
|
|
|
|
|
* Various attributes are supported:
|
|
|
|
|
* <itemizedlist>
|
|
|
|
|
* <listitem>
|
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>"initcwnd"</literal> - an unsigned 32 bit integer.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* <listitem>
|
|
|
|
|
* <para><literal>"initrwnd"</literal> - an unsigned 32 bit integer.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* <listitem>
|
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>
|
2023-02-01 22:40:38 +01:00
|
|
|
* <para><literal>"onlink"</literal> - a boolean value. The onlink flag
|
|
|
|
|
* is ignored for IPv4 routes without a gateway. That also means,
|
|
|
|
|
* with a positive "weight" the route cannot merge with ECMP routes
|
|
|
|
|
* which are onlink and have a gateway.
|
|
|
|
|
* </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>
|
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>"scope"</literal> - an unsigned 8 bit integer. IPv4 only.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* <listitem>
|
|
|
|
|
* <para><literal>"src"</literal> - an IPv4 address.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* <listitem>
|
|
|
|
|
* <para><literal>"table"</literal> - an unsigned 32 bit integer. The default depends on ipv4.route-table.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* <listitem>
|
|
|
|
|
* <para><literal>"tos"</literal> - an unsigned 8 bit integer. IPv4 only.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* <listitem>
|
|
|
|
|
* <para><literal>"type"</literal> - one of <literal>unicast</literal>, <literal>local</literal>, <literal>blackhole</literal>,
|
2023-02-28 00:43:35 -05:00
|
|
|
* <literal>unreachable</literal>, <literal>prohibit</literal>, <literal>throw</literal>.
|
2022-02-25 21:01:04 +01:00
|
|
|
* 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>
|
2023-02-01 08:58:15 +01:00
|
|
|
* <para><literal>"weight"</literal> - an unsigned 32 bit integer
|
|
|
|
|
* ranging from 0 to 256. A non-zero weight indicates that the IPv4
|
|
|
|
|
* route is an ECMP IPv4 route. NetworkManager will automatically
|
|
|
|
|
* merge compatible ECMP routes into multi-hop routes. Setting to
|
|
|
|
|
* zero or omitting the attribute configures single hop routes that
|
|
|
|
|
* won't get merged. If the route finds no merge partner, it is
|
|
|
|
|
* configured as single hop route.</para> <para>Note that in
|
|
|
|
|
* NetworkManager, currently all nexthops of a ECMP route must share
|
|
|
|
|
* the same "onlink" flag in order to be mergable.</para>
|
2023-01-19 15:34:42 +01:00
|
|
|
* </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>"window"</literal> - an unsigned 32 bit integer.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* </itemizedlist>
|
|
|
|
|
* </para>
|
|
|
|
|
* <para>
|
|
|
|
|
* For details see also `man ip-route`.
|
|
|
|
|
* </para>
|
2021-02-17 20:31:47 -05:00
|
|
|
* ---end---
|
|
|
|
|
*/
|
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),
|
2021-06-18 09:44:46 +02:00
|
|
|
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("aau"),
|
2022-10-21 14:50:27 +02:00
|
|
|
.to_dbus_fcn = ip4_routes_to_dbus,
|
2021-06-29 14:37:16 +02:00
|
|
|
.compare_fcn = _nm_setting_ip_config_compare_fcn_routes,
|
2022-10-24 11:01:15 +02:00
|
|
|
.from_dbus_fcn = ip4_routes_from_dbus, ),
|
libnm: refactor to-dbus on the client skipping to serialize legacy properties
We have 4 legacy properties ("ipv[46].addresses", "ipv[46].routes") that
got replaced by newer variants ("ipv[46].address-data", "ipv[46].route-data").
When the client side of libnm (_nm_utils_is_manager_process) serializes
those properties, it must only serialize the newer version. That is so
that the forward/backward compatibility works as intended.
Previously, there was the NM_SETTING_PARAM_LEGACY GObject property flag.
That was fine, but not very clear.
For one, the legacy part of those properties is only about D-Bus. In
particular, they are not deprecated in libnm, keyfile, or nmcli. Thus
the name wasn't very clear.
Also, in the meantime we have more elaborate property meta data, that
goes beyond the meta data of the GObject property.
Move NM_SETTING_PARAM_LEGACY to NMSettInfoProperty.to_dbus_only_in_manager_process.
I think, this is a better name. It's also right at
```
_nm_properties_override_gobj(
properties_override,
g_object_class_find_property(G_OBJECT_CLASS(setting_class), NM_SETTING_IP_CONFIG_ROUTES),
NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("a(ayuayu)"),
.to_dbus_fcn = ip6_routes_to_dbus,
.compare_fcn = _nm_setting_ip_config_compare_fcn_routes,
.from_dbus_fcn = ip6_routes_from_dbus, ),
.to_dbus_only_in_manager_process = TRUE,
.dbus_deprecated = TRUE, );
```
that is, directly at the place where we describe how the D-Bus property behaves.
2022-10-24 13:22:40 +02:00
|
|
|
.to_dbus_only_in_manager_process = TRUE,
|
|
|
|
|
.dbus_deprecated = TRUE, );
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-11-16 15:36:18 -05:00
|
|
|
/* ---dbus---
|
|
|
|
|
* property: route-data
|
|
|
|
|
* format: array of vardict
|
|
|
|
|
* description: Array of IPv4 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
|
2020-08-10 17:58:55 +02:00
|
|
|
* will also have a 'next-hop' entry, containing the next hop IP address as
|
2014-11-16 15:36:18 -05:00
|
|
|
* 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---
|
|
|
|
|
*/
|
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}"),
|
2022-10-21 14:50:27 +02:00
|
|
|
.to_dbus_fcn = ip4_route_data_to_dbus,
|
2021-06-29 17:03:37 +02:00
|
|
|
.compare_fcn = _nm_setting_property_compare_fcn_ignore,
|
2022-10-21 14:50:27 +02:00
|
|
|
.from_dbus_fcn = ip4_route_data_from_dbus, ));
|
2020-09-28 16:03:33 +02:00
|
|
|
|
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 192.167.4.0/24 table 45</literal>
|
|
|
|
|
* </para>
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2023-04-20 16:57:24 +02:00
|
|
|
/* ---nmcli---
|
|
|
|
|
* property: method
|
|
|
|
|
* format: string
|
|
|
|
|
* description: The IPv4 connection method.
|
|
|
|
|
* description-docbook:
|
|
|
|
|
* <para>
|
|
|
|
|
* Sets the IPv4 connection method. You can set one of the following values:
|
|
|
|
|
* </para>
|
|
|
|
|
* <para>
|
|
|
|
|
* <itemizedlist>
|
|
|
|
|
* <listitem>
|
|
|
|
|
* <para><literal>"auto"</literal> - Enables automatic IPv4 address assignment from DHCP, PPP, or similar services.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* <listitem>
|
|
|
|
|
* <para><literal>"manual"</literal> - Enables the configuration of static IPv4 addresses on the interface. Note that you must set at least one IP address and subnet mask in the "ipv4.addresses" property.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* <listitem>
|
|
|
|
|
* <para><literal>"disabled"</literal> - Disables the IPv4 protocol in this connection profile.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* <listitem>
|
|
|
|
|
* <para><literal>"shared"</literal> - Provides network access to other computers. If you do not specify an IP address and subnet mask in "ipv4.addresses", NetworkManager assigns 10.42.x.1/24 to the interface. Additionally, NetworkManager starts a DHCP server and DNS forwarder. Hosts that connect to this interface will then receive an IP address from the configured range, and NetworkManager configures NAT to map client addresses to the one of the current default network connection.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* <listitem>
|
|
|
|
|
* <para><literal>"link-local"</literal> - Enables link-local addresses according to RFC 3927. NetworkManager assigns a random link-local address from the 169.254.0.0/16 subnet to the interface.</para>
|
|
|
|
|
* </listitem>
|
|
|
|
|
* </itemizedlist>
|
|
|
|
|
* </para>
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
|
2019-01-11 08:28:26 +01:00
|
|
|
g_object_class_install_properties(object_class, _PROPERTY_ENUMS_LAST, obj_properties);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-06-28 14:53:16 +02:00
|
|
|
_nm_setting_class_commit(setting_class,
|
|
|
|
|
NM_META_SETTING_TYPE_IP4_CONFIG,
|
|
|
|
|
NULL,
|
|
|
|
|
properties_override,
|
libnm: embed private structure in NMSetting and avoid g_type_class_add_private()
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
|
|
|
G_STRUCT_OFFSET(NMSettingIP4Config, _priv));
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
