For now only add the core settings, no peers' data.
To support peers and the allowed-ips of the peers is more complicated
and will be done later. It's more complicated because these are nested
lists (allowed-ips) inside a list (peers). That is quite unusual and to
conveniently support that in D-Bus API, in keyfile format, in libnm,
and nmcli, is a effort.
Also, it's further complicated by the fact that each peer has a secret (the
preshared-key). Thus we probably need secret flags for each peer, which
is a novelty as well (until now we require a fixed set of secrets per
profile that is well known).
We already need to special handle regular settings (with secrets as
GObject properties) and VPN secrets.
Next, we will also need to special handle WireGuard peers, which can
have secrets too.
Move the code to a virtual function, so that "nm-connection.c" and
"nm-setting.c" does not have explicit per-setting knowledge.
- use cleanup attribute to free memory
- return floating reference from _nm_connection_for_each_secret().
It's more idiomatic that a function that constructs a variant and
returns it, returns a floating variant.
_nm_connection_for_each_secret() (formerly for_each_secret()) and
_nm_connection_find_secret() (formerly find_secret()) operate on a
GVariant of secrets. For that, they implement certain assumptions
of how to handle secrets. For example, it must special-case VPN settings,
because there is no generic abstraction to handle regular secret and VPN
secrets the same.
Such special casing should only be done in libnm-core, at one place.
Move the code to libnm-core as internal API.
There are two callers that are concerned with disconnecting/releasing a
setting:
- _setting_release_hfr() (formerly _setting_release())
- _nm_connection_add_setting() for the @s_old setting
Compared to one caller that connects/adds a setting (_nm_connection_add_setting()).
Refactor the two callers to use the same helper function
(_setting_release()) so that the implementation of how to release a
setting is at one place.
This patch was originally done when adding another signal to NMSetting.
That did not happen (yet), but the refactoring still makes sense.
Order the code in our common way. No other changes.
- ensure to include the main header first (directly after
"nm-default.h").
- reorder function definitions: get_property(), set_property(),
*_init(), *_new(), finalize(), *_class_init().
We should no longer use nm_connection_for_each_setting_value() and
nm_setting_for_each_value(). It's fundamentally broken as it does
not work with properties that are not backed by a GObject property
and it cannot be fixed because it is public API.
Add an internal function _nm_connection_aggregate() to replace it.
Compare the implementation of the aggregation functionality inside
libnm with the previous two checks for secret-flags that it replaces:
- previous approach broke abstraction and require detailed knowledge of
secret flags. Meaning, they must special case NMSettingVpn and
GObject-property based secrets.
If we implement a new way for implementing secrets (like we will need
for WireGuard), then this the new way should only affect libnm-core,
not require changes elsewhere.
- it's very inefficient to itereate over all settings. It involves
cloning and sorting the list of settings, and retrieve and clone all
GObject properties. Only to look at secret properties alone.
_nm_connection_aggregate() is supposed to be more flexible then just
the two new aggregate types that perform a "find-any" search. The
@arg argument and boolean return value can suffice to implement
different aggregation types in the future.
Also fixes the check of NMAgentManager for secret flags for VPNs
(NM_CONNECTION_AGGREGATE_ANY_SYSTEM_SECRET_FLAGS). A secret for VPNs
is a property that either has a secret or a secret-flag. The previous
implementation would only look at present secrets and
check their flags. It wouldn't check secret-flags that are
NM_SETTING_SECRET_FLAG_NONE, but have no secret.
NMConnection keeps a list (hash table) of all settings.
There are two lookup methods to find a setting in a connection:
- nm_connection_get_setting() by GType
- nm_connection_get_setting_by_name() by name
Note, that nm_connection_get_setting_by_name() first converts the
name to a GType, and then looks up the setting by GType.
But then, nm_connection_get_setting() would again convert the GType to
the type name, and hash the name. That is pointless, just index by GType
directly.
Maybe, using a hash table is anyway overkill because commonly there are
only a handful of settings in a connection. Regardless of that, change
the hashing.
Note that NMSettingEthtool and NMSettingMatch don't have such
functions either.
We have API
nm_connection_get_setting (NMConnection *, GType)
nm_connection_get_setting_by_name (NMConnection *, const char *)
which can be used generically, meaning: the requested setting type
is an argument to the function. That is generally more useful and
flexible.
Don't add API which duplicates existing functionality and is (arguably)
inferiour. Drop it now. This is an ABI/API break for the current development
cycle where the 1.14.0 API is still unstable. Indeed it's already after
1.14-rc1, which is ugly. But it's also unlikely that somebody already uses
this API/ABI and is badly impacted by this change.
Note that nm_connection_get_setting() and nm_connection_get_setting_by_name()
are slightly inconvenient in C still, because they usually require a cast.
We should fix that by changing the return type to "void *". Such
a change may be possibly any time without breaking API/ABI (almost, it'd
be an API change when taking a function pointer without casting).
(cherry picked from commit a10156f516)
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
Utilize _nm_setting_to_dbus() to serialize the setting. The main reason
is that this way we can also print the more complicated values
g_strdup_value_contents() can't grok, e.g. the GArrays and GHashTables.
Some effort was spent on tidying up the results in a manner it was done
previously, instead of reducing this to a plain g_variant_print(). It
looks good that way:
Before:
vpn
service-type : "org.freedesktop.NetworkManager.VPN.Novpn" (s)
user-name : NULL (sd)
persistent : FALSE (sd)
data : ((GHashTable*) 0xc61060) (s)
secrets : ((GHashTable*) 0xdda640) (s)
timeout : 0 (sd)
After:
vpn
service-type : 'org.freedesktop.NetworkManager.VPN.Novpn'
data : {'gateway': 'novpn.example.com', 'username': 'hello'}
secrets : {'password': 'world'}
Note that no effort was spent on printing the defaults. There are
multiple ways that could be achieved, but I'm not sure it would be all
that necessary given this is really just a quick'n'dirty debugging facilty.
Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*.
This will be used to determine, whether the profile is fundamentally
incompatible with the device, or whether just some other properties
mismatch. That information will be importand during a plain `nmcli
connection up`, where NetworkManager searches all devices for a device
to activate. If no device is found (and multiple errors happened),
we want to show the error that is most likely relevant for the user.
Also note, how NMDevice's check_connection_compatible() uses the new
class field "device_class->connection_type_check_compatible" to simplify
checks for compatible profiles.
The error reason is still unused.
gretap and ip6gretap ip-tunnel interfaces encapsulate L2 packets over
IP. Allow adding a wired setting for such connections so that users
can change the interface MAC.
For some device types it's not going to be sufficient to tell whether
they carry "IP".
In particular, there's no way to carry legacy IP over the tiny MTU
datagrams of IEEE 802.15.4 WPAN links while an IPv6 transport exist
in form of 6LoWPAN.
When link auto-negotiation is enabled, by default the network device
advertises all the supported speed and duplex modes in order to
negotiate the fastest link speed with the remote endpoint.
It is possible anyway to configure the device to just advertise and
accept a subset of supported modes.
This could be useful to properly enforce gigabit speeds on Ethernet:
as stated in IEEE 802.3 specification, auto-negotiation is mandatory
for 1000Base-T and 10GBase-T standards.
Allow specific values to 802-3-ethernet.speed and 802-3-ethernet.duplex
properties also when 802-3-ethernet.auto-negotiate=yes: this will
result in link auto-negotiation advertising the specified speed/duplex
mode as the only one available.
Coccinelle:
@@
expression a, b;
@@
-a ? a : b
+a ?: b
Applied with:
spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .
With some manual adjustments on spots that Cocci didn't catch for
reasons unknown.
Thanks to the marvelous effort of the GNU compiler developer we can now
spare a couple of bits that could be used for more important things,
like this commit message. Standards commitees yet have to catch up.
The secrets are transient -- when they are loaded into the connections and
subsequently cleared the connection itself doesn't change. The Update
signal is to be emmited only on explicit Update()/Update2() or
ClearSecrets() which is already the case.
Apart from Update being wrong, it has the ill effect of causing libnm to
drop secrets from the cached connection.
We commonly only allow tabs at the beginning of a line, not
afterwards. The reason for this style is so that the code
looks formated right with tabstop=4 and tabstop=8.
yes, this is not an issue in practice. Variadic arguments are always
propagated to at least int/unsigned type. And kernel and glib both require
sizeof(guint32) <= sizeof(guint). Hence, this was safe on any supported
architecture. Still, let's be explicit about the types.
We also do this for libnm and libnm-core, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.
Normalizing can be complicated, as settings depend on each other and possibly
conflict.
That is, because verify() must exactly anticipate whether normalization will
succeed and how the result will look like. That is because we only want to
modify the connection, if we are sure that the result will verify.
Hence, verify() and normalize() are strongly related. The implementation
should not be spread out between NMSettingOvsInterface:verify(),
NMSettingOvsPatch:verify() and _normalize_ovs_interface_type().
Also, add some unit-tests.
There is no API to get all settings. You can only ask for
settings explicitly, but that requires you to probe for them
and know which ones may exist.
The alternative API might be nm_connection_for_each_setting_value(),
but that only iterates over settings' properties. If a setting has no
properties, it is ignored.
Previously, nm_setting_diff() would return !(*results), that means,
if the caller passed in a hash table (empty or not), the return value
would always be FALSE, indicating a difference.
That is not documented, and makes no sense.
The return value, should solely indicate whether some difference was
found. The only convenience is, if nm_setting_diff() created a hash
table internally and no difference was found, it would destroy
it again, without returning it to the caller.
When the user sets a GSM or CDMA setting along with a Bluetooth setting
we know we're dealing with a DUN profile. No need to ask.
[thaller@redhat.com: verify() and normalize() must strongly agree whether a
connection is normalizable, and now to do it. That is, after verify()
determines the connection is normalizable, normalize() must fix it as
anticipated.
The reason is, we only want to modify the connection, if we are able
to create a valid result. Hence, after normalize() it *must* verify().
Try to simplify that by moving the logic of fixing the bt-type to a
common place _nm_connection_detect_bluetooth_type().]
Co-Authored-By: Thomas Haller <thaller@redhat.com>
Functions call each other, like
nm_connection_get_id()
nm_connection_get_setting_connection()
nm_connection_get_setting()
Along the way, each function asserts that the input argument
is of type NMConnection via
g_return_val_if_fail (NM_IS_CONNECTION (connection), NULL);
Avoid such duplicate assertions when we already verifyied the
input argument.
For example, in case of nm_connection_get_id(), don't check just call
nm_connection_get_setting_connection() right away. It already
asserts.
The downside is, that the assertion no longer fails in the function
that immediately called it. But these are assertions after all.
Branch f9b1bc16e9 added bluetooth NAP
support. A NAP connection is of connection.type "bluetooth", but it
also has a "bridge" setting. Also, it is primarily handled by NMDeviceBridge
and NMBridgeDeviceFactory (with help from NMBluezManager).
However, don't let nm_connection_get_connection_type() and
nm_connnection_is_type() lie about what the connection.type is.
The type is "bluetooth" for most purposes -- at least, as far as
the client is concerned (and the public API of libnm). This restores
previous API behavior, where nm_connection_get_connection_type()
and nm_connection_is_type() would be simple accessors to the
"connection.type" property.
Only a few places care about the bridge aspect, and those places need special
treatment. For example NMDeviceBridge needs to be fully aware that it can
handle bluetooth NAP connection. That is nothing new: if you handle a
connection of any type, you must know which fields matter and what they
mean. It's not enough that nm_connection_get_connection_type() for bluetooth
NAP connectins is claiming to be a bridge.
Counter examples, where the original behavior is right:
src/nm-manager.c- g_set_error (error,
src/nm-manager.c- NM_MANAGER_ERROR,
src/nm-manager.c- NM_MANAGER_ERROR_FAILED,
src/nm-manager.c- "NetworkManager plugin for '%s' unavailable",
src/nm-manager.c: nm_connection_get_connection_type (connection));
the correct message is: "no bluetooth plugin available", not "bridge".
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: if ( ( nm_connection_is_type (connection, NM_SETTING_WIRED_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: && !nm_connection_get_setting_pppoe (connection))
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_VLAN_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_WIRELESS_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_INFINIBAND_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_BOND_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_TEAM_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_BRIDGE_SETTING_NAME))
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c- return TRUE;
the correct behavior is for ifcfg-rh plugin to reject bluetooth NAP
connections, not proceed and store it.
Functions should behave gracefully with connections that don't verify.
Especially, as _normalize_connection_type() calls
_nm_connection_find_base_type_setting() precisely with an unknown
connection.type.
Using plain numbers make it cumbersome to grep for
setting types by priority.
The only downside is, that with the enum values it
is no longer obvious which value has higher or lower
priority.
Also, introduce NM_SETTING_PRIORITY_INVALID. This is what
_nm_setting_type_get_base_type_priority() returns. For the moment
it still has the same numerical value 0 as before. Later, that
shall be distinct from NM_SETTING_PRIORITY_CONNECTION.
In an ideal world, we should not validate connections containing
options not valid for the current bond mode. However adding such
restriction now means that during an upgrade to the new NM version
some connections that were valid before become invalid, possibly
disrupting connectivity.
Instead, consider invalid options as a normalizable error and remove
them during normalization.
Converting the setting to a "canonical" form without invalid options
is important for the connection matching logic, where such invalid
options can cause false mismatches.
