The D-Bus API documentation of the IPv4 and IPv6 settings say:
* addresses
Deprecated in favor of the 'address-data' and 'gateway'
properties, but this can be used for backward-compatibility
with older daemons. Note that if you send this property the
daemon will ignore 'address-data' and 'gateway'.
* gateway
The gateway associated with this configuration. This is only
meaningful if "addresses" is also set.
This documentation wrongly suggests that at D-Bus level "gateway"
requires "addresses", while it actually requires "address-data". The
reason for the inconsistency is that the gateway documentation is
common between nmcli and D-Bus and it refers to the "address" GObject
property, not to the D-Bus property.
Fix this inconsistency by not explicitly mentioning the property name.
Fixes: 36156b70dc ('libnm: Override parts of nm-setting-docs.xml')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2319
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).
When we do `nmcli networking off` it's shown as state "sleeping". This
is confusing, and the only reason is that we share internally code to
handle both situations in a similar way.
Rename the state to the more generic name "disabled", situation that can
happen either because of sleeping or networking off.
Clients cannot differentiate the exact reason only with the NMState value,
but better that they show "network off" as this is the most common reason
that they will be able to display. If the system is suspending, there will
be only a short period of time that they can show the state, and showing
"network off" is not wrong because that's what NM has done as a response
to suspend.
In the logs, let's make explicit the exact reason why state is changing
to DISABLED: sleeping or networking off.
Logs before:
manager: disable requested (sleeping: no enabled: yes)
manager: NetworkManager state is now ASLEEP
Logs after:
manager: disable requested (sleeping: no enabled: yes)
manager: NetworkManager state is now DISABLED (NEWORKING OFF)
State before:
$ nmcli general
STATE ...
asleep ...
State after:
$ nmcli general
STATE ...
network off ...
Running the build script with LTO disabled
("contrib/fedora/rpm/build_clean.sh -W lto") gives the following error:
In file included from ../src/libnm-std-aux/nm-default-std.h:102,
from ../src/libnm-glib-aux/nm-default-glib.h:11,
from ../src/libnm-glib-aux/nm-default-glib-i18n-lib.h:13,
from ../src/libnm-client-aux-extern/nm-default-client.h:11,
from ../src/nmcli/connections.c:6:
In function ‘_nm_auto_unref_ptrarray’,
inlined from ‘do_connection_add’ at ../src/nmcli/connections.c:6069:35:
../src/libnm-std-aux/nm-std-aux.h:1106:12: error: ‘props’ may be used uninitialized [-Werror=maybe-uninitialized]
1106 | if (*v) \
| ^
../src/libnm-glib-aux/nm-macros-internal.h:91:1: note: in expansion of macro ‘NM_AUTO_DEFINE_FCN0’
91 | NM_AUTO_DEFINE_FCN0(GPtrArray *, _nm_auto_unref_ptrarray, g_ptr_array_unref);
| ^~~~~~~~~~~~~~~~~~~
../src/nmcli/connections.c: In function ‘do_connection_add’:
../src/nmcli/connections.c:6069:35: note: ‘props’ was declared here
6069 | gs_unref_ptrarray GPtrArray *props;
| ^~~~~
cc1: all warnings being treated as errors
Fix it.
Fixes: bb850fda0e ('nmcli: connection: process port-type, type and controller first')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2236
Commit bb850fda0e ('nmcli: connection: process port-type, type
and controller first') started correctly rejecting IP configuration
on port connections.
However, previously nmcli would accept IP parameters for ports when
using a specific parameters order. To avoid breaking user scripts that
may have relied on this behavior, introduce a backward compatibility
quirk.
Specifically, nmcli accepts a disabled/ignore IP method on a port
connection. For any other IP setting on a port connection, a specific
error message is now shown.
https://issues.redhat.com/browse/RHEL-90756https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2227
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
When nmcli tries to match a controller it filters by its type. The
controller's type must match with the port's port-type. If no controller
matches, the printed warning was "doesn't refer to any existing
profile". However, the profile might exist, but with wrong type. Improve
the message so it makes that clear.
Fixes: aa12bb353b ('cli: discover slave type for a connection with a master')
Normally it is possible not to define port-type in nmcli and it deduces
it from connection.type or connection.controller. Some types like 'bond-slave'
have a single possible value for port-type. In other cases nmcli deduces
the port-type by getting the controller's type, like 'bond'.
For OVS connections, the second method of guessing by the controller's
type was used. However, in OVS it is common to have different devices
with the same name, causing nmcli to use "ovs-interface" as port-type
if it matched by controller name.
Fix if by deducing the port-type from the connection's type. An ovs-port
connection must always have port-type=ovs-bridge, and an ovs-interface
connection must always have port-type=ovs-port.
Note that this is something that should be done in the daemon, not in
the clients, but this is a small patch that makes it to work in nmcli,
at least. Without this, the mechanism of guessing from the parent would
act, leading to wrong results.
Ideally, all this should be done in the daemon, but currently many
checks in nmcli/libnm depends on having the port-type set, and it
would be lot of work to change it.
Fixes: c5324ed285 ('nmcli: streamline connection addition')
When processing the "type" property we deduce the port-type in some
cases and set it. If the user has chosen a port-type we must not
overwrite it. In any case, we should raise an error when validating the
connection.
Fixes: c5324ed285 ('nmcli: streamline connection addition')
If the connection is a port we need to set the connection.port-type
property. Usually this property is guessed by nmcli depending on the
connection type or the chosen controller, so it doesn't need to be
specified by the user. However, if it is explicitly set by the user
we should not guess, but just use it.
When we process arguments like "controller" or "type" we call custom
functions like set_connection_controller that will guess the port-type
if needed. By processing port-type first, it will be set in the
connection by the time that these other properties are processed, so they
won't try to guess.
After port-type, process connection.type and connection.controller, as we
are usually capable of deducing the port-type from them. Type needs to
be processed first because some types like bond-slave or ovs-port have
only one possible port-type value so we must not try to guess from the
controller.
Fixes: c5324ed285 ('nmcli: streamline connection addition')
This has always been broken (libedit-0:3.1-17.20160618cvs.fc26 is too
old to work and libedit-0:3.1-20.20170329cvs.fc27.x86_64 has this type
mismatch), but new GCC complains (14, 15).
../src/nmcli/connections.c: In function ‘nmcli_editor_tab_completion’:
../src/nmcli/connections.c:6862:64: error: assignment to ‘void (*)(char **, int, int)’ from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types]
6862 | rl_completion_display_matches_hook = uuid_display_hook;
| ^
../src/nmcli/connections.c:6909:60: error: assignment to ‘void (*)(char **, int, int)’ from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types]
6909 | rl_completion_display_matches_hook = uuid_display_hook;
| ^
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2172
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
If an alias like `nmcli=nmcli --some-arguments` is used, bash completion
doesn't work. Fix it by using `command nmcli` from the nmcli-completion
script, so we ensure that the --complete-args is passed directly to
nmcli binary, not through an alias.
Contributed-by: Jonas Belouadi (@potamides)
Fixes https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1734
The current mess of code seems like a hodgepodge of complex ideas,
partially copied from systemd, but then subtly different, and it's a
mess. Let's simplify this drastically.
First, assume that getrandom() is always available. If the kernel is too
old, we have an unoptimized slowpath for still supporting ancient
kernels, a path that should be removed at some point. If getrandom()
isn't available and the fallback path doesn't work, the system has much
larger problems, so just crash. This should basically never happen.
getrandom() and having randomness available in general is a critical
system API that should be expected to be available on any functioning
system.
Second, assume that the rng is initialized, so that asking for random
numbers should never block. This is virtually always true on modern
kernels. On ancient kernels, it usually becomes true. But, more
importantly, this is not the responsibility of various daemons, even
ones that run at boot. Instead, this is something for the kernel and/or
init to ensure.
Putting these together, we adopt new behavior:
- First, try getrandom(..., ..., 0). The 0 flags field means that this
call will only return good random bytes, not insecure ones.
- If this fails for some reason that isn't ENOSYS, crash.
- If this fails due to ENOSYS, poll on /dev/random until 1 byte is
available, suggesting that subsequent reads from the rng will almost
have good random bytes. If this fails, crash. Then, read from
/dev/urandom. If this fails, crash.
We don't bother caching when getrandom() returns ENOSYS. We don't apply
any other fancy optimizations to the slow fallback path. We keep that as
barebones and minimal as we can. It works. It's for ancient kernels. It
should be removed soon. It's not worth spending cycles over. Instead,
the goal is to eventually reduce all of this down to a simple boring
call to getrandom(..., ..., 0).
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2127
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
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.
Since introducing the setting ipv[46].dhcp-send-hostname-v2 internally
in NM for supporting global default behavior of DHCP send hostname,
confusion arises for setting the dhcp-send-hostname-v2 and old
dhcp-send-hostname in nmcli. To avoid any confusion from user
configuring dhcp-send-hostname-v2 and old dhcp-send-hostname using
nmcli, introduce the mapping from nmcli argument dhcp-send-hostname to
internal dhcp-send-hostname-v2 property and the mapping from nmcli
argument dhcp-send-hostname-deprecated to internal old dhcp-send-hostname
property.
The change in split_required_fields_for_con_show makes that properties
specified with -g or -f are converted to the libnm's "internal" names.
The change in _print_fill makes that the names are converted to the
"external" user facing names.
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.
from its previous location unter the users `$HOME` directory to
`$XDG_CACHE_HOME/nmcli-history`. This makes `nmcli` compliant with the
[XDG Base Directory Specification][1].
[1]: https://specifications.freedesktop.org/basedir-spec/latest/
This patch add support to IPVLAN interface. IPVLAN is a driver for a
virtual network device that can be used in container environment to
access the host network. IPVLAN exposes a single MAC address to the
external network regardless the number of IPVLAN device created inside
the host network. This means that a user can have multiple IPVLAN
devices in multiple containers and the corresponding switch reads a
single MAC address. IPVLAN driver is useful when the local switch
imposes constraints on the total number of MAC addresses that it can
manage.
When a connection with ipv4.method=auto (DHCP) is configured with
ipv4.link-local=enable we were leaving the link-local address forever,
but this is not correct according to RFC3927[1] which says:
a host SHOULD NOT have both an operable routable address and an IPv4
Link-Local address configured on the same interface.
This adds a new mode that is more compliant, which only sets an IPv4
link-local address if no other address is set (through either DHCP lease
or ivp4.addresses setting)
Closes#1562
Link: https://github.com/systemd/systemd/issues/13316
Link: https://datatracker.ietf.org/doc/html/rfc3927#section-1.9 [1]
The code handling options with supposes, that options
are split by `=`, which is not the case. This fixes the following:
```
nmcli -f ipv4.ad\t\t
nmcli -f ipv4.ad=ipv4.addresses
nmcli --field ipv4.ad\t\t
nmcli --field ipv4.ad=ipv4.addresses
```
Using options with values separated with `=` remains broken,
but this change doesn't affect it:
```
nmcli --field=ipv4.ad\t\t
nmcli --field=ipv4.ad
```
Also, `man` and `usage` uses `--color auto|yes|no`,
not `--color=auto|yes|no`. So, this fix should be sufficient.
Bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2115827
Attempt to tab-complete a property from a setting which does not exist
results in an assertion failure:
nmcli > set lala.lala<TAB>
(process:597363): nm-CRITICAL **: 16:30:21.642: nm_meta_setting_info_editor_find_by_name: assertion 'setting_name' failed
Thread 1 "nmcli" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff780dc28 in g_logv () from /lib64/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff780dc28 in g_logv () at /lib64/libglib-2.0.so.0
#1 0x00007ffff780dea3 in g_log () at /lib64/libglib-2.0.so.0
#2 0x000000000044a2c2 in nm_meta_setting_info_editor_find_by_name (setting_name=<optimized out>, use_alias=use_alias@entry=0)
at src/libnmc-setting/nm-meta-setting-access.c:35
#3 0x000000000042eb07 in get_setting_and_property (prompt=<optimized out>, line=<optimized out>, setting_out=0x7fffffffcf10, property_out=0x7fffffffcf18)
at src/nmcli/connections.c:6639
#4 0x000000000042ec38 in get_allowed_property_values (out_to_free=out_to_free@entry=0x7fffffffcf50) at src/nmcli/connections.c:6711
#5 0x000000000042ed8c in should_complete_property_values (prompt=prompt@entry=0x5befb0 "nmcli 802-1x.pac-file> ", line=line@entry=0x0, multi=multi@entry=0x7fffffffcfe4)
at src/nmcli/connections.c:6735
#6 0x000000000042f5d8 in nmcli_editor_tab_completion (text=0x5bef90 "lala", start=<optimized out>, end=13) at src/nmcli/connections.c:6899
#7 0x00007ffff776dcdc in gen_completion_matches () at /lib64/libreadline.so.8
...
Do not proceed resolving the setting name if it does not pass
check_valid_name().
In case the user selects a setting/property with "goto" command, and
then attempts to tab-complete a setting/property pair, the original sett
and prop strings are overriden without freeing:
nmcli > goto 802-1x.pac-file
nmcli 802-1x.pac-file> set 802-1.lal<TAB>
Fixes: 79bc271685 ('cli: TAB-completion for enum-style property values (rh #1034126)')
