It is useful when there is an already active device and we want to
bring it down preserving the SR-IOV VFs. For example:
$ nmcli connection add type ethernet ifname eni1np1 sriov.total-vfs 2 ipv4.method disabled ipv6.method disabled
$ nmcli connection up ethernet-eni1np1
$ ip link show eni1np1
342: eni1np1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 6e:cf:f0:08:74:f4 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, ...
vf 1 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, ...
$ nmcli device modify eni1np1 sriov.preserve-on-down yes
$ nmcli connection down ethernet-eni1np1
$ ip link show eni1np1
342: eni1np1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 6e:cf:f0:08:74:f4 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, ...
vf 1 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, ...
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.
When using the netdev datapath, we wait that the tun link appears, we
call nm_device_set_ip_ifindex() (which also brings the link up) and
then we check that the link is ready, i.e. that udev has announced the
link and the MAC address is correct. After that, we schedule stage3
(ip-config).
In this, there is a race condition that occurs sometimes in NMCI test
ovs_datapath_type_netdev_with_cloned_mac. In rare conditions,
nm_device_set_ip_ifindex() bring the interface up but then ovs-vswitch
changes again the flags of the interface without IFF_UP. The result is
that the interface stays down, breaking communications.
To fix this, we need to always call nm_device_bring_up() after the tun
device is ready. The problem is that we can't do it in
_netdev_tun_link_cb() because that function is already invoked
synchronously from platform code.
Instead, simplify the handling of the netdev datapath. Every
"link-changed" event from platform is handled by
_netdev_tun_link_cb(), which always schedule a delayed function
_netdev_tun_link_cb_in_idle(). This function just assigns the
ip-ifindex to the device if missing, and starts stage3 if the link is
ready. While doing so, it also bring the interface up.
Fixes: 99a6c6eda6 ('ovs, dpdk: fix creating ovs-interface when the ovs-bridge is netdev')
https://issues.redhat.com/browse/RHEL-17358https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2218
When connecting to an AP configured for WPA3 transition mode, the
connection will fail if PMF is disabled on the client due to SAE and
FT-SAE being unconditionally added to the key_mgmt variable's
parameters.
By removing the "!is_ap ||" check, SAE and FT-SAE will no longer be
selected when PMF is disabled, allowing clients to connect via
WPA2/PSK mode as per the original intent of
a0988868ba.
Signed-off-by: Conn O'Griofa <connogriofa@gmail.com>
The Open VSwitch interfaces have corresponding platform links. When an
Open VSwitch interface is created while NetworkManager is running, the
OVS factory usually sees an OVSDB entry appear first, then creates a
NMDevice. After that, when a platform link appears, the device is
already there.
Upon a (re-)start, the link might be seen first, and then things
go south. The OVS factory rejects the device, which results in Generic
device being created instead. Another device, this time of an
appropriate is created for the same link once the OVSDB entry is seen.
Needless to say, with two NMDevices for the same platform link existing,
no end of mayhem ensues (an assertion is tripped).
Resolves: https://issues.redhat.com/browse/NMT-1634https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2207
A device has the "external-down" unmanaged flag when:
!is-created-by-nm AND (!is-up OR (!has-address AND !is-controller))
When the "is-up" or the "has-address" conditions change, we properly update
the unmanaged flag by calling _dev_unmanaged_check_external_down() in
_dev_l3_cfg_notify_cb(PLATFORM_CHANGE_ON_IDLE).
The "is-controller" condition changes when another link indicates the
current device as controller. We currently don't update the unmanaged flag
when that happens and so it's possible that the device stays unmanaged even
if it has a port. This can be easily reproduced by running this commands:
ip link add veth0 type veth peer name veth1
ip link add vrf0 type vrf table 10
ip link set vrf0 up
ip link set veth0 master vrf0
Sometimes, the device shows as "unmanaged" instead of "connected
(externally)".
Fix this by re-evaluating the "external-down" unmanaged flags on the
controller when a port is attached or detached.
Fixes: c3586ce01a ('device: consider a device with slaves configured')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2209
When calling to nm_device_is_available, the device types that requires a
parent like VLAN or MACVLAN checks that their parent exists.
nm_device_is_available is a function to check if the device is available
to activate a connection, so it makes sense that if the parent is not
present it can't be activated.
However, this is wrong for 2 reasons:
1. Most of they are virtual devices that might be unrealized when
checking its availability. If they're unrealized, their parent hasn't
been set yet.
2. Even if they're realized, their current parent might not be the one
that is defined in the connection that is being activated.
This is causing that unrealized devices are not being activated as ports
because nm_manager_get_best_device_for_connection thinks that they are
not available.
Get rid of these checks for the parent in the is_available callbacks.
Fixes: ba86c208e0 ('Revert "core: prevent the activation of unavailable OVS interfaces only"')
Fixes: 774badb151 ('core: prevent the activation of unavailable devices')
When defining an IPv6 address with square brackets and prefix, like
[dead::beef]/64, the prefix was silently ignored. The address was
accepted only accidentally, because get_word replaced ']' with '\0' so
it resulted in a valid IPv6 address string, but without the prefix.
The previous commit has fixed get_word with better logic to handle the
square brackets, uncovering this issue.
Fix it by explicitly splitting IP addresses and prefixes in
reader_parse_ip so we get a valid address and prefix.
Also, use a prefix different to 64 in the test test_if_ip6_manual. 64 is
the default one, making that the test passed despite the defined prefix
was actually ignored.
Fixes: ecc074b2f8 ('initrd: add command line parser')
If any bond option contains an IPv6 address it needs to be enclosed with
[]. Otherwise the ':' separators from the IP address can be confused
with the ':' separators from the 'bond=' cmdline arguments.
However, the square brackets were ignored:
$ nm-initrd-generator -s "bond=bond0:eth0,eth1:ns_ip6_target=[FC08::789:1:0:0:3]"
NetworkManager-Message: 08:46:55.114: <warn> [1745498815.1146] cmdline-reader: Ignoring invalid bond option: "ns_ip6_target" = "[FC08": '[FC08' is not a valid IPv6 address for 'ns_ip6_target' option
NetworkManager-Message: 08:46:55.114: <warn> [1745498815.1148] cmdline-reader: Ignoring extra: '789:1:0:0:3]'.
The opening '[' was only being considered if it was the first character
in `get_word`. Fix it and consider it if it's in the middle too.
If the brackets are used first and last, directly remove them as it is what
most callers expect. However, if it's in the middle there is no reasonable
way to remove them, so don't do it. Instead, the caller will have to consider
this possibility when processing the content.
Fixes: ecc074b2f8 ('initrd: add command line parser')
Fixes https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1755
NMDevices have a special "can_reapply_change_ovs_external_ids" boolean
field indicating whether the device type supports reapplying the
ovs-external-ids and ovs-other-config settings.
Remove this field and use the standard can_reapply_change() method. No
change in behavior is expected.
If a OVS bridge created via NM has a port created externally, when the
bridge connections goes down then NM detaches the NM-created
port. However, it finds that the bridge still has a port (the external
one) and so it doesn't remove the bridge from ovsdb.
This is a problem, because it means that an explicity deactivation of
the bridge leaves the bridge up. To fix this, only track the number of
port in the bridge actually created by NM. Also, leave alone bridges
not created by NM.
Skip the internal NBFT table parsing when nbft interfaces
are already defined on the cmdline, e.g. from the original
95nvmf dracut module.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Some firmware implementations incorrectly report v6 address prefix
of zero. Let's use /64 as a sane workaround.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Creates additional connections for VLANs, which are in fact
separate HFI records in the NBFT table. Uses MAC address for
linking parent interface as the interface naming is defined
by an external service.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
As suggested during the review process, NBFT is niche and most users
won't need it. So keep the initrd generator light and only open
libnvme when any NBFT table is found.
In a typical dracut host-only scenario the nbft dracut module will
be pulled in only when NBFT is present in the system, packing in
nvme-cli and libnvme in the initramfs image.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
The NVMe Boot Firmware Table (NBFT) is a mechanism of passing context
from a pre-OS Boot environment to an OS runtime, as defined by the
NVM Express Boot Specification. Exposed as an ACPI table it contains
network interface definitions along with NVMe subsystem and namespace
data structures.
This adds new nm-initrd-generator parser that uses libnvme NBFT parser
implementation.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
We often forget to add new files to POTFILES, and also
have some paths in the skip file that have not existed
for 15+ years. We should ensure that these files include
the paths that should be there, and nothing more.
This commit adds a test that checks whether all the files
in the po lists exist, and vice versa, that all the files
in the source tree that should be included in this list,
are indeed included in this list.
Introduce some basic infrastructure to perform ethtool operations via
netlink. As a proof of concept, implement the pause settings.
Netlink has some advantages over ioctl():
- it can be easily extended with new attributes;
- it can return descriptive error messages via the extended ack
mechanism. For example, when setting the ring parameters to a value
outside the allowed range, userspace receives error code -EINVAL
and message "requested ring size exceeds maximum". ioctl() gets
only -EINVAL, which is shared among many error reasons;
- since it's possible to specify an ifindex in the request, there are
no race conditions when the interface name changes;
New ethtool API is available only via netlink; however it makes sense
to start using netlink also for the old API that NM is already using
(pause, eee, rings, etc.) over ioctl() because of the advantages
described above.
We're going to replace most of the ioctl-based ethtool functions with
a netlink-based equivalent. Move the ioctl ones to a separate file so
that it's easier to see what still needs to be converted. Also add a
common prefix to the function names.
Previously, when a generated connection was edited, and the
machine was rebooted, the connection would not apply, and a
new generated connection would be made, because autoconnect
was set to FALSE.
Set autoconnect to be true by default, so that the modified
generated connection is applied.
