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.
iproute2 and the kernel accept 0 as valid rto_min value:
# ip route add 172.16.0.1 dev enp1s0 rto_min 0ms
# ip route show
172.16.0.1 dev enp1s0 scope link rto_min lock 0ms
Even if a value of 0ms would not be useful in practice, it is better
to exactly track what kernel reports, instead of assuming that when
the value is zero it is "not set".
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 the dictionary contains keys "address" and "uri", the first value
is leaked.
==4730== 14 bytes in 1 blocks are definitely lost in loss record 51 of 1,755
==4730== at 0x4841866: malloc (vg_replace_malloc.c:446)
==4730== by 0x4CC5CB9: g_malloc (gmem.c:100)
==4730== by 0x4CDF518: g_strdup (gstrfuncs.c:323)
==4730== by 0x496A6B8: g_strdup_inline (gstrfuncs.h:321)
==4730== by 0x496A6B8: nm_inet_ntop_dup (nm-inet-utils.h:355)
==4730== by 0x496A95B: nm_inet_parse_str (nm-inet-utils.c:539)
==4730== by 0x48AF3A3: _notify_update_prop_nameservers (nm-ip-config.c:179)
Fixes: 4422b14704 ('core, libnm: support per-connection DNS URIs')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2184
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')
Make sure nm_device_update_dynamic_ip_setup is called every time a carrier was down before and the link is now up again.
Previously the dhcp lease was not renewed if the carrier went down and then up again quickly enough.
This led to cases where an old IP was retained even though the device was connected to a different network with a different DHCP server.
This commit introduces device_link_carrier_changed_down
Fixes: d6429d3ddb ('device: ensure DHCP is restarted every time the link goes up')
It is a little odd that client tests connect "UNAVAILABLE" devices, and
the devices return to "DISCONNECTED" after deactivation.
It differs from what happens in reality, and some client tools
(hey nm-cloud-setup) can break when they rightly assume that the
device is not ready for activation when it's "UNAVAILABLE" not
"DISCONNECTED".
Make it possible to opt in or out of the behavior of creating
connections for disconnected devices. It's not clear why such policy was
in place, and the feature might come useful outside OCI.
Let's add an (undocumented) knob to configure the behavior. We might
remove it (and perhaps make the behaviour default everywhere), or
document and keep it if it turns out we need to use it.
