This new endpoint type has been recently added to the kernel in v6.18
[1]. It will be used to create new subflows from the associated address
to additional addresses announced by the other peer. This will be done
if allowed by the MPTCP limits, and if the associated address is not
already being used by another subflow from the same MPTCP connection.
Note that the fullmesh flag takes precedence over the laminar one.
Without any of these two flags, the path-manager will create new
subflows to additional addresses announced by the other peer by
selecting the source address from the routing tables, which is harder to
configure if the announced address is not known in advance.
The support of the new flag is easy: simply by declaring a new flag for
NM, and adding it in the related helpers and existing checks looking at
the different MPTCP endpoint. The documentation now references the new
endpoint type.
Note that only the new 'define' has been added in the Linux header file:
this file has changed a bit since the last sync, now split in two files.
Only this new line is needed, so the minimum has been modified here.
Link: https://git.kernel.org/torvalds/c/539f6b9de39e [1]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
This property allows the user to optionally configure
an interlink name on a HSR interface, so that it could
serve as RedBox (Redundant Box) by connecting DAN (dual
attachment node) to SAN (single attachment node).
This property allows the user to set the protocol
version when using HSR. Currently, the property
supports two values - `2010` (referred to as HSRv0
in the kernel), and `2012` (HSRv1).
If "flags" indicate that only secrets should be serialized and a peer
doesn't contain any secrets, skip it. Otherwise the function would
return a non-empty result when the connection contains no secret,
which causes issues later in the agent manager.
Fixes: e148ec07d5 ('libnm: add NMWireGuardPeer and libnm support for peers')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2244
The previous commit will raise an error if wrong list
separators are being used in an nmconnection file for dns-search to
avoid that they are all considered a single string.
However, existing users might have wrong values of dns-search that
currently are not preventing the connection of being activated. To avoid
that a NetworkManager update breaks existing configs, potentially even
cutting connectivity with remote machines, accept wrong separators in
keyfiles but emitting a warning.
Fixes: 919156552ede ('dns: ensure that no wrong separators are used for DNS search domains')
If wrong separators are used in they keyfile, like commas, the whole
line is considered as a single domain string, like "a.org,b.org".
Obviously this is invalid.
Ideally we should validate that the string is a valid domain, but this
gets quite complex if we want to support unicode characters, which are
valid for many top domains. For now, validate at least that no wrong
separators have been used.
Fixes https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1740
verify() is setting an error without returning FALSE to make the
validation fail. When the parent is set, the device is a Infiniband
partition and it must have a p-key != -1.
Fixes: d595f7843e ('libnm: add libnm/libnm-core (part 1)')
Linux UIDs/GIDs are 32-bit unsigned integer, with 4294967295 reserved
as undefined.
Before:
# useradd -u 4294967294 -M testuser
useradd warning: testuser's uid -2 outside of the UID_MIN 1000 and UID_MAX 60000 range.
# nmcli connection add type tun ifname tun1 owner 4294967294 ipv4.method disabled ipv6.method disabled
Error: Failed to add 'tun-tun1' connection: tun.owner: '4294967294': invalid user ID
After:
# useradd -u 4294967294 -M testuser
useradd warning: testuser's uid -2 outside of the UID_MIN 1000 and UID_MAX 60000 range.
# nmcli connection add type tun ifname tun1 owner 4294967294 ipv4.method disabled ipv6.method disabled
Connection 'tun-tun1' (5da24d19-1723-45d5-8e04-c976f7a251d0) successfully added.
# ip -d link show tun1
2421: tun1: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 500
link/none promiscuity 0 allmulti 0 minmtu 68 maxmtu 65535
tun type tun pi off vnet_hdr off persist on user testuser ...
^^^^^^^^^^^^^
Fixes: 1f30147a7a ('libnm-core: add NMSettingTun')
It is not clear whether we can actually respect this value. For example,
we should not restore the kernel's default value on deactivation or
device's state change, but it is unclear if we can ensure that we'll
still have the connection's configuration in all possible changes of
state.
Also, it is unclear if it's a desirable value that we want to support.
At this point it is mostly clear that trying to configure NM managed
devices externally always ends being dissapointing, no matter how hard
we try.
Remove this value for now, while we discuss whether it makes sense or
not, so it doesn't become stable in the new 1.54 release.
Add a new "sriov.preserve-on-down" property that controls whether
NetworkManager preserves the SR-IOV parameters set on the device when
the connection is deactivated, or whether it resets them to their
default value. The SR-IOV parameters are those specified in the
"sriov" setting, like the number of VFs to create, the eswitch
configuration, etc.
Even if WireGuard is supported since long time in NetworkManager, it
is still not possible to manage the list of peers via nmcli. The
reason is that in the past we wanted to introduce a special syntax
that would allow to manage the peer list more easily. However, this
requires heavy changes to the nmcli output formatting code, and so it
never happened.
Since perfection is the enemy of good, abandon the idea of a custom
handling of peers and treat them as any other composite property. The
property is named "wireguard.peers" and exposes the peers indexed by
public key, with optional attributes.
Example:
$ nmcli connection modify wg0 wireguard.peers "8Wgc1a0jJX3rQULwD5NFFLKrKQnbOnTiaNoerLneG1o= preshared-key=16uGwZvROnwyNGoW6Z3pvJB5GKbd6ncYROA/FFleLQA= allowed-ips=0.0.0.0/0 persistent-keepalive=10"
$ nmcli connection modify wg0 +wireguard.peers "fd2NSxUjkaR/Jft15+gpXU13hKSyZLoe4cp+g+feBCc= allowed-ips=192.168.40.0/24 endpoint=172.25.10.1:8888"
$ nmcli -g wireguard.peers connection show wg0
8Wgc1a0jJX3rQULwD5NFFLKrKQnbOnTiaNoerLneG1o= allowed-ips=0.0.0.0/0 persistent-keepalive=10, fd2NSxUjkaR/Jft15+gpXU13hKSyZLoe4cp+g+feBCc= allowed-ips=192.168.40.0/24 endpoint=172.25.10.1\:8888
$ nmcli connection modify wg0 -wireguard.peers 8Wgc1a0jJX3rQULwD5NFFLKrKQnbOnTiaNoerLneG1o=
$ nmcli -g wireguard.peers connection show wg0
fd2NSxUjkaR/Jft15+gpXU13hKSyZLoe4cp+g+feBCc= allowed-ips=192.168.40.0/24 endpoint=172.25.10.1\:8888
Settings "ovs-dpdk" and "ovs-patch" are currently marked with priority
NM_SETTING_PRIORITY_HW_BASE, which makes them "base" settings. This
means that they can be used as connection type, for example via "nmcli
connection add type ovs-dpdk ...".
This is wrong, as both settings can only belong to a connection of
type "ovs-interface". Decrease their priority and make them non-base
settings.
The problem was spotted when trying to add a ovs-patch connection via
nmcli:
# nmcli connection add type ovs-patch ifname p con-name q ovs-patch.peer r controller s port-type ovs-port
Warning: controller='s' doesn't refer to any existing profile.
(process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 1682 (_normalize_ovs_interface_type): should not be reached
(process:4580): nm-WARNING **: 10:15:42.807: connection did not verify after normalization: ??
(process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 2170 (_connection_normalize): should not be reached
Error: Failed to add 'q' connection: ovs-interface.type: A connection with 'ovs-patch' setting must be of connection.type "ovs-interface" but is "ovs-patch"
Fixes: d0ec501163 ('cli: assert that valid_parts are set for base types')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2178
Introduce a new "prefix-delegation" setting. It contains properties
related to the configuration of downstream interfaces using IPv6
prefix-delegation. The only property at the moment is "subnet-id",
which specifies which prefix to choose when the delegation contains
multiple /64 networks.
Previously, IPv4 shared method will automatically enable the IPv4
global forwarding, all the per-interface level IPv4 forwarding settings
may be changed to match the global setting. Also, all the per-inteface
level forwarding settings can not be restored when deactivating the
shared connection. This is problematic as it may disrupt custom
configurations and lead to inconsistent forwarding behavior across
different network interfaces.
To address this, the implementation now ensures that the original
per-interface forwarding settings are preserved. Upon activating a
shared connection, instead of enabling IPv4 global forwarding
automatically, the per-interface forwarding is enabled on all other
connections unless a connection explicitly has the forwarding set to
"no" in its configuration. Upon deactivating all shared connection,
per-interface forwarding settings are restored to sysctl's default
value. Furthermore, deactivating any connection explicitly sets the
forwarding to sysctl's default value ensuring that network forwarding
behavior remains consistent.
Add support for configuring per-interface IPv4 sysctl forwarding setting
in NetworkManager. The feature allows users to configure the
net.ipv4.conf.<interface>.forward setting directly through
NetworkManager, enabling targeted forwarding configurations for
interfaces. This is particularly useful for cases such as enabling
forwarding for MetalLB load balancing without requiring a global
ip_forward=1 setting.
While forwarding setting can be managed via /etc/sysctl.conf,
configuring sysctl options for dynamically created or
software-configured interfaces (e.g., bridges) poses challenges. With
this feature, NetworkManager can configure these settings when
interfaces are created or updated, users no longer need to rely on
nm-dispatcher scripts for per-interface sysctl configuration, which can
be error-prone and complex. This feature ensures a more seamless and
integrated way to manage per-interface forwarding configurations,
reducing user overhead and improving usability in complex network
setups.
We do not support configuring per-device IPv6 sysctl forwarding because
in order to make per-device IPv6 sysctl forwarding work, we also need to
enable the IPv6 global sysctl forwarding setting, but this has potential
security concerns because it changes the behavior of the system to
function as a router, which expose the system to new risks and
unintended traffic flows, especially when enabling forwarding on the
interface the user previously explicitly disabled. Also enabling
per-device IPv6 sysctl setting will change the behavior of router
advertisement (accept_ra), which is not expected. Therefore, we
only support configuring per-device IPv4 sysctl forwarding option in
NetworkManager.
Resolves: https://issues.redhat.com/browse/RHEL-60237https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2071https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1833
Move nm_keyfile_add_group() to libnm-glib-aux so that it can be used
by other components such as nm-initrd-generator. Rename it to
nm_key_file_add_group() to be consistent with the GLib API names
(g_key_file_*()).
Introduce new functions to parse and normalize name servers. Their
name contains "dns_uri" because they also support a URI-like syntax
as: "dns+tls://192.0.2.0:553#example.org".
The keyfile format allows to specify the gateway in two ways: with a
separate "gateway" key, or by appending the gateway address to one of
the address$N lines:
[ipv4]
address1=192.0.2.1/24
gateway=192.0.2.254
[ipv4]
address1=192.0.2.1/24,192.0.2.254
The former syntax is self-documenting and easier to understand for
users, but NetworkManager defaults to the latter when writing
connection files, for historical reasons. Change that and use the
explicit form.
Note that if a users has scripts manually parsing keyfiles, they could
stop working and so this can be considered an API breakage. OTOH,
those scripts are buggy if they don't support both forms, and they can
already break with perfectly valid user-generated keyfiles.
I think it's acceptable to change the default way to persist keyfiles;
the only precaution would be that this patch should not be applied
during a stable release cycle of a distro.
The "closure" annotation needs to be set on the callback parameter
instead of on the data for the callback function.
This patch fixes the following warning:
"""
../src/libnm-core-impl/nm-utils.c:3632: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:4778: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:5776: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:5849: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:5976: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6091: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6448: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6521: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6581: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6663: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6728: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:974: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1014: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1041: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:974: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1014: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1041: Warning: NM: invalid "closure" annotation: only valid on callback parameters
"""
Introducing support of ethtool FEC mode:
D-BUS API: `fec-mode: uint32_t`.
Keyfile:
```
[ethtool]
fec-mode=<uint32_t>
```
nmcli: `ethtool.fec-mode` allowing values are any combination of:
* auto
* off
* rs
* baser
* llrs
Unit test cases included.
Resolves: https://issues.redhat.com/browse/RHEL-24055
Signed-off-by: Gris Ge <fge@redhat.com>
We have encountered multiple incidents where users face connectivity
issues after booting, particularly due to hardware like switches that do
not pass traffic for a few seconds after startup. And services such as
NFS fail to mount because they try to initiate before the network is
fully reachable. Therefore, we are supporting
`connection.ip-ping-addresses` and `connection.ip-ping-timeout` to
allow administrators to configure the network to verify connectivity to
a specific target(such as a service like NFS) instead of relying on
gateway reachability, which may not always be relevant in certain
network configurations.
Resolves: https://issues.redhat.com/browse/RHEL-21160https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2034https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1797
To have a consistent setting name conversion between
`dhcp-send-hostname` and `dhcp-send-hostname-v2` with nmcli and global
config, convert dhcp-send-hostname <-> dhcp-send-hostname-v2 during
keyfile settings read and write.
In nmcli we have renamed dhcp-send-hostname and dhcp-send-hostname-v2 to
dhcp-send-hostname-deprecated and dhcp-send-hostname so users don't need
to worry about the details of the weird workarounds that we sometimes
need to do to expand and/or deprecate some properties.
However, the autogenerated documentation didn't include this names. Add
---nmcli--- specific documentation, adding a new property-infos field
called "rename" with the new name used in nmcli. This field can be used
for more properties if we use the same strategy in the future.
The user does not want to send machine hostname to the DHCP server
globally by default to avoid ddns record getting created in IPAM.
otherwise, IPAM creates ddns records which might interfere with user's
regular host record. Thus, introduce the ternary property
dhcp_send_hostname_v2 to warrant this behavior.
Notice that we set the GSpec of dhcp-send-hostname-v2 to int, because
defining it as enum would make that it cannot be expanded in a backwards
compatible way if we need to add more values: old clients using libnm
would reject it due to the new value being unknown. Follow the same
strategy than _nm_setting_property_define_direct_enum, defining the
NMSettInfoPropertType as enum, but the glib's GSpec as int.
Resolves: https://issues.redhat.com/browse/RHEL-56565https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2029https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1765
Add a new "ipv4.dhcp-ipv6-only-preferred" property to control the
"IPv6-Only Preferred" DHCPv4 option (RFC 8925). The option indicates
that a host supports an IPv6-only mode and is willing to forgo
obtaining an IPv4 address if the network provides IPv6 connectivity.
