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)')
Not all setting names are valid values for the value of the connection's "type".
However, if a shortened value is introduced, all setting names are
considered, like in:
Error: bad connection type: 'eth' is ambiguous: ethernet, ethtool
Note that ethtool is not a valid value for "type".
Fix it by considering only "base" settings names.
At the moment, the access point mode uses 20MHz channels. Introduce a
new 'wifi.channel-width' property that allows the use of a larger
bandwidth, thus increasing performances.
Instead of asking the Wi-Fi password in advance (or not at all, if we're
creating a new connection for "nmcli d conn"), use the secret agent.
This makes things consistent with other places where we handle the secrets
for an activating connection in nmcli ("nmcli c up", "nmcli d con" with
an existing connection).
This also fixes the situation where the secrets would stop being
required, such as on enrollment via WPS button press on a router.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1960
A signal handler is not the only place where we need to clean up after
an in-progress readline() on exit; we may do so when erroring out as
well:
Before (not also the missing line break, which is part of the cleanup):
$ (sleep 10; nmcli c del 'Red Hat Wi-Fi')
$ nmcli --ask d wifi connect 'Red Hat Wi-Fi'
Passwords or encryption keys are required to access the wireless network 'Red Hat Wi-Fi'.
Password (802-11-wireless-security.psk): Error: Connection activation failed: The device's active connection disappeared.
$ [terminal messed up, no echo]
After:
$ (sleep 10; nmcli c del 'Red Hat Wi-Fi')
$ nmcli --ask d wifi connect 'Red Hat Wi-Fi'
Passwords or encryption keys are required to access the wireless network 'Red Hat Wi-Fi'.
Password (802-11-wireless-security.psk):
Error: Connection activation failed: The device's active connection disappeared.
$ hello [terminal echo fine, wheee]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1959
Commit 797f3cafee ('device: fall back to saved use_tempaddr value
instead of rereading /proc') changed the behaviour of how to get the
last resort default value for ip6-privacy property.
Previously we read it from /proc/sys/net/ipv6/conf/default, buf after
this commit we started to read /proc/sys/net/ipv6/conf/<iface> instead,
because the user might have set a different value specific for that device.
As NetworkManager changes that value on connection activation, we used
the value read at the time that NetworkManager was started.
Commit 6cb14ae6a6 ('device: introduce ipv6.temp-valid-lifetime and
ipv6.temp-preferred-lifetime properties') introduced 2 new IPv6 privacy
related properties relying on the same mechanism.
However, this new behaviour is problematic because it's not predictable
nor reliable:
- NetworkManager is normally started at boot time. That means that, if a
user wants to set a new value to /proc/sys/net/ipv6/conf/<iface>,
NetworkManager is likely alread running, so the change won't take
effect.
- If NetworkManager is restarted it will read the value again, but this
value can be the one set by NetworkManager itself in the last
activation. This means that different values can be used as default in
the same system boot depending on the restarts of NetworkManager.
Moreover, this weird situation might happen:
- Connection A with ip6-privacy=2 is activated
- NetworkManager is stopped. The value in
/proc/sys/net/ipv6/conf/<iface>/use_tempaddr remains as 2.
- NetworkManager starts. It reads from /proc/sys/... and saves the value
'2' as the default.
- Connection B with no ip6-privacy setting is activated. The '2' saved
as default value is used. The connection didn't specify any value for
it, and the value '2' was set by another connection for that specific
connection only, not manually by a user that wanted '2' to be the
default.
A user shouldn't have to think on when NetworkManager starts or restarts
to known in an easy and predictable way what the default value for
certain property is. It's totally counterintuitive.
Revert back to the old behaviour of reading from
/proc/sys/net/ipv6/conf/default. Although this value is used by the
kernel only for newly created interfaces, and not for already existing
ones, it is reasonable to think on these settings as "systemwide
defaults" that the user has chosen.
Note that setting a different default in NetworkManager.conf still takes
precedence.
The D-Bus and C APIs admit setting the 802.1X certificates as blobs, as
the documentation of the properties explains. However, this is not
possible from nmcli, where only path to the certificates' files is possible.
This difference in nmcli was explained in the description message that
is shown in nmcli's editor, but this is a documentation that most users
won't ever see, and still the main documentation in nm-settings-nmcli is
missleading.
Add a nmcli specific documentation for the relevant properties and
remove the nmcli's editor descriptions as they are no longer needed.
In the gtkdoc comments, the text below tags like `Since: 1.2` is
discarded. In the property `autoconnect-slaves` a line indicating its
deprecation was below one of these tags. As a result, it was missing in
the man page. Fix it.
Fixes: 194455660d ('connection: deprecate NMSettingConnection autoconnect-slaves property')
When IPv6 privacy extensions are enabled, by default temporary addresses
have a valid lifetime of 1 week and a preferred lifetime of 1 day.
That's far too long for privacy-conscious users, some of whom want a new
address once every few seconds. Add connection options that correspond
to /proc/sys/net/ipv6/conf/*/temp_valid_lft and
/proc/sys/net/ipv6/conf/*/temp_prefered_lft to allow configuring the
address rotation time on a per-connection basis.
The new properties are defined as 32-bit signed integers to match the
sysctl parameters which are also signed, although currently only
positive numbers are valid.
