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.
The function n_dhcp4_c_connection_send_request does not release or take
ownership of its request argument. Because of that, setting it to NULL
in the caller prevents the auto-cleanup of the variable to be executed,
causing a resource leak. Fix it.
Fixes: e23b3c9c3a ('Squashed 'shared/n-dhcp4/' content from commit fb1d43449')
Fixes: 243cc433fb ('n-dhcp4: add new client probe function to send RELEASE message')
Detected by coverity, the ping_op pointers are used after being freed in
cleanup_ping_operations. Although calling to g_list_remove is probably
safe because it only needs the value of the pointer, not to dereference
it, better to follow best practices. One of the use after free was
actually an error because we dereference ping_op->log_domain.
Fixes: 658aef0fa1 ('connection: Support connection.ip-ping-addresses')
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
