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.
If there is value in such a helper function (there is), then
it should go alongside the other nm_connection_get_setting*()
helpers. NMDevice is already large enough.
For the Bluetooth NAP we need a Bridge link for the BlueZ to assign the BNEP
links for PANU client connections into.
Let's disable STP by default -- it adds extra delay for the Bridge when the
BNEP link is assigned and is likely not useful for a typical client.
When the two base settings are present, use one of higher priority.
This will pick the "bridge" setting when both "bridge" and "bluetooth" are
present for a Bluetooth NAP connection.
We will need multiple base settings for Bluetooth NAP servers: bluetooth and
bridge. We want to identify the device as "bluetooth" to the user, but leave
the Bridge factory handle it.
The "connection.type" is somewhat redundant -- let's keep it for what the user
sees. And identify the actual base setting to pick the right factory by the
actually present setting.
Having a bridge-port/team-port setting for a connection that
has a different slave-type makes no sense. Such a configuration
shall be considered invalid, and be fixed by normalization.
Note that there is already a normalization the other way around,
when you omit the "slave-type" but a "master" and one(!) port-type
setting is present, the slave-type is automatically determined
based on the port-type.
The use of this is of course to modify an existing slave connection
to make it a non-slave. Then the invalid port settings should be
automatically removed.
Previously, ifcfg-rh writer would write the "BRIDGING_OPTS" setting
without a "BRIDGE". The reader would then (correctly) ignore the
bridge-port. Avoid that altogehter, by requiring the connection to
strictly verify.
A "vlan" setting can optionally have an ethernet setting.
However, ifcfg-rh reader always adds such a setting, because
well... Anyway, the result is that writing a VLAN setting
without ethernet section will yield a different result
on re-read.
Let's have normalization add the ethernet setting, so that
two we consistently have it present.
The new NMSettingMacsec contains information necessary to establish a
MACsec connection. At the moment we support two different MACsec
modes, both using wpa_supplicant: PSK and EAP.
PSK mode is based on a static CAK key for the MACsec key agreement
protocol, while EAP mode derives keys from a 802.1x authentication and
thus requires the presence of a NMSetting8021x in the connection.
If auto-negotiate is switched off, enforce that both speed and duplex
are set or unset (which would mean "ignore"): if only one is set, reset
both silently and ignore link configuration.
NOTE: changed the default value for auto-negotiate from TRUE to FALSE.
Normalization enforces that no values for speed and duplex are there
when autonegotiation is on. This is required as autoneg on with specific
speed and duplex set means to ethtool to use autonegotiation but
advertise that specific speed and duplex only.
autoneg off, speed 0 and duplex NULL means to ignore link negotiation.
