2019-09-10 09:19:01 +00:00
|
|
|
// SPDX-License-Identifier: LGPL-2.1+
|
2014-07-27 18:35:17 +00:00
|
|
|
/*
|
2019-10-01 07:20:35 +00:00
|
|
|
* Copyright (C) 2014 - 2018 Red Hat, Inc.
|
2014-07-27 18:35:17 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef NM_CORE_NM_INTERNAL_H
|
|
|
|
#define NM_CORE_NM_INTERNAL_H
|
|
|
|
|
|
|
|
/* This header file contain functions that are provided as private API
|
|
|
|
* by libnm-core. It will contain functions to give privileged access to
|
|
|
|
* libnm-core. This can be useful for NetworkManager and libnm.so
|
|
|
|
* which both are special users of libnm-core.
|
|
|
|
* It also exposes some utility functions for reuse.
|
|
|
|
*
|
|
|
|
* These functions are not exported and are only available to components that link
|
|
|
|
* statically against libnm-core. This basically means libnm-core, libnm, NetworkManager
|
|
|
|
* and some test programs.
|
|
|
|
**/
|
2018-01-02 12:37:06 +00:00
|
|
|
#if !((NETWORKMANAGER_COMPILATION) & NM_NETWORKMANAGER_COMPILATION_WITH_LIBNM_CORE_INTERNAL)
|
|
|
|
#error Cannot use this header.
|
|
|
|
#endif
|
2014-07-27 18:35:17 +00:00
|
|
|
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-connection.h"
|
|
|
|
#include "nm-core-enum-types.h"
|
2019-01-28 11:39:38 +00:00
|
|
|
#include "nm-core-types-internal.h"
|
|
|
|
#include "nm-meta-setting.h"
|
2018-05-22 13:41:29 +00:00
|
|
|
#include "nm-setting-6lowpan.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting-8021x.h"
|
|
|
|
#include "nm-setting-adsl.h"
|
|
|
|
#include "nm-setting-bluetooth.h"
|
|
|
|
#include "nm-setting-bond.h"
|
|
|
|
#include "nm-setting-bridge-port.h"
|
|
|
|
#include "nm-setting-bridge.h"
|
|
|
|
#include "nm-setting-cdma.h"
|
|
|
|
#include "nm-setting-connection.h"
|
|
|
|
#include "nm-setting-dcb.h"
|
2017-01-31 13:13:35 +00:00
|
|
|
#include "nm-setting-dummy.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting-generic.h"
|
|
|
|
#include "nm-setting-gsm.h"
|
|
|
|
#include "nm-setting-infiniband.h"
|
2015-09-01 12:06:00 +00:00
|
|
|
#include "nm-setting-ip-tunnel.h"
|
2014-07-27 18:35:17 +00:00
|
|
|
#include "nm-setting-ip4-config.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting-ip6-config.h"
|
2016-06-30 16:20:43 +00:00
|
|
|
#include "nm-setting-macsec.h"
|
2015-09-17 16:13:49 +00:00
|
|
|
#include "nm-setting-macvlan.h"
|
2018-08-07 13:52:56 +00:00
|
|
|
#include "nm-setting-match.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting-olpc-mesh.h"
|
2017-08-01 16:36:34 +00:00
|
|
|
#include "nm-setting-ovs-bridge.h"
|
2017-08-01 16:36:34 +00:00
|
|
|
#include "nm-setting-ovs-interface.h"
|
2019-06-11 13:53:05 +00:00
|
|
|
#include "nm-setting-ovs-dpdk.h"
|
2017-08-01 16:36:34 +00:00
|
|
|
#include "nm-setting-ovs-patch.h"
|
2017-10-02 07:03:19 +00:00
|
|
|
#include "nm-setting-ovs-port.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting-ppp.h"
|
|
|
|
#include "nm-setting-pppoe.h"
|
2019-01-28 11:39:38 +00:00
|
|
|
#include "nm-setting-proxy.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting-serial.h"
|
2018-05-25 10:05:24 +00:00
|
|
|
#include "nm-setting-sriov.h"
|
2017-11-16 16:35:20 +00:00
|
|
|
#include "nm-setting-tc-config.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting-team-port.h"
|
|
|
|
#include "nm-setting-team.h"
|
2015-09-14 20:56:51 +00:00
|
|
|
#include "nm-setting-tun.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting-vlan.h"
|
|
|
|
#include "nm-setting-vpn.h"
|
2019-12-05 09:13:34 +00:00
|
|
|
#include "nm-setting-vrf.h"
|
2015-10-13 07:09:54 +00:00
|
|
|
#include "nm-setting-vxlan.h"
|
2019-01-28 11:39:38 +00:00
|
|
|
#include "nm-setting-wifi-p2p.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting-wimax.h"
|
|
|
|
#include "nm-setting-wired.h"
|
2018-12-27 15:48:30 +00:00
|
|
|
#include "nm-setting-wireguard.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting-wireless-security.h"
|
|
|
|
#include "nm-setting-wireless.h"
|
2018-03-09 09:51:49 +00:00
|
|
|
#include "nm-setting-wpan.h"
|
2014-10-21 22:43:33 +00:00
|
|
|
#include "nm-setting.h"
|
|
|
|
#include "nm-simple-connection.h"
|
|
|
|
#include "nm-utils.h"
|
|
|
|
#include "nm-vpn-dbus-interface.h"
|
libnm/vpn: allow specifying non-absolute plugin name in VPN .name file
Since commit 3dfbbb227e82b47973f612b6b031d8d591727436, we enforce that
the plugin path in the .name file is absolute and we perform several
checks on the file before loading it (ownership, etc).
Relax that, to also allow libray names without path component.
In that case, g_module_open()/dlopen() will search for a library
in various search paths. This allows, to omit absolute paths
in the .name file. The latter is problematic, because by default
we install the .name file in the architecture independent location
/usr/lib/NetworkManager. As such, it should not contain paths
to architecture dependent libraries. With this change, a .name
file can contain only the library name and it will be loaded
using the usual mechanism.
However, specifying absolute paths is still possible and works
same as before, including checking file permissions.
As such, distributions probably should package the VPN plugins
to have no path in the .name file. On the other hand, a user
compiling from source probably wants to specify an absolute
path. The reason is, that the user probably doesn't build the
plugin for multiple achitectures and that way, he can install
the plugin in a separate (private) prefix.
2016-04-18 16:19:04 +00:00
|
|
|
#include "nm-vpn-editor-plugin.h"
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"libnm-core" implements common functionality for "NetworkManager" and
"libnm".
Note that clients like "nmcli" cannot access the internal API provided
by "libnm-core". So, if nmcli wants to do something that is also done by
"libnm-core", , "libnm", or "NetworkManager", the code would have to be
duplicated.
Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
Note that:
0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
On the other hand, "libnm-libnm-core-aux.la" is not used by
libnm-core, but provides utilities on top of it.
1) they both extend "libnm-core" with utlities that are not public
API of libnm itself. Maybe part of the code should one day become
public API of libnm. On the other hand, this is code for which
we may not want to commit to a stable interface or which we
don't want to provide as part of the API.
2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
and thus directly available to "libnm" and "NetworkManager".
On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
and "NetworkManager".
Both libraries may be statically linked by libnm clients (like
nmcli).
3) it must only use glib, libnm-glib-aux.la, and the public API
of libnm-core.
This is important: it must not use "libnm-core/nm-core-internal.h"
nor "libnm-core/nm-utils-private.h" so the static library is usable
by nmcli which couldn't access these.
Note that "shared/nm-meta-setting.c" is an entirely different case,
because it behaves differently depending on whether linking against
"libnm-core" or the client programs. As such, this file must be compiled
twice.
(cherry picked from commit af07ed01c04867e281cc3982a7ab0d244d4f8e2e)
2019-04-15 07:26:53 +00:00
|
|
|
#include "nm-libnm-core-intern/nm-libnm-core-utils.h"
|
2014-07-27 18:35:17 +00:00
|
|
|
|
2017-11-23 14:52:07 +00:00
|
|
|
/* IEEE 802.1D-1998 timer values */
|
|
|
|
#define NM_BR_MIN_HELLO_TIME 1
|
|
|
|
#define NM_BR_MAX_HELLO_TIME 10
|
|
|
|
|
|
|
|
#define NM_BR_MIN_FORWARD_DELAY 2
|
|
|
|
#define NM_BR_MAX_FORWARD_DELAY 30
|
|
|
|
|
|
|
|
#define NM_BR_MIN_MAX_AGE 6
|
|
|
|
#define NM_BR_MAX_MAX_AGE 40
|
|
|
|
|
|
|
|
/* IEEE 802.1D-1998 Table 7.4 */
|
|
|
|
#define NM_BR_MIN_AGEING_TIME 0
|
|
|
|
#define NM_BR_MAX_AGEING_TIME 1000000
|
|
|
|
|
2019-01-03 13:19:21 +00:00
|
|
|
#define NM_BR_PORT_MAX_PRIORITY 63
|
|
|
|
#define NM_BR_PORT_DEF_PRIORITY 32
|
|
|
|
|
|
|
|
#define NM_BR_PORT_MAX_PATH_COST 65535
|
2019-12-12 10:52:11 +00:00
|
|
|
#define NM_BR_PORT_DEF_PATH_COST 100
|
2019-01-03 13:19:21 +00:00
|
|
|
|
2014-08-11 16:10:43 +00:00
|
|
|
/* NM_SETTING_COMPARE_FLAG_INFERRABLE: check whether a device-generated
|
|
|
|
* connection can be replaced by a already-defined connection. This flag only
|
|
|
|
* takes into account properties marked with the %NM_SETTING_PARAM_INFERRABLE
|
|
|
|
* flag.
|
|
|
|
*/
|
2015-09-18 15:21:34 +00:00
|
|
|
#define NM_SETTING_COMPARE_FLAG_INFERRABLE ((NMSettingCompareFlags) 0x80000000)
|
2014-08-11 16:10:43 +00:00
|
|
|
|
2015-09-18 15:21:34 +00:00
|
|
|
/* NM_SETTING_COMPARE_FLAG_IGNORE_REAPPLY_IMMEDIATELY: this flag is used for properties
|
|
|
|
* that automatically get re-applied on an active connection when the settings
|
|
|
|
* connection is modified. For most properties, the applied-connection is distinct
|
|
|
|
* from the setting-connection and changes don't propagate. Exceptions are the
|
|
|
|
* firewall-zone and the metered property.
|
|
|
|
*/
|
|
|
|
#define NM_SETTING_COMPARE_FLAG_IGNORE_REAPPLY_IMMEDIATELY ((NMSettingCompareFlags) 0x40000000)
|
|
|
|
|
|
|
|
/* NM_SETTING_COMPARE_FLAG_NONE: for convenience, define a special flag NONE -- which
|
|
|
|
* equals to numeric zero (NM_SETTING_COMPARE_FLAG_EXACT).
|
|
|
|
*/
|
|
|
|
#define NM_SETTING_COMPARE_FLAG_NONE ((NMSettingCompareFlags) 0)
|
2014-07-27 18:35:17 +00:00
|
|
|
|
2018-12-29 20:23:09 +00:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
2019-02-09 10:18:17 +00:00
|
|
|
#define NM_SETTING_SECRET_FLAG_ALL \
|
2018-12-29 20:23:09 +00:00
|
|
|
((NMSettingSecretFlags) ( NM_SETTING_SECRET_FLAG_NONE \
|
|
|
|
| NM_SETTING_SECRET_FLAG_AGENT_OWNED \
|
|
|
|
| NM_SETTING_SECRET_FLAG_NOT_SAVED \
|
|
|
|
| NM_SETTING_SECRET_FLAG_NOT_REQUIRED))
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
_nm_setting_secret_flags_valid (NMSettingSecretFlags flags)
|
|
|
|
{
|
2019-02-09 10:18:17 +00:00
|
|
|
return !NM_FLAGS_ANY (flags, ~NM_SETTING_SECRET_FLAG_ALL);
|
2018-12-29 20:23:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
2014-08-11 16:21:53 +00:00
|
|
|
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 08:43:53 +00:00
|
|
|
const char *nm_bluetooth_capability_to_string (NMBluetoothCapabilities capabilities, char *buf, gsize len);
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2019-07-09 09:26:02 +00:00
|
|
|
#define NM_DHCP_HOSTNAME_FLAGS_FQDN_MASK \
|
|
|
|
( NM_DHCP_HOSTNAME_FLAG_FQDN_ENCODED \
|
|
|
|
| NM_DHCP_HOSTNAME_FLAG_FQDN_SERV_UPDATE \
|
|
|
|
| NM_DHCP_HOSTNAME_FLAG_FQDN_NO_UPDATE \
|
|
|
|
| NM_DHCP_HOSTNAME_FLAG_FQDN_CLEAR_FLAGS)
|
|
|
|
|
|
|
|
#define NM_DHCP_HOSTNAME_FLAGS_FQDN_DEFAULT_IP4 \
|
|
|
|
( NM_DHCP_HOSTNAME_FLAG_FQDN_ENCODED \
|
|
|
|
| NM_DHCP_HOSTNAME_FLAG_FQDN_SERV_UPDATE)
|
|
|
|
|
|
|
|
#define NM_DHCP_HOSTNAME_FLAGS_FQDN_DEFAULT_IP6 \
|
|
|
|
NM_DHCP_HOSTNAME_FLAG_FQDN_SERV_UPDATE
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
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 12:42:50 +00:00
|
|
|
typedef enum { /*< skip >*/
|
|
|
|
NM_SETTING_PARSE_FLAGS_NONE = 0,
|
|
|
|
NM_SETTING_PARSE_FLAGS_STRICT = 1LL << 0,
|
|
|
|
NM_SETTING_PARSE_FLAGS_BEST_EFFORT = 1LL << 1,
|
2016-03-17 09:34:44 +00:00
|
|
|
NM_SETTING_PARSE_FLAGS_NORMALIZE = 1LL << 2,
|
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 12:42:50 +00:00
|
|
|
|
|
|
|
_NM_SETTING_PARSE_FLAGS_LAST,
|
|
|
|
NM_SETTING_PARSE_FLAGS_ALL = ((_NM_SETTING_PARSE_FLAGS_LAST - 1) << 1) - 1,
|
|
|
|
} NMSettingParseFlags;
|
|
|
|
|
|
|
|
gboolean _nm_connection_replace_settings (NMConnection *connection,
|
|
|
|
GVariant *new_settings,
|
|
|
|
NMSettingParseFlags parse_flags,
|
|
|
|
GError **error);
|
|
|
|
|
2018-06-27 15:00:55 +00:00
|
|
|
gpointer _nm_connection_check_main_setting (NMConnection *connection,
|
|
|
|
const char *setting_name,
|
|
|
|
GError **error);
|
|
|
|
|
2019-06-27 07:07:16 +00:00
|
|
|
typedef struct {
|
2019-06-27 07:09:06 +00:00
|
|
|
struct {
|
|
|
|
guint64 val;
|
|
|
|
bool has;
|
|
|
|
} timestamp;
|
|
|
|
|
|
|
|
const char **seen_bssids;
|
|
|
|
|
2019-06-27 07:07:16 +00:00
|
|
|
} NMConnectionSerializationOptions;
|
|
|
|
|
|
|
|
GVariant *nm_connection_to_dbus_full (NMConnection *connection,
|
|
|
|
NMConnectionSerializationFlags flags,
|
|
|
|
const NMConnectionSerializationOptions *options);
|
|
|
|
|
2019-01-04 10:28:27 +00:00
|
|
|
typedef enum {
|
|
|
|
/* whether the connection has any secrets.
|
|
|
|
*
|
|
|
|
* @arg may be %NULL or a pointer to a gboolean for the result. The return
|
|
|
|
* value of _nm_connection_aggregate() is likewise the boolean result. */
|
|
|
|
NM_CONNECTION_AGGREGATE_ANY_SECRETS,
|
|
|
|
|
|
|
|
/* whether the connection has any secret with flags NM_SETTING_SECRET_FLAG_NONE.
|
|
|
|
* Note that this only cares about the flags, not whether the secret is actually
|
|
|
|
* present.
|
|
|
|
*
|
|
|
|
* @arg may be %NULL or a pointer to a gboolean for the result. The return
|
|
|
|
* value of _nm_connection_aggregate() is likewise the boolean result. */
|
|
|
|
NM_CONNECTION_AGGREGATE_ANY_SYSTEM_SECRET_FLAGS,
|
|
|
|
} NMConnectionAggregateType;
|
|
|
|
|
|
|
|
gboolean _nm_connection_aggregate (NMConnection *connection,
|
|
|
|
NMConnectionAggregateType type,
|
|
|
|
gpointer arg);
|
|
|
|
|
2017-02-28 18:34:59 +00:00
|
|
|
/**
|
|
|
|
* NMSettingVerifyResult:
|
|
|
|
* @NM_SETTING_VERIFY_SUCCESS: the setting verifies successfully
|
|
|
|
* @NM_SETTING_VERIFY_ERROR: the setting has a serious misconfiguration
|
|
|
|
* @NM_SETTING_VERIFY_NORMALIZABLE: the setting is valid but has properties
|
|
|
|
* that should be normalized
|
|
|
|
* @NM_SETTING_VERIFY_NORMALIZABLE_ERROR: the setting is invalid but the
|
|
|
|
* errors can be fixed by nm_connection_normalize().
|
|
|
|
*/
|
|
|
|
typedef enum {
|
|
|
|
NM_SETTING_VERIFY_SUCCESS = TRUE,
|
|
|
|
NM_SETTING_VERIFY_ERROR = FALSE,
|
|
|
|
NM_SETTING_VERIFY_NORMALIZABLE = 2,
|
|
|
|
NM_SETTING_VERIFY_NORMALIZABLE_ERROR = 3,
|
|
|
|
} NMSettingVerifyResult;
|
|
|
|
|
|
|
|
NMSettingVerifyResult _nm_connection_verify (NMConnection *connection, GError **error);
|
|
|
|
|
2019-06-01 09:39:34 +00:00
|
|
|
gboolean _nm_connection_ensure_normalized (NMConnection *connection,
|
|
|
|
gboolean allow_modify,
|
2019-06-14 11:41:24 +00:00
|
|
|
const char *expected_uuid,
|
|
|
|
gboolean coerce_uuid,
|
2019-06-01 09:39:34 +00:00
|
|
|
NMConnection **out_connection_clone,
|
|
|
|
GError **error);
|
|
|
|
|
2017-03-01 12:50:59 +00:00
|
|
|
gboolean _nm_connection_remove_setting (NMConnection *connection, GType setting_type);
|
|
|
|
|
2019-05-29 15:10:51 +00:00
|
|
|
#if NM_MORE_ASSERTS
|
2019-06-21 07:51:15 +00:00
|
|
|
extern const char _nmtst_connection_unchanging_user_data;
|
2019-05-29 15:10:51 +00:00
|
|
|
void nmtst_connection_assert_unchanging (NMConnection *connection);
|
|
|
|
#else
|
|
|
|
static inline void
|
|
|
|
nmtst_connection_assert_unchanging (NMConnection *connection)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2016-03-17 09:34:44 +00:00
|
|
|
NMConnection *_nm_simple_connection_new_from_dbus (GVariant *dict,
|
|
|
|
NMSettingParseFlags parse_flags,
|
|
|
|
GError **error);
|
|
|
|
|
2017-06-01 11:43:52 +00:00
|
|
|
NMSettingPriority _nm_setting_get_setting_priority (NMSetting *setting);
|
2014-08-11 16:21:53 +00:00
|
|
|
|
2014-02-26 09:09:54 +00:00
|
|
|
gboolean _nm_setting_get_property (NMSetting *setting, const char *name, GValue *value);
|
|
|
|
|
libnm: add generic-data for implementing NMSetting
Add a new way how NMSetting subclasses can be implemented.
Currently, most NMSetting implementations realize all their properties
via GObject properties. That has some downsides:
- the biggest one, is the large effort to add new properties.
Most of them are implemented on a one-by-one basis and they come
with additional API (like native getter functions).
It makes it cumbersome to add more properties.
- for certain properties, it's hard to encode them entirely in
a GObject property. That results in unusable API like
NM_SETTING_IP_CONFIG_ADDRESSES, NM_SETTING_BOND_OPTIONS,
NM_SETTING_USER_DATA. These complex valued properties only
exist, because we currently always need GObject properties
to even implement simple functionality. For example,
nm_setting_duplicate() is entirely implemented via
nm_setting_enumerate_values(), which can only iterate
GObject properies. There is no reason why this is necessary.
Note also how nmcli badly handles bond options and VPN
data. That is only a shortcoming of nmcli and wouldn't
need to be that way. But it happend, because we didn't
keep an open mind that settings might be more than just
accessing GObject properties.
- a major point of NMSetting is to convert to/from a GVariant
from the D-Bus API. As NMSetting needs to squeeze all values
into the static GObject structure, there is no place to
encode invalid or unknown properties. Optimally,
_nm_setting_new_from_dbus() does not loose any information
and a subsequent _nm_setting_to_dbus() can restore the original
variant. That is interesting, because we want that an older
libnm client can talk to a newer NetworkManager version. The
client needs to handle unknown properties gracefully to stay
forward compatible. However, it also should not just drop the
properties on the floor.
Note however, optimally we want that nm_setting_verify() still
can reject settings that have such unknown/invalid values. So,
it should be possible to create an NMSetting instance without
error or loosing information. But verify() should be usable to
identify such settings as invalid.
They also have a few upsides.
- libnm is heavily oriented around GObject. So, we generate
our nm-settings manual based on the gtk-doc. Note however,
how we fail to generate a useful manual for bond.options.
Also note, that there is no reason we couldn't generate
great documentation, even if the properties are not GObject
properties.
- GObject properties do give some functionality like meta-data,
data binding and notification. However, the meta-data is not
sufficient on its own. Note how keyfile and nmcli need extensive
descriptor tables on top of GObject properties, to make this
useful. Note how GObject notifications for NMSetting instances
are usually not useful, aside for data binding like nmtui does.
Also note how NMSettingBond already follows a different paradigm
than using GObject properties. Nowdays, NMSettingBond is considered
a mistake (related bug rh#1032808). Many ideas of NMSettingBond
are flawed, like exposing an inferiour API that reduces everything
to a string hash. Also, it only implemented the options hash inside
NMSettingBond. That means, if we would consider this a good style,
we would have to duplicate this approach in each new setting
implementation.
Add a new style to track data for NMSetting subclasses. It keeps
an internal hash table with all GVariant properies. Also, the
functionality is hooked into NMSetting base class, so all future
subclasses that follow this way, can benefit from this. This approach
has a few similiarties with NMSettingBond, but avoids its flaws.
With this, we also no longer need GObject properties (if we would
also implement generating useful documentation based on non-gkt-doc).
They may be added as accessors if they are useful, but there is no
need for them.
Also, handling the properties as a hash of variants invites for a
more generic approach when handling them. While we still could add
accessors that operate on a one-by-one bases, this leads to a more
generic usage where we apply common functionality to a set of properties.
Also, this is for the moment entirely internal and an implementation
detail. It's entirely up to the NMSetting subclass to make use of this
new style. Also, there are little hooks for the subclass available.
If they turn out to be necessary, they might be added. However, for
the moment, the functionality is restricted to what is useful and
necessary.
2018-07-27 08:05:40 +00:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
GHashTable *_nm_setting_gendata_hash (NMSetting *setting,
|
|
|
|
gboolean create_if_necessary);
|
|
|
|
|
|
|
|
void _nm_setting_gendata_notify (NMSetting *setting,
|
|
|
|
gboolean keys_changed);
|
|
|
|
|
|
|
|
guint _nm_setting_gendata_get_all (NMSetting *setting,
|
|
|
|
const char *const**out_names,
|
|
|
|
GVariant *const**out_values);
|
|
|
|
|
|
|
|
gboolean _nm_setting_gendata_reset_from_hash (NMSetting *setting,
|
|
|
|
GHashTable *new);
|
|
|
|
|
|
|
|
void _nm_setting_gendata_to_gvalue (NMSetting *setting,
|
|
|
|
GValue *value);
|
|
|
|
|
|
|
|
GVariant *nm_setting_gendata_get (NMSetting *setting,
|
|
|
|
const char *name);
|
|
|
|
|
|
|
|
const char *const*nm_setting_gendata_get_all_names (NMSetting *setting,
|
|
|
|
guint *out_len);
|
|
|
|
|
|
|
|
GVariant *const*nm_setting_gendata_get_all_values (NMSetting *setting);
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
libnm, cli, ifcfg-rh: add NMSettingEthtool setting
Note that in NetworkManager API (D-Bus, libnm, and nmcli),
the features are called "feature-xyz". The "feature-" prefix
is used, because NMSettingEthtool possibly will gain support
for options that are not only -K|--offload|--features, for
example -C|--coalesce.
The "xzy" suffix is either how ethtool utility calls the feature
("tso", "rx"). Or, if ethtool utility specifies no alias for that
feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation").
If possible, we prefer ethtool utility's naming.
Also note, how the features "feature-sg", "feature-tso", and
"feature-tx" actually refer to multiple underlying kernel features
at once. This too follows what ethtool utility does.
The functionality is not yet implemented server-side.
2018-07-16 21:37:55 +00:00
|
|
|
guint nm_setting_ethtool_init_features (NMSettingEthtool *setting,
|
|
|
|
NMTernary *requested /* indexed by NMEthtoolID - _NM_ETHTOOL_ID_FEATURE_FIRST */);
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2016-10-13 15:51:07 +00:00
|
|
|
#define NM_UTILS_HWADDR_LEN_MAX_STR (NM_UTILS_HWADDR_LEN_MAX * 3)
|
|
|
|
|
|
|
|
guint8 *_nm_utils_hwaddr_aton (const char *asc, gpointer buffer, gsize buffer_length, gsize *out_length);
|
|
|
|
const char *nm_utils_hwaddr_ntoa_buf (gconstpointer addr, gsize addr_len, gboolean upper_case, char *buf, gsize buf_len);
|
2016-05-25 08:46:48 +00:00
|
|
|
|
2019-03-24 19:36:00 +00:00
|
|
|
gboolean nm_utils_is_valid_iface_name_utf8safe (const char *utf8safe_name);
|
|
|
|
|
2014-07-27 21:33:16 +00:00
|
|
|
GSList * _nm_utils_hash_values_to_slist (GHashTable *hash);
|
|
|
|
|
2014-06-24 21:40:08 +00:00
|
|
|
GHashTable *_nm_utils_copy_strdict (GHashTable *strdict);
|
|
|
|
|
2014-06-24 16:46:03 +00:00
|
|
|
typedef gpointer (*NMUtilsCopyFunc) (gpointer);
|
|
|
|
|
2017-12-11 10:37:21 +00:00
|
|
|
const char **_nm_ip_address_get_attribute_names (const NMIPAddress *addr, gboolean sorted, guint *out_length);
|
|
|
|
|
2019-04-24 07:24:15 +00:00
|
|
|
void _nm_setting_wired_clear_s390_options (NMSettingWired *setting);
|
|
|
|
|
2017-09-13 18:43:16 +00:00
|
|
|
gboolean _nm_ip_route_attribute_validate_all (const NMIPRoute *route);
|
2017-10-30 11:23:34 +00:00
|
|
|
const char **_nm_ip_route_get_attribute_names (const NMIPRoute *route, gboolean sorted, guint *out_length);
|
2019-04-19 09:51:42 +00:00
|
|
|
GHashTable *_nm_ip_route_get_attributes (NMIPRoute *route);
|
2017-09-13 18:43:16 +00:00
|
|
|
|
2018-12-01 16:44:37 +00:00
|
|
|
NMSriovVF *_nm_utils_sriov_vf_from_strparts (const char *index, const char *detail, gboolean ignore_unknown, GError **error);
|
2018-05-25 10:05:24 +00:00
|
|
|
gboolean _nm_sriov_vf_attribute_validate_all (const NMSriovVF *vf, GError **error);
|
|
|
|
|
2014-08-26 12:31:04 +00:00
|
|
|
GPtrArray *_nm_utils_copy_array (const GPtrArray *array,
|
|
|
|
NMUtilsCopyFunc copy_func,
|
|
|
|
GDestroyNotify free_func);
|
|
|
|
GPtrArray *_nm_utils_copy_object_array (const GPtrArray *array);
|
|
|
|
|
2016-09-23 13:03:41 +00:00
|
|
|
gssize _nm_utils_ptrarray_find_first (gconstpointer *list, gssize len, gconstpointer needle);
|
2015-05-12 09:29:29 +00:00
|
|
|
|
2015-07-01 12:08:51 +00:00
|
|
|
GSList * _nm_utils_strv_to_slist (char **strv, gboolean deep_copy);
|
2019-05-27 14:16:41 +00:00
|
|
|
char ** _nm_utils_slist_to_strv (const GSList *slist, gboolean deep_copy);
|
2015-07-01 12:02:31 +00:00
|
|
|
|
|
|
|
GPtrArray * _nm_utils_strv_to_ptrarray (char **strv);
|
2019-05-27 14:16:41 +00:00
|
|
|
char ** _nm_utils_ptrarray_to_strv (const GPtrArray *ptrarray);
|
2015-07-01 12:02:31 +00:00
|
|
|
|
2015-05-28 19:52:24 +00:00
|
|
|
gboolean _nm_utils_check_file (const char *filename,
|
|
|
|
gint64 check_owner,
|
|
|
|
NMUtilsCheckFilePredicate check_file,
|
|
|
|
gpointer user_data,
|
|
|
|
struct stat *out_st,
|
|
|
|
GError **error);
|
|
|
|
|
libnm: require exact vpn plugin filename
Originally, nm-applet loaded the vpn plugins by passing the filename
to g_module_open(). Thereby, g_module_open() allowed for missing file
extension and tries to complete the name with a system-dependent suffix.
When porting to libnm, we kept that behavior but did more elaborate
checks on the file, like checking owner and permissions.
Change to no longer trying to append the system suffix, but require
an exact path. That is no usability problem, because the plugin path
is specified in the .name files, and we just require them now to be the
full path (including the .so extension).
Note also, that this only affects new, libnm-based vpn plugins, thus there
is no change in behavior for legacy libnm-glib based plugins.
Fixes: eed0d0c58f7f13638eb587e240737048d729cb68
2015-08-18 09:56:17 +00:00
|
|
|
gboolean _nm_utils_check_module_file (const char *name,
|
|
|
|
int check_owner,
|
|
|
|
NMUtilsCheckFilePredicate check_file,
|
|
|
|
gpointer user_data,
|
|
|
|
GError **error);
|
2015-05-28 20:07:55 +00:00
|
|
|
|
2018-10-30 12:07:25 +00:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
typedef struct _NMUuid {
|
|
|
|
guchar uuid[16];
|
|
|
|
} NMUuid;
|
|
|
|
|
|
|
|
NMUuid *_nm_utils_uuid_parse (const char *str,
|
|
|
|
NMUuid *uuid);
|
|
|
|
char *_nm_utils_uuid_unparse (const NMUuid *uuid,
|
|
|
|
char *out_str /*[37]*/);
|
|
|
|
NMUuid *_nm_utils_uuid_generate_random (NMUuid *out_uuid);
|
|
|
|
|
2018-10-31 09:38:01 +00:00
|
|
|
gboolean nm_utils_uuid_is_null (const NMUuid *uuid);
|
|
|
|
|
2014-12-03 16:29:54 +00:00
|
|
|
#define NM_UTILS_UUID_TYPE_LEGACY 0
|
2018-10-31 07:27:41 +00:00
|
|
|
#define NM_UTILS_UUID_TYPE_VERSION3 3
|
|
|
|
#define NM_UTILS_UUID_TYPE_VERSION5 5
|
2014-12-03 16:29:54 +00:00
|
|
|
|
2018-10-31 09:14:54 +00:00
|
|
|
NMUuid *nm_utils_uuid_generate_from_string_bin (NMUuid *uuid, const char *s, gssize slen, int uuid_type, gpointer type_args);
|
|
|
|
|
2014-12-03 16:29:54 +00:00
|
|
|
char *nm_utils_uuid_generate_from_string (const char *s, gssize slen, int uuid_type, gpointer type_args);
|
|
|
|
|
2017-05-28 14:34:31 +00:00
|
|
|
/* arbitrarily chosen namespace UUID for _nm_utils_uuid_generate_from_strings() */
|
2015-02-22 19:15:52 +00:00
|
|
|
#define NM_UTILS_UUID_NS "b425e9fb-7598-44b4-9e3b-5a2e3aaa4905"
|
|
|
|
|
|
|
|
char *_nm_utils_uuid_generate_from_strings (const char *string1, ...) G_GNUC_NULL_TERMINATED;
|
|
|
|
|
2016-11-08 16:39:26 +00:00
|
|
|
char *nm_utils_uuid_generate_buf_ (char *buf);
|
|
|
|
#define nm_utils_uuid_generate_buf(buf) \
|
|
|
|
({ \
|
|
|
|
G_STATIC_ASSERT (sizeof (buf) == G_N_ELEMENTS (buf) && sizeof (buf) >= 37); \
|
|
|
|
nm_utils_uuid_generate_buf_ (buf); \
|
|
|
|
})
|
|
|
|
#define nm_utils_uuid_generate_a() (nm_utils_uuid_generate_buf_ (g_alloca (37)))
|
|
|
|
|
2014-10-15 18:55:41 +00:00
|
|
|
void _nm_dbus_errors_init (void);
|
|
|
|
|
2014-11-14 16:45:51 +00:00
|
|
|
extern gboolean _nm_utils_is_manager_process;
|
|
|
|
|
2018-10-11 08:54:12 +00:00
|
|
|
gboolean _nm_dbus_typecheck_response (GVariant *response,
|
|
|
|
const GVariantType *reply_type,
|
|
|
|
GError **error);
|
|
|
|
|
2015-03-27 12:02:25 +00:00
|
|
|
gulong _nm_dbus_signal_connect_data (GDBusProxy *proxy,
|
|
|
|
const char *signal_name,
|
|
|
|
const GVariantType *signature,
|
|
|
|
GCallback c_handler,
|
|
|
|
gpointer data,
|
|
|
|
GClosureNotify destroy_data,
|
|
|
|
GConnectFlags connect_flags);
|
|
|
|
#define _nm_dbus_signal_connect(proxy, name, signature, handler, data) \
|
|
|
|
_nm_dbus_signal_connect_data (proxy, name, signature, handler, data, NULL, (GConnectFlags) 0)
|
|
|
|
|
2015-03-27 12:44:50 +00:00
|
|
|
GVariant *_nm_dbus_proxy_call_finish (GDBusProxy *proxy,
|
|
|
|
GAsyncResult *res,
|
|
|
|
const GVariantType *reply_type,
|
|
|
|
GError **error);
|
|
|
|
|
2018-10-11 08:54:12 +00:00
|
|
|
GVariant * _nm_dbus_connection_call_finish (GDBusConnection *dbus_connection,
|
|
|
|
GAsyncResult *result,
|
|
|
|
const GVariantType *reply_type,
|
|
|
|
GError **error);
|
|
|
|
|
2015-03-27 13:04:13 +00:00
|
|
|
gboolean _nm_dbus_error_has_name (GError *error,
|
|
|
|
const char *dbus_error_name);
|
2015-05-20 10:21:11 +00:00
|
|
|
|
2016-10-02 16:22:50 +00:00
|
|
|
/*****************************************************************************/
|
2015-05-20 10:21:11 +00:00
|
|
|
|
2018-08-12 10:15:38 +00:00
|
|
|
char *_nm_utils_ssid_to_string_arr (const guint8 *ssid, gsize len);
|
|
|
|
char *_nm_utils_ssid_to_string (GBytes *ssid);
|
|
|
|
char *_nm_utils_ssid_to_utf8 (GBytes *ssid);
|
|
|
|
gboolean _nm_utils_is_empty_ssid (GBytes *ssid);
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2015-05-22 11:26:40 +00:00
|
|
|
gboolean _nm_vpn_plugin_info_check_file (const char *filename,
|
|
|
|
gboolean check_absolute,
|
|
|
|
gboolean do_validate_filename,
|
|
|
|
gint64 check_owner,
|
|
|
|
NMUtilsCheckFilePredicate check_file,
|
|
|
|
gpointer user_data,
|
|
|
|
GError **error);
|
|
|
|
|
|
|
|
const char *_nm_vpn_plugin_info_get_default_dir_etc (void);
|
|
|
|
const char *_nm_vpn_plugin_info_get_default_dir_lib (void);
|
|
|
|
const char *_nm_vpn_plugin_info_get_default_dir_user (void);
|
|
|
|
|
|
|
|
GSList *_nm_vpn_plugin_info_list_load_dir (const char *dirname,
|
|
|
|
gboolean do_validate_filename,
|
|
|
|
gint64 check_owner,
|
|
|
|
NMUtilsCheckFilePredicate check_file,
|
|
|
|
gpointer user_data);
|
|
|
|
|
2016-10-02 16:22:50 +00:00
|
|
|
/*****************************************************************************/
|
2015-05-22 11:26:40 +00:00
|
|
|
|
2015-05-20 10:21:11 +00:00
|
|
|
typedef struct {
|
|
|
|
const char *name;
|
|
|
|
gboolean numeric;
|
|
|
|
gboolean ipv6_only;
|
2015-05-20 10:31:10 +00:00
|
|
|
} NMUtilsDNSOptionDesc;
|
2015-05-20 10:21:11 +00:00
|
|
|
|
2015-05-20 10:31:10 +00:00
|
|
|
extern const NMUtilsDNSOptionDesc _nm_utils_dns_option_descs[];
|
2015-05-20 10:21:11 +00:00
|
|
|
|
|
|
|
gboolean _nm_utils_dns_option_validate (const char *option, char **out_name,
|
|
|
|
long *out_value, gboolean ipv6,
|
2015-05-20 10:31:10 +00:00
|
|
|
const NMUtilsDNSOptionDesc *option_descs);
|
2017-09-27 09:54:51 +00:00
|
|
|
gssize _nm_utils_dns_option_find_idx (GPtrArray *array, const char *option);
|
2015-05-20 10:21:11 +00:00
|
|
|
|
2016-10-02 16:22:50 +00:00
|
|
|
/*****************************************************************************/
|
2015-05-20 10:21:11 +00:00
|
|
|
|
2015-05-22 16:52:22 +00:00
|
|
|
typedef struct _NMUtilsStrStrDictKey NMUtilsStrStrDictKey;
|
|
|
|
guint _nm_utils_strstrdictkey_hash (gconstpointer a);
|
|
|
|
gboolean _nm_utils_strstrdictkey_equal (gconstpointer a, gconstpointer b);
|
|
|
|
NMUtilsStrStrDictKey *_nm_utils_strstrdictkey_create (const char *v1, const char *v2);
|
|
|
|
|
|
|
|
#define _nm_utils_strstrdictkey_static(v1, v2) \
|
|
|
|
( (NMUtilsStrStrDictKey *) ("\03" v1 "\0" v2 "") )
|
|
|
|
|
2016-10-02 16:22:50 +00:00
|
|
|
/*****************************************************************************/
|
2015-05-22 16:52:22 +00:00
|
|
|
|
2015-10-30 10:02:44 +00:00
|
|
|
gboolean _nm_setting_vlan_set_priorities (NMSettingVlan *setting,
|
|
|
|
NMVlanPriorityMap map,
|
|
|
|
const NMVlanQosMapping *qos_map,
|
|
|
|
guint n_qos_map);
|
|
|
|
void _nm_setting_vlan_get_priorities (NMSettingVlan *setting,
|
|
|
|
NMVlanPriorityMap map,
|
|
|
|
NMVlanQosMapping **out_qos_map,
|
|
|
|
guint *out_n_qos_map);
|
|
|
|
|
2016-10-02 16:22:50 +00:00
|
|
|
/*****************************************************************************/
|
2015-10-30 10:02:44 +00:00
|
|
|
|
all: make MAC address randomization algorithm configurable
For the per-connection settings "ethernet.cloned-mac-address"
and "wifi.cloned-mac-address", and for the per-device setting
"wifi.scan-rand-mac-address", we may generate MAC addresses using
either the "random" or "stable" algorithm.
Add new properties "generate-mac-address-mask" that allow to configure
which bits of the MAC address will be scrambled.
By default, the "random" and "stable" algorithms scamble all bits
of the MAC address, including the OUI part and generate a locally-
administered, unicast address.
By specifying a MAC address mask, we can now configure to perserve
parts of the current MAC address of the device. For example, setting
"FF:FF:FF:00:00:00" will preserve the first 3 octects of the current
MAC address.
One can also explicitly specify a MAC address to use instead of the
current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00"
sets the OUI part of the MAC address to "68:F7:28" while scrambling
the last 3 octects.
Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble
all bits of the MAC address, except clearing the second-least
significant bit. Thus, creating a burned-in address, globally
administered.
One can also supply a list of MAC addresses like
"FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which
case a MAC address is choosen randomly.
To fully scamble the MAC address one can configure
"02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00".
which also randomly creates either a locally or globally administered
address.
With this, the following macchanger options can be implemented:
`macchanger --random`
This is the default if no mask is configured.
-> ""
while is the same as:
-> "00:00:00:00:00:00"
-> "02:00:00:00:00:00 02:00:00:00:00:00"
`macchanger --random --bia`
-> "02:00:00:00:00:00 00:00:00:00:00:00"
`macchanger --ending`
This option cannot be fully implemented, because macchanger
uses the current MAC address but also implies --bia.
-> "FF:FF:FF:00:00:00"
This would yields the same result only if the current MAC address
is already a burned-in address too. Otherwise, it has not the same
effect as --ending.
-> "FF:FF:FF:00:00:00 <MAC_ADDR>"
Alternatively, instead of using the current MAC address,
spell the OUI part out. But again, that is not really the
same as macchanger does because you explictly have to name
the OUI part to use.
`machanger --another`
`machanger --another_any`
-> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..."
"$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
2016-06-22 18:31:39 +00:00
|
|
|
struct ether_addr;
|
|
|
|
|
|
|
|
gboolean _nm_utils_generate_mac_address_mask_parse (const char *value,
|
|
|
|
struct ether_addr *out_mask,
|
|
|
|
struct ether_addr **out_ouis,
|
|
|
|
gsize *out_ouis_len,
|
|
|
|
GError **error);
|
|
|
|
|
2016-10-02 16:22:50 +00:00
|
|
|
/*****************************************************************************/
|
2019-03-02 21:17:49 +00:00
|
|
|
|
2019-07-28 12:37:44 +00:00
|
|
|
static inline gpointer
|
|
|
|
_nm_connection_get_setting (NMConnection *connection,
|
|
|
|
GType type)
|
|
|
|
{
|
|
|
|
return (gpointer) nm_connection_get_setting (connection, type);
|
|
|
|
}
|
|
|
|
|
2019-03-02 21:17:49 +00:00
|
|
|
NMSettingIPConfig *nm_connection_get_setting_ip_config (NMConnection *connection,
|
|
|
|
int addr_family);
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
all: make MAC address randomization algorithm configurable
For the per-connection settings "ethernet.cloned-mac-address"
and "wifi.cloned-mac-address", and for the per-device setting
"wifi.scan-rand-mac-address", we may generate MAC addresses using
either the "random" or "stable" algorithm.
Add new properties "generate-mac-address-mask" that allow to configure
which bits of the MAC address will be scrambled.
By default, the "random" and "stable" algorithms scamble all bits
of the MAC address, including the OUI part and generate a locally-
administered, unicast address.
By specifying a MAC address mask, we can now configure to perserve
parts of the current MAC address of the device. For example, setting
"FF:FF:FF:00:00:00" will preserve the first 3 octects of the current
MAC address.
One can also explicitly specify a MAC address to use instead of the
current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00"
sets the OUI part of the MAC address to "68:F7:28" while scrambling
the last 3 octects.
Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble
all bits of the MAC address, except clearing the second-least
significant bit. Thus, creating a burned-in address, globally
administered.
One can also supply a list of MAC addresses like
"FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which
case a MAC address is choosen randomly.
To fully scamble the MAC address one can configure
"02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00".
which also randomly creates either a locally or globally administered
address.
With this, the following macchanger options can be implemented:
`macchanger --random`
This is the default if no mask is configured.
-> ""
while is the same as:
-> "00:00:00:00:00:00"
-> "02:00:00:00:00:00 02:00:00:00:00:00"
`macchanger --random --bia`
-> "02:00:00:00:00:00 00:00:00:00:00:00"
`macchanger --ending`
This option cannot be fully implemented, because macchanger
uses the current MAC address but also implies --bia.
-> "FF:FF:FF:00:00:00"
This would yields the same result only if the current MAC address
is already a burned-in address too. Otherwise, it has not the same
effect as --ending.
-> "FF:FF:FF:00:00:00 <MAC_ADDR>"
Alternatively, instead of using the current MAC address,
spell the OUI part out. But again, that is not really the
same as macchanger does because you explictly have to name
the OUI part to use.
`machanger --another`
`machanger --another_any`
-> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..."
"$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
2016-06-22 18:31:39 +00:00
|
|
|
|
2016-03-16 10:22:07 +00:00
|
|
|
typedef enum {
|
|
|
|
NM_BOND_OPTION_TYPE_INT,
|
|
|
|
NM_BOND_OPTION_TYPE_STRING,
|
|
|
|
NM_BOND_OPTION_TYPE_BOTH,
|
|
|
|
NM_BOND_OPTION_TYPE_IP,
|
2016-03-15 16:37:06 +00:00
|
|
|
NM_BOND_OPTION_TYPE_MAC,
|
2016-03-16 10:22:07 +00:00
|
|
|
NM_BOND_OPTION_TYPE_IFNAME,
|
|
|
|
} NMBondOptionType;
|
|
|
|
|
|
|
|
NMBondOptionType
|
|
|
|
_nm_setting_bond_get_option_type (NMSettingBond *setting, const char *name);
|
|
|
|
|
2016-10-02 16:22:50 +00:00
|
|
|
/*****************************************************************************/
|
2017-06-07 10:46:10 +00:00
|
|
|
|
|
|
|
/* nm_connection_get_uuid() asserts against NULL, which is the right thing to
|
|
|
|
* do in order to catch bugs. However, sometimes that behavior is inconvenient.
|
|
|
|
* Just try or return NULL. */
|
|
|
|
|
|
|
|
static inline const char *
|
|
|
|
_nm_connection_get_id (NMConnection *connection)
|
|
|
|
{
|
|
|
|
return connection ? nm_connection_get_id (connection) : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline const char *
|
|
|
|
_nm_connection_get_uuid (NMConnection *connection)
|
|
|
|
{
|
|
|
|
return connection ? nm_connection_get_uuid (connection) : NULL;
|
|
|
|
}
|
|
|
|
|
all: add connection.multi-connect property for wildcard profiles
Add a new option that allows to activate a profile multiple times
(at the same time). Previoulsy, all profiles were implicitly
NM_SETTING_CONNECTION_MULTI_CONNECT_SINGLE, meaning, that activating
a profile that is already active will deactivate it first.
This will make more sense, as we also add more match-options how
profiles can be restricted to particular devices. We already have
connection.type, connection.interface-name, and (ethernet|wifi).mac-address
to restrict a profile to particular devices. For example, it is however
not possible to specify a wildcard like "eth*" to match a profile to
a set of devices by interface-name. That is another missing feature,
and once we extend the matching capabilities, it makes more sense to
activate a profile multiple times.
See also https://bugzilla.redhat.com/show_bug.cgi?id=997998, which
previously changed that a connection is restricted to a single activation
at a time. This work relaxes that again.
This only adds the new property, it is not used nor implemented yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1555012
2018-04-10 09:45:35 +00:00
|
|
|
NMConnectionMultiConnect _nm_connection_get_multi_connect (NMConnection *connection);
|
|
|
|
|
2017-06-07 10:46:10 +00:00
|
|
|
/*****************************************************************************/
|
2016-04-30 14:43:10 +00:00
|
|
|
|
2016-07-04 14:25:39 +00:00
|
|
|
typedef enum {
|
|
|
|
NM_BOND_MODE_UNKNOWN = 0,
|
|
|
|
NM_BOND_MODE_ROUNDROBIN,
|
|
|
|
NM_BOND_MODE_ACTIVEBACKUP,
|
|
|
|
NM_BOND_MODE_XOR,
|
|
|
|
NM_BOND_MODE_BROADCAST,
|
|
|
|
NM_BOND_MODE_8023AD,
|
|
|
|
NM_BOND_MODE_TLB,
|
|
|
|
NM_BOND_MODE_ALB,
|
|
|
|
} NMBondMode;
|
|
|
|
|
|
|
|
NMBondMode _nm_setting_bond_mode_from_string (const char *str);
|
|
|
|
gboolean _nm_setting_bond_option_supported (const char *option, NMBondMode mode);
|
|
|
|
|
2016-10-02 16:22:50 +00:00
|
|
|
/*****************************************************************************/
|
2016-07-04 14:25:39 +00:00
|
|
|
|
2017-05-31 20:37:49 +00:00
|
|
|
NMSettingBluetooth *_nm_connection_get_setting_bluetooth_for_nap (NMConnection *connection);
|
|
|
|
|
2016-04-30 14:43:10 +00:00
|
|
|
gboolean _nm_utils_inet6_is_token (const struct in6_addr *in6addr);
|
|
|
|
|
2016-10-02 16:22:50 +00:00
|
|
|
/*****************************************************************************/
|
2016-08-30 13:21:16 +00:00
|
|
|
|
2019-05-12 10:13:28 +00:00
|
|
|
NMTeamLinkWatcher *_nm_team_link_watcher_ref (NMTeamLinkWatcher *watcher);
|
|
|
|
|
2019-05-11 08:31:57 +00:00
|
|
|
int nm_team_link_watcher_cmp (const NMTeamLinkWatcher *watcher, const NMTeamLinkWatcher *other);
|
|
|
|
|
|
|
|
int nm_team_link_watchers_cmp (const NMTeamLinkWatcher *const*a,
|
|
|
|
const NMTeamLinkWatcher *const*b,
|
|
|
|
gsize len,
|
|
|
|
gboolean ignore_order);
|
|
|
|
|
|
|
|
gboolean nm_team_link_watchers_equal (const GPtrArray *a,
|
|
|
|
const GPtrArray *b,
|
|
|
|
gboolean ignore_order);
|
2019-03-21 10:30:21 +00:00
|
|
|
|
2017-02-16 11:20:51 +00:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
2017-11-18 16:17:24 +00:00
|
|
|
guint32 _nm_utils_parse_tc_handle (const char *str,
|
|
|
|
GError **error);
|
|
|
|
void _nm_utils_string_append_tc_parent (GString *string,
|
|
|
|
const char *prefix,
|
|
|
|
guint32 parent);
|
|
|
|
void _nm_utils_string_append_tc_qdisc_rest (GString *string,
|
|
|
|
NMTCQdisc *qdisc);
|
2017-11-27 21:16:36 +00:00
|
|
|
gboolean _nm_utils_string_append_tc_tfilter_rest (GString *string,
|
|
|
|
NMTCTfilter *tfilter,
|
|
|
|
GError **error);
|
2017-11-18 16:17:24 +00:00
|
|
|
|
2019-04-19 09:51:42 +00:00
|
|
|
GHashTable *_nm_tc_qdisc_get_attributes (NMTCQdisc *qdisc);
|
|
|
|
GHashTable *_nm_tc_action_get_attributes (NMTCAction *action);
|
|
|
|
|
2017-11-18 16:17:24 +00:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
2018-01-18 09:43:48 +00:00
|
|
|
static inline gboolean
|
|
|
|
_nm_connection_type_is_master (const char *type)
|
|
|
|
{
|
|
|
|
return (NM_IN_STRSET (type,
|
|
|
|
NM_SETTING_BOND_SETTING_NAME,
|
|
|
|
NM_SETTING_BRIDGE_SETTING_NAME,
|
|
|
|
NM_SETTING_TEAM_SETTING_NAME,
|
|
|
|
NM_SETTING_OVS_BRIDGE_SETTING_NAME,
|
|
|
|
NM_SETTING_OVS_PORT_SETTING_NAME));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2018-03-06 15:10:01 +00:00
|
|
|
gboolean _nm_utils_dhcp_duid_valid (const char *duid, GBytes **out_duid_bin);
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
2018-05-25 10:05:24 +00:00
|
|
|
|
|
|
|
gboolean _nm_setting_sriov_sort_vfs (NMSettingSriov *setting);
|
2019-03-16 16:21:35 +00:00
|
|
|
gboolean _nm_setting_bridge_port_sort_vlans (NMSettingBridgePort *setting);
|
2019-03-21 15:49:55 +00:00
|
|
|
gboolean _nm_setting_bridge_sort_vlans (NMSettingBridge *setting);
|
2018-05-25 10:05:24 +00: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 13:26:03 +00:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
2018-12-29 12:01:28 +00:00
|
|
|
typedef struct _NMSockAddrEndpoint NMSockAddrEndpoint;
|
|
|
|
|
|
|
|
NMSockAddrEndpoint *nm_sock_addr_endpoint_new (const char *endpoint);
|
|
|
|
|
|
|
|
NMSockAddrEndpoint *nm_sock_addr_endpoint_ref (NMSockAddrEndpoint *self);
|
|
|
|
void nm_sock_addr_endpoint_unref (NMSockAddrEndpoint *self);
|
|
|
|
|
|
|
|
const char *nm_sock_addr_endpoint_get_endpoint (NMSockAddrEndpoint *self);
|
|
|
|
const char *nm_sock_addr_endpoint_get_host (NMSockAddrEndpoint *self);
|
|
|
|
gint32 nm_sock_addr_endpoint_get_port (NMSockAddrEndpoint *self);
|
|
|
|
|
|
|
|
gboolean nm_sock_addr_endpoint_get_fixed_sockaddr (NMSockAddrEndpoint *self,
|
|
|
|
gpointer sockaddr);
|
|
|
|
|
|
|
|
#define nm_auto_unref_sockaddrendpoint nm_auto(_nm_auto_unref_sockaddrendpoint)
|
2019-03-13 16:05:15 +00:00
|
|
|
NM_AUTO_DEFINE_FCN0 (NMSockAddrEndpoint *, _nm_auto_unref_sockaddrendpoint, nm_sock_addr_endpoint_unref)
|
2018-12-29 12:01:28 +00:00
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2019-01-30 11:36:13 +00:00
|
|
|
NMSockAddrEndpoint *_nm_wireguard_peer_get_endpoint (const NMWireGuardPeer *self);
|
|
|
|
void _nm_wireguard_peer_set_endpoint (NMWireGuardPeer *self,
|
|
|
|
NMSockAddrEndpoint *endpoint);
|
|
|
|
|
|
|
|
void _nm_wireguard_peer_set_public_key_bin (NMWireGuardPeer *self,
|
|
|
|
const guint8 public_key[static NM_WIREGUARD_PUBLIC_KEY_LEN]);
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2019-03-13 08:18:49 +00:00
|
|
|
const NMIPAddr *nm_ip_routing_rule_get_from_bin (const NMIPRoutingRule *self);
|
|
|
|
void nm_ip_routing_rule_set_from_bin (NMIPRoutingRule *self,
|
|
|
|
gconstpointer from,
|
|
|
|
guint8 len);
|
|
|
|
|
|
|
|
const NMIPAddr *nm_ip_routing_rule_get_to_bin (const NMIPRoutingRule *self);
|
|
|
|
void nm_ip_routing_rule_set_to_bin (NMIPRoutingRule *self,
|
|
|
|
gconstpointer to,
|
|
|
|
guint8 len);
|
|
|
|
|
|
|
|
gboolean nm_ip_routing_rule_get_xifname_bin (const NMIPRoutingRule *self,
|
|
|
|
gboolean iif /* or else oif */,
|
|
|
|
char out_xifname[static 16]);
|
|
|
|
|
2019-07-11 16:54:48 +00:00
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_ACTION "action"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_DPORT_END "dport-end"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_DPORT_START "dport-start"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_FAMILY "family"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_FROM "from"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_FROM_LEN "from-len"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_FWMARK "fwmark"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_FWMASK "fwmask"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_IIFNAME "iifname"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_INVERT "invert"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_IPPROTO "ipproto"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_OIFNAME "oifname"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_PRIORITY "priority"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_SPORT_END "sport-end"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_SPORT_START "sport-start"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_SUPPRESS_PREFIXLENGTH "suppress-prefixlength"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_TABLE "table"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_TO "to"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_TOS "tos"
|
|
|
|
#define NM_IP_ROUTING_RULE_ATTR_TO_LEN "to-len"
|
2019-03-13 08:18:49 +00:00
|
|
|
|
|
|
|
NMIPRoutingRule *nm_ip_routing_rule_from_dbus (GVariant *variant,
|
|
|
|
gboolean strict,
|
|
|
|
GError **error);
|
|
|
|
GVariant *nm_ip_routing_rule_to_dbus (const NMIPRoutingRule *self);
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2019-01-21 07:10:14 +00:00
|
|
|
typedef struct _NMSettInfoSetting NMSettInfoSetting;
|
|
|
|
typedef struct _NMSettInfoProperty NMSettInfoProperty;
|
libnm: add generic-data for implementing NMSetting
Add a new way how NMSetting subclasses can be implemented.
Currently, most NMSetting implementations realize all their properties
via GObject properties. That has some downsides:
- the biggest one, is the large effort to add new properties.
Most of them are implemented on a one-by-one basis and they come
with additional API (like native getter functions).
It makes it cumbersome to add more properties.
- for certain properties, it's hard to encode them entirely in
a GObject property. That results in unusable API like
NM_SETTING_IP_CONFIG_ADDRESSES, NM_SETTING_BOND_OPTIONS,
NM_SETTING_USER_DATA. These complex valued properties only
exist, because we currently always need GObject properties
to even implement simple functionality. For example,
nm_setting_duplicate() is entirely implemented via
nm_setting_enumerate_values(), which can only iterate
GObject properies. There is no reason why this is necessary.
Note also how nmcli badly handles bond options and VPN
data. That is only a shortcoming of nmcli and wouldn't
need to be that way. But it happend, because we didn't
keep an open mind that settings might be more than just
accessing GObject properties.
- a major point of NMSetting is to convert to/from a GVariant
from the D-Bus API. As NMSetting needs to squeeze all values
into the static GObject structure, there is no place to
encode invalid or unknown properties. Optimally,
_nm_setting_new_from_dbus() does not loose any information
and a subsequent _nm_setting_to_dbus() can restore the original
variant. That is interesting, because we want that an older
libnm client can talk to a newer NetworkManager version. The
client needs to handle unknown properties gracefully to stay
forward compatible. However, it also should not just drop the
properties on the floor.
Note however, optimally we want that nm_setting_verify() still
can reject settings that have such unknown/invalid values. So,
it should be possible to create an NMSetting instance without
error or loosing information. But verify() should be usable to
identify such settings as invalid.
They also have a few upsides.
- libnm is heavily oriented around GObject. So, we generate
our nm-settings manual based on the gtk-doc. Note however,
how we fail to generate a useful manual for bond.options.
Also note, that there is no reason we couldn't generate
great documentation, even if the properties are not GObject
properties.
- GObject properties do give some functionality like meta-data,
data binding and notification. However, the meta-data is not
sufficient on its own. Note how keyfile and nmcli need extensive
descriptor tables on top of GObject properties, to make this
useful. Note how GObject notifications for NMSetting instances
are usually not useful, aside for data binding like nmtui does.
Also note how NMSettingBond already follows a different paradigm
than using GObject properties. Nowdays, NMSettingBond is considered
a mistake (related bug rh#1032808). Many ideas of NMSettingBond
are flawed, like exposing an inferiour API that reduces everything
to a string hash. Also, it only implemented the options hash inside
NMSettingBond. That means, if we would consider this a good style,
we would have to duplicate this approach in each new setting
implementation.
Add a new style to track data for NMSetting subclasses. It keeps
an internal hash table with all GVariant properies. Also, the
functionality is hooked into NMSetting base class, so all future
subclasses that follow this way, can benefit from this. This approach
has a few similiarties with NMSettingBond, but avoids its flaws.
With this, we also no longer need GObject properties (if we would
also implement generating useful documentation based on non-gkt-doc).
They may be added as accessors if they are useful, but there is no
need for them.
Also, handling the properties as a hash of variants invites for a
more generic approach when handling them. While we still could add
accessors that operate on a one-by-one bases, this leads to a more
generic usage where we apply common functionality to a set of properties.
Also, this is for the moment entirely internal and an implementation
detail. It's entirely up to the NMSetting subclass to make use of this
new style. Also, there are little hooks for the subclass available.
If they turn out to be necessary, they might be added. However, for
the moment, the functionality is restricted to what is useful and
necessary.
2018-07-27 08:05:40 +00:00
|
|
|
|
2019-04-24 14:28:11 +00:00
|
|
|
typedef GVariant *(*NMSettInfoPropToDBusFcn) (const NMSettInfoSetting *sett_info,
|
2019-01-02 14:54:18 +00:00
|
|
|
guint property_idx,
|
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 13:26:03 +00:00
|
|
|
NMConnection *connection,
|
2019-01-02 14:54:18 +00:00
|
|
|
NMSetting *setting,
|
2019-06-27 07:07:16 +00:00
|
|
|
NMConnectionSerializationFlags flags,
|
|
|
|
const NMConnectionSerializationOptions *options);
|
2019-04-24 14:28:11 +00:00
|
|
|
typedef gboolean (*NMSettInfoPropFromDBusFcn) (NMSetting *setting,
|
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 13:26:03 +00:00
|
|
|
GVariant *connection_dict,
|
|
|
|
const char *property,
|
|
|
|
GVariant *value,
|
|
|
|
NMSettingParseFlags parse_flags,
|
|
|
|
GError **error);
|
2019-04-24 14:28:11 +00:00
|
|
|
typedef gboolean (*NMSettInfoPropMissingFromDBusFcn) (NMSetting *setting,
|
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 13:26:03 +00:00
|
|
|
GVariant *connection_dict,
|
|
|
|
const char *property,
|
|
|
|
NMSettingParseFlags parse_flags,
|
|
|
|
GError **error);
|
2019-04-24 14:28:11 +00:00
|
|
|
typedef GVariant *(*NMSettInfoPropGPropToDBusFcn) (const GValue *from);
|
|
|
|
typedef void (*NMSettInfoPropGPropFromDBusFcn) (GVariant *from,
|
2019-04-24 13:51:04 +00:00
|
|
|
GValue *to);
|
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 13:26:03 +00:00
|
|
|
|
2019-09-21 18:35:18 +00:00
|
|
|
const NMSettInfoSetting *nmtst_sett_info_settings (void);
|
|
|
|
|
libnm: refactor NMSettInfoProperty to save memory for simple properties
In total, we register 447 property informations. Out of these,
326 are plain, GObject property based without special implementations.
The NMSettInfoProperty had all function pointers directly embedded,
currently this amounts to 5 function pointers and the "dbus_type" field.
That means, at runtime we have 326 times trivial implementations with
waste 326*6*8 bytes of NULL pointers. We can compact these by moving
them to a separate structure.
Before:
447 * 5 function pointers
447 * "dbus_type" pointer
= 2682 pointers
After:
447 * 1 pointers (for NMSettInfoProperty.property_type)
89 * 6 pointers (for the distinct NMSettInfoPropertType data)
= 981 pointers
So, in total this saves 13608 byes of runtime memory (on 64 bit arch).
The 89 NMSettInfoPropertType instances are the remaining distinct instances.
Note that every NMSettInfoProperty has a "property_type" pointer, but most of them are
shared. That is because the underlying type and the operations are the same.
Also nice is that the NMSettInfoPropertType are actually constant,
static fields and initialized very early.
This change also makes sense form a design point of view. Previously,
NMSettInfoProperty contained both per-property data (the "name") but
also the behavior. Now, the "behavioral" part is moved to a separate
structure (where it is also shared). That means, the parts that are
concerned with the type of the property (the behavior) are separate
from the actual data of the property.
2019-09-22 06:53:06 +00:00
|
|
|
typedef struct {
|
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 13:26:03 +00:00
|
|
|
const GVariantType *dbus_type;
|
|
|
|
|
2019-04-24 14:28:11 +00:00
|
|
|
NMSettInfoPropToDBusFcn to_dbus_fcn;
|
|
|
|
NMSettInfoPropFromDBusFcn from_dbus_fcn;
|
|
|
|
NMSettInfoPropMissingFromDBusFcn missing_from_dbus_fcn;
|
|
|
|
|
|
|
|
/* Simpler variants of @to_dbus_fcn/@from_dbus_fcn that operate solely
|
|
|
|
* on the GValue value of the GObject property. */
|
|
|
|
NMSettInfoPropGPropToDBusFcn gprop_to_dbus_fcn;
|
|
|
|
NMSettInfoPropGPropFromDBusFcn gprop_from_dbus_fcn;
|
libnm: refactor NMSettInfoProperty to save memory for simple properties
In total, we register 447 property informations. Out of these,
326 are plain, GObject property based without special implementations.
The NMSettInfoProperty had all function pointers directly embedded,
currently this amounts to 5 function pointers and the "dbus_type" field.
That means, at runtime we have 326 times trivial implementations with
waste 326*6*8 bytes of NULL pointers. We can compact these by moving
them to a separate structure.
Before:
447 * 5 function pointers
447 * "dbus_type" pointer
= 2682 pointers
After:
447 * 1 pointers (for NMSettInfoProperty.property_type)
89 * 6 pointers (for the distinct NMSettInfoPropertType data)
= 981 pointers
So, in total this saves 13608 byes of runtime memory (on 64 bit arch).
The 89 NMSettInfoPropertType instances are the remaining distinct instances.
Note that every NMSettInfoProperty has a "property_type" pointer, but most of them are
shared. That is because the underlying type and the operations are the same.
Also nice is that the NMSettInfoPropertType are actually constant,
static fields and initialized very early.
This change also makes sense form a design point of view. Previously,
NMSettInfoProperty contained both per-property data (the "name") but
also the behavior. Now, the "behavioral" part is moved to a separate
structure (where it is also shared). That means, the parts that are
concerned with the type of the property (the behavior) are separate
from the actual data of the property.
2019-09-22 06:53:06 +00:00
|
|
|
} NMSettInfoPropertType;
|
|
|
|
|
|
|
|
struct _NMSettInfoProperty {
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
GParamSpec *param_spec;
|
|
|
|
|
|
|
|
const NMSettInfoPropertType *property_type;
|
2019-01-21 07:10:14 +00: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 13:26:03 +00:00
|
|
|
|
|
|
|
typedef struct {
|
libnm: add generic-data for implementing NMSetting
Add a new way how NMSetting subclasses can be implemented.
Currently, most NMSetting implementations realize all their properties
via GObject properties. That has some downsides:
- the biggest one, is the large effort to add new properties.
Most of them are implemented on a one-by-one basis and they come
with additional API (like native getter functions).
It makes it cumbersome to add more properties.
- for certain properties, it's hard to encode them entirely in
a GObject property. That results in unusable API like
NM_SETTING_IP_CONFIG_ADDRESSES, NM_SETTING_BOND_OPTIONS,
NM_SETTING_USER_DATA. These complex valued properties only
exist, because we currently always need GObject properties
to even implement simple functionality. For example,
nm_setting_duplicate() is entirely implemented via
nm_setting_enumerate_values(), which can only iterate
GObject properies. There is no reason why this is necessary.
Note also how nmcli badly handles bond options and VPN
data. That is only a shortcoming of nmcli and wouldn't
need to be that way. But it happend, because we didn't
keep an open mind that settings might be more than just
accessing GObject properties.
- a major point of NMSetting is to convert to/from a GVariant
from the D-Bus API. As NMSetting needs to squeeze all values
into the static GObject structure, there is no place to
encode invalid or unknown properties. Optimally,
_nm_setting_new_from_dbus() does not loose any information
and a subsequent _nm_setting_to_dbus() can restore the original
variant. That is interesting, because we want that an older
libnm client can talk to a newer NetworkManager version. The
client needs to handle unknown properties gracefully to stay
forward compatible. However, it also should not just drop the
properties on the floor.
Note however, optimally we want that nm_setting_verify() still
can reject settings that have such unknown/invalid values. So,
it should be possible to create an NMSetting instance without
error or loosing information. But verify() should be usable to
identify such settings as invalid.
They also have a few upsides.
- libnm is heavily oriented around GObject. So, we generate
our nm-settings manual based on the gtk-doc. Note however,
how we fail to generate a useful manual for bond.options.
Also note, that there is no reason we couldn't generate
great documentation, even if the properties are not GObject
properties.
- GObject properties do give some functionality like meta-data,
data binding and notification. However, the meta-data is not
sufficient on its own. Note how keyfile and nmcli need extensive
descriptor tables on top of GObject properties, to make this
useful. Note how GObject notifications for NMSetting instances
are usually not useful, aside for data binding like nmtui does.
Also note how NMSettingBond already follows a different paradigm
than using GObject properties. Nowdays, NMSettingBond is considered
a mistake (related bug rh#1032808). Many ideas of NMSettingBond
are flawed, like exposing an inferiour API that reduces everything
to a string hash. Also, it only implemented the options hash inside
NMSettingBond. That means, if we would consider this a good style,
we would have to duplicate this approach in each new setting
implementation.
Add a new style to track data for NMSetting subclasses. It keeps
an internal hash table with all GVariant properies. Also, the
functionality is hooked into NMSetting base class, so all future
subclasses that follow this way, can benefit from this. This approach
has a few similiarties with NMSettingBond, but avoids its flaws.
With this, we also no longer need GObject properties (if we would
also implement generating useful documentation based on non-gkt-doc).
They may be added as accessors if they are useful, but there is no
need for them.
Also, handling the properties as a hash of variants invites for a
more generic approach when handling them. While we still could add
accessors that operate on a one-by-one bases, this leads to a more
generic usage where we apply common functionality to a set of properties.
Also, this is for the moment entirely internal and an implementation
detail. It's entirely up to the NMSetting subclass to make use of this
new style. Also, there are little hooks for the subclass available.
If they turn out to be necessary, they might be added. However, for
the moment, the functionality is restricted to what is useful and
necessary.
2018-07-27 08:05:40 +00:00
|
|
|
const GVariantType *(*get_variant_type) (const struct _NMSettInfoSetting *sett_info,
|
|
|
|
const char *name,
|
|
|
|
GError **error);
|
|
|
|
} NMSettInfoSettGendata;
|
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 13:26:03 +00:00
|
|
|
|
|
|
|
typedef struct {
|
libnm: add generic-data for implementing NMSetting
Add a new way how NMSetting subclasses can be implemented.
Currently, most NMSetting implementations realize all their properties
via GObject properties. That has some downsides:
- the biggest one, is the large effort to add new properties.
Most of them are implemented on a one-by-one basis and they come
with additional API (like native getter functions).
It makes it cumbersome to add more properties.
- for certain properties, it's hard to encode them entirely in
a GObject property. That results in unusable API like
NM_SETTING_IP_CONFIG_ADDRESSES, NM_SETTING_BOND_OPTIONS,
NM_SETTING_USER_DATA. These complex valued properties only
exist, because we currently always need GObject properties
to even implement simple functionality. For example,
nm_setting_duplicate() is entirely implemented via
nm_setting_enumerate_values(), which can only iterate
GObject properies. There is no reason why this is necessary.
Note also how nmcli badly handles bond options and VPN
data. That is only a shortcoming of nmcli and wouldn't
need to be that way. But it happend, because we didn't
keep an open mind that settings might be more than just
accessing GObject properties.
- a major point of NMSetting is to convert to/from a GVariant
from the D-Bus API. As NMSetting needs to squeeze all values
into the static GObject structure, there is no place to
encode invalid or unknown properties. Optimally,
_nm_setting_new_from_dbus() does not loose any information
and a subsequent _nm_setting_to_dbus() can restore the original
variant. That is interesting, because we want that an older
libnm client can talk to a newer NetworkManager version. The
client needs to handle unknown properties gracefully to stay
forward compatible. However, it also should not just drop the
properties on the floor.
Note however, optimally we want that nm_setting_verify() still
can reject settings that have such unknown/invalid values. So,
it should be possible to create an NMSetting instance without
error or loosing information. But verify() should be usable to
identify such settings as invalid.
They also have a few upsides.
- libnm is heavily oriented around GObject. So, we generate
our nm-settings manual based on the gtk-doc. Note however,
how we fail to generate a useful manual for bond.options.
Also note, that there is no reason we couldn't generate
great documentation, even if the properties are not GObject
properties.
- GObject properties do give some functionality like meta-data,
data binding and notification. However, the meta-data is not
sufficient on its own. Note how keyfile and nmcli need extensive
descriptor tables on top of GObject properties, to make this
useful. Note how GObject notifications for NMSetting instances
are usually not useful, aside for data binding like nmtui does.
Also note how NMSettingBond already follows a different paradigm
than using GObject properties. Nowdays, NMSettingBond is considered
a mistake (related bug rh#1032808). Many ideas of NMSettingBond
are flawed, like exposing an inferiour API that reduces everything
to a string hash. Also, it only implemented the options hash inside
NMSettingBond. That means, if we would consider this a good style,
we would have to duplicate this approach in each new setting
implementation.
Add a new style to track data for NMSetting subclasses. It keeps
an internal hash table with all GVariant properies. Also, the
functionality is hooked into NMSetting base class, so all future
subclasses that follow this way, can benefit from this. This approach
has a few similiarties with NMSettingBond, but avoids its flaws.
With this, we also no longer need GObject properties (if we would
also implement generating useful documentation based on non-gkt-doc).
They may be added as accessors if they are useful, but there is no
need for them.
Also, handling the properties as a hash of variants invites for a
more generic approach when handling them. While we still could add
accessors that operate on a one-by-one bases, this leads to a more
generic usage where we apply common functionality to a set of properties.
Also, this is for the moment entirely internal and an implementation
detail. It's entirely up to the NMSetting subclass to make use of this
new style. Also, there are little hooks for the subclass available.
If they turn out to be necessary, they might be added. However, for
the moment, the functionality is restricted to what is useful and
necessary.
2018-07-27 08:05:40 +00:00
|
|
|
/* if set, then this setting class has no own fields. Instead, its
|
|
|
|
* data is entirely based on gendata. Meaning: it tracks all data
|
|
|
|
* as native GVariants.
|
|
|
|
* It might have some GObject properties, but these are merely accessors
|
|
|
|
* to the underlying gendata.
|
|
|
|
*
|
|
|
|
* Note, that at the moment there are few hooks, to customize the behavior
|
|
|
|
* of the setting further. They are currently unneeded. This is desired,
|
|
|
|
* but could be added when there is a good reason.
|
|
|
|
*
|
|
|
|
* However, a few hooks there are... see NMSettInfoSettGendata. */
|
|
|
|
const NMSettInfoSettGendata *gendata_info;
|
|
|
|
} NMSettInfoSettDetail;
|
|
|
|
|
|
|
|
struct _NMSettInfoSetting {
|
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 13:26:03 +00:00
|
|
|
NMSettingClass *setting_class;
|
2019-01-04 14:37:39 +00:00
|
|
|
|
|
|
|
/* the properties, sorted by property name. */
|
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 13:26:03 +00:00
|
|
|
const NMSettInfoProperty *property_infos;
|
2019-01-04 14:37:39 +00:00
|
|
|
|
|
|
|
/* the @property_infos list is sorted by property name. For some uses we need
|
|
|
|
* a different sort order. If @property_infos_sorted is set, this is the order
|
|
|
|
* instead. It is used for:
|
|
|
|
*
|
|
|
|
* - nm_setting_enumerate_values()
|
|
|
|
* - keyfile writer adding keys to the group.
|
|
|
|
*
|
|
|
|
* Note that currently only NMSettingConnection implements here a sort order
|
|
|
|
* that differs from alphabetical sort of the property names.
|
|
|
|
*/
|
|
|
|
const NMSettInfoProperty *const*property_infos_sorted;
|
|
|
|
|
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 13:26:03 +00:00
|
|
|
guint property_infos_len;
|
|
|
|
NMSettInfoSettDetail detail;
|
libnm: add generic-data for implementing NMSetting
Add a new way how NMSetting subclasses can be implemented.
Currently, most NMSetting implementations realize all their properties
via GObject properties. That has some downsides:
- the biggest one, is the large effort to add new properties.
Most of them are implemented on a one-by-one basis and they come
with additional API (like native getter functions).
It makes it cumbersome to add more properties.
- for certain properties, it's hard to encode them entirely in
a GObject property. That results in unusable API like
NM_SETTING_IP_CONFIG_ADDRESSES, NM_SETTING_BOND_OPTIONS,
NM_SETTING_USER_DATA. These complex valued properties only
exist, because we currently always need GObject properties
to even implement simple functionality. For example,
nm_setting_duplicate() is entirely implemented via
nm_setting_enumerate_values(), which can only iterate
GObject properies. There is no reason why this is necessary.
Note also how nmcli badly handles bond options and VPN
data. That is only a shortcoming of nmcli and wouldn't
need to be that way. But it happend, because we didn't
keep an open mind that settings might be more than just
accessing GObject properties.
- a major point of NMSetting is to convert to/from a GVariant
from the D-Bus API. As NMSetting needs to squeeze all values
into the static GObject structure, there is no place to
encode invalid or unknown properties. Optimally,
_nm_setting_new_from_dbus() does not loose any information
and a subsequent _nm_setting_to_dbus() can restore the original
variant. That is interesting, because we want that an older
libnm client can talk to a newer NetworkManager version. The
client needs to handle unknown properties gracefully to stay
forward compatible. However, it also should not just drop the
properties on the floor.
Note however, optimally we want that nm_setting_verify() still
can reject settings that have such unknown/invalid values. So,
it should be possible to create an NMSetting instance without
error or loosing information. But verify() should be usable to
identify such settings as invalid.
They also have a few upsides.
- libnm is heavily oriented around GObject. So, we generate
our nm-settings manual based on the gtk-doc. Note however,
how we fail to generate a useful manual for bond.options.
Also note, that there is no reason we couldn't generate
great documentation, even if the properties are not GObject
properties.
- GObject properties do give some functionality like meta-data,
data binding and notification. However, the meta-data is not
sufficient on its own. Note how keyfile and nmcli need extensive
descriptor tables on top of GObject properties, to make this
useful. Note how GObject notifications for NMSetting instances
are usually not useful, aside for data binding like nmtui does.
Also note how NMSettingBond already follows a different paradigm
than using GObject properties. Nowdays, NMSettingBond is considered
a mistake (related bug rh#1032808). Many ideas of NMSettingBond
are flawed, like exposing an inferiour API that reduces everything
to a string hash. Also, it only implemented the options hash inside
NMSettingBond. That means, if we would consider this a good style,
we would have to duplicate this approach in each new setting
implementation.
Add a new style to track data for NMSetting subclasses. It keeps
an internal hash table with all GVariant properies. Also, the
functionality is hooked into NMSetting base class, so all future
subclasses that follow this way, can benefit from this. This approach
has a few similiarties with NMSettingBond, but avoids its flaws.
With this, we also no longer need GObject properties (if we would
also implement generating useful documentation based on non-gkt-doc).
They may be added as accessors if they are useful, but there is no
need for them.
Also, handling the properties as a hash of variants invites for a
more generic approach when handling them. While we still could add
accessors that operate on a one-by-one bases, this leads to a more
generic usage where we apply common functionality to a set of properties.
Also, this is for the moment entirely internal and an implementation
detail. It's entirely up to the NMSetting subclass to make use of this
new style. Also, there are little hooks for the subclass available.
If they turn out to be necessary, they might be added. However, for
the moment, the functionality is restricted to what is useful and
necessary.
2018-07-27 08:05:40 +00: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 13:26:03 +00:00
|
|
|
|
2019-01-04 14:37:39 +00:00
|
|
|
static inline const NMSettInfoProperty *
|
|
|
|
_nm_sett_info_property_info_get_sorted (const NMSettInfoSetting *sett_info,
|
|
|
|
guint idx)
|
|
|
|
{
|
|
|
|
nm_assert (sett_info);
|
|
|
|
nm_assert (idx < sett_info->property_infos_len);
|
|
|
|
nm_assert (!sett_info->property_infos_sorted || sett_info->property_infos_sorted[idx]);
|
|
|
|
|
|
|
|
return sett_info->property_infos_sorted
|
|
|
|
? sett_info->property_infos_sorted[idx]
|
|
|
|
: &sett_info->property_infos[idx];
|
|
|
|
}
|
|
|
|
|
2019-01-10 18:50:14 +00:00
|
|
|
const NMSettInfoProperty *_nm_sett_info_setting_get_property_info (const NMSettInfoSetting *sett_info,
|
|
|
|
const char *property_name);
|
|
|
|
|
2019-01-10 18:44:30 +00:00
|
|
|
const NMSettInfoSetting *_nm_setting_class_get_sett_info (NMSettingClass *setting_class);
|
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 13:26:03 +00:00
|
|
|
|
2019-01-10 18:50:14 +00:00
|
|
|
static inline const NMSettInfoProperty *
|
|
|
|
_nm_setting_class_get_property_info (NMSettingClass *setting_class,
|
|
|
|
const char *property_name)
|
|
|
|
{
|
|
|
|
return _nm_sett_info_setting_get_property_info (_nm_setting_class_get_sett_info (setting_class),
|
|
|
|
property_name);
|
|
|
|
}
|
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 13:26:03 +00:00
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2019-04-25 08:17:47 +00:00
|
|
|
gboolean _nm_setting_compare (NMConnection *con_a,
|
|
|
|
NMSetting *set_a,
|
|
|
|
NMConnection *con_b,
|
|
|
|
NMSetting *set_b,
|
|
|
|
NMSettingCompareFlags flags);
|
|
|
|
|
|
|
|
gboolean _nm_setting_diff (NMConnection *con_a,
|
|
|
|
NMSetting *set_a,
|
|
|
|
NMConnection *con_b,
|
|
|
|
NMSetting *set_b,
|
|
|
|
NMSettingCompareFlags flags,
|
|
|
|
gboolean invert_results,
|
|
|
|
GHashTable **results);
|
|
|
|
|
ifcfg-rh: don't use 802-1x certifcate setter functions
The certificate setter function like nm_setting_802_1x_set_ca_cert()
actually load the file from disk, and validate whether it is a valid
certificate. That is very wrong to do.
For one, the certificates are external files, which are not embedded
into the NMConnection. That means, strongly validating the files while
loading the ifcfg files, is wrong because:
- if validation fails, loading the file fails in its entirety with
a warning in the log. That is not helpful to the user, who now
can no longer use nmcli to fix the path of the certificate (because
the profile failed to load in the first place).
- even if the certificate is valid at load-time, there is no guarantee
that it is valid later on, when we actually try to use the file. What
good does such a validation do? nm_setting_802_1x_set_ca_cert() might
make sense during nmcli_connection_modify(). At the moment when we
create or update the profile, we do want to validate the input and
be helpful to the user. Validating the file later on, when reloading
the profile from disk seems undesirable.
- note how keyfile also does not perform such validations (for good
reasons, I presume).
Also, there is so much wrong with how ifcfg reader handles EAP files.
There is a lot of duplication, and trying to be too smart. I find it
wrong how the "eap_readers" are nested. E.g. both eap_peap_reader() and
"tls" method call to eap_tls_reader(), making it look like that
NMSetting8021x can handle multiple EAP profiles separately. But it cannot. The
802-1x profile is a flat set of properties like ca-cert and others. All
EAP methods share these properties, so having this complex parsing
is not only complicated, but also wrong. The reader should simply parse
the shell variables, and let NMSetting8021x::verify() handle validation
of the settings. Anyway, the patch does not address that.
Also, the setting of the likes of NM_SETTING_802_1X_CLIENT_CERT_PASSWORD was
awkwardly only done when
privkey_format != NM_SETTING_802_1X_CK_FORMAT_PKCS12
&& scheme == NM_SETTING_802_1X_CK_SCHEME_PKCS11
It is too smart. Just read it from file, if it contains invalid data, let
verify() reject it. That is only partly addressed.
Also note, how writer never actually writes the likes of
IEEE_8021X_CLIENT_CERT_PASSWORD. That is another bug and not fixed
either.
2018-09-03 10:24:27 +00:00
|
|
|
NMSetting8021xCKScheme _nm_setting_802_1x_cert_get_scheme (GBytes *bytes, GError **error);
|
|
|
|
|
|
|
|
GBytes *_nm_setting_802_1x_cert_value_to_bytes (NMSetting8021xCKScheme scheme,
|
|
|
|
const guint8 *val_bin,
|
|
|
|
gssize val_len,
|
|
|
|
GError **error);
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2019-06-15 09:18:46 +00:00
|
|
|
static inline gboolean
|
|
|
|
_nm_connection_serialize_secrets (NMConnectionSerializationFlags flags,
|
|
|
|
NMSettingSecretFlags secret_flags)
|
|
|
|
{
|
|
|
|
if (NM_FLAGS_HAS (flags, NM_CONNECTION_SERIALIZE_NO_SECRETS))
|
|
|
|
return FALSE;
|
|
|
|
if ( NM_FLAGS_HAS (flags, NM_CONNECTION_SERIALIZE_WITH_SECRETS_AGENT_OWNED)
|
|
|
|
&& !NM_FLAGS_HAS (secret_flags, NM_SETTING_SECRET_FLAG_AGENT_OWNED))
|
|
|
|
return FALSE;
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2019-06-15 09:26:14 +00:00
|
|
|
void _nm_connection_clear_secrets_by_secret_flags (NMConnection *self,
|
|
|
|
NMSettingSecretFlags filter_flags);
|
|
|
|
|
2019-01-31 07:53:32 +00:00
|
|
|
GVariant *_nm_connection_for_each_secret (NMConnection *self,
|
|
|
|
GVariant *secrets,
|
|
|
|
gboolean remove_non_secrets,
|
2019-01-31 08:38:58 +00:00
|
|
|
_NMConnectionForEachSecretFunc callback,
|
2019-01-31 07:53:32 +00:00
|
|
|
gpointer callback_data);
|
|
|
|
|
|
|
|
typedef gboolean (*NMConnectionFindSecretFunc) (NMSettingSecretFlags flags,
|
|
|
|
gpointer user_data);
|
|
|
|
|
|
|
|
gboolean _nm_connection_find_secret (NMConnection *self,
|
|
|
|
GVariant *secrets,
|
|
|
|
NMConnectionFindSecretFunc callback,
|
|
|
|
gpointer callback_data);
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2019-03-02 16:10:25 +00:00
|
|
|
gboolean nm_utils_base64secret_normalize (const char *base64_key,
|
|
|
|
gsize required_key_len,
|
|
|
|
char **out_base64_key_norm);
|
2018-12-27 15:48:30 +00:00
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
2019-03-19 14:35:28 +00:00
|
|
|
void _nm_bridge_vlan_str_append_rest (const NMBridgeVlan *vlan,
|
|
|
|
GString *string,
|
|
|
|
gboolean leading_space);
|
|
|
|
|
2019-05-26 21:39:25 +00:00
|
|
|
gboolean nm_utils_connection_is_adhoc_wpa (NMConnection *connection);
|
|
|
|
|
2019-02-20 12:23:26 +00:00
|
|
|
const char *nm_utils_wifi_freq_to_band (guint32 freq);
|
|
|
|
|
2019-10-15 08:27:10 +00:00
|
|
|
gboolean _nm_utils_iaid_verify (const char *str, gint64 *out_value);
|
|
|
|
|
2019-07-09 09:26:02 +00:00
|
|
|
gboolean _nm_utils_validate_dhcp_hostname_flags (NMDhcpHostnameFlags flags,
|
|
|
|
int addr_family,
|
|
|
|
GError **error);
|
|
|
|
|
2019-11-27 12:13:48 +00:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
gboolean _nmtst_variant_attribute_spec_assert_sorted (const NMVariantAttributeSpec *const*array,
|
|
|
|
gsize len);
|
|
|
|
|
|
|
|
const NMVariantAttributeSpec *_nm_variant_attribute_spec_find_binary_search (const NMVariantAttributeSpec *const*array,
|
|
|
|
gsize len,
|
|
|
|
const char *name);
|
2014-07-27 18:35:17 +00:00
|
|
|
#endif
|