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.
(cherry picked from commit 476c89b6f2)
PyGObject 3.52 switched from gobject-introspection’s libgirepository 1.0
to glib’s libgirepository 2.0. As a result, the Python script would
no longer be able to find the `GIRepository` 2.0 typelib:
(process:1944): GLib-GIRepository-DEBUG: 15:25:14.521: Ignoring GIRepository-2.0.typelib because this libgirepository corresponds to GIRepository-3.0.typelib
We could update the script to support both versions of the typelib
but it is not really necessary. It was only used to add extra directories
from `$LD_LIBRARY_PATH` and the CLI argument to repository’s library path
but libgirepository already supports using `LD_LIBRARY_PATH` directly:
https://docs.gtk.org/girepository/method.Repository.prepend_library_path.html
(cherry picked from commit 12eff9a7fd)
When a software device becomes deactivated, we check whether it can
be unrealized (= deleted in kernel), by calling function
delete_on_deactivate_check_and_schedule().
The function returns without doing anything if there is a new
activation enqueued on the device (priv->queued_act_request), because
in that case the device will be reused for the next activation.
This commit fixes a problem seen in NMCI test
@ovs_delete_connecting_interface: sometimes the device is not
unrealized after deleting the connection. That happens because if the
queued activation fails, we never try again to unrealize the device.
Fix that by calling delete_on_deactivate_check_and_schedule() when
there is a failure starting the queued activation.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2258
(cherry picked from commit 0b03614b68)
(cherry picked from commit 1f23bb18ad)
Commit c5d1e35f99 ('device: support reapplying bridge-port VLANs')
didn't update can_reapply_change() to accept the "bridge-port.vlans"
property during a reapply. So, it was only possible to change the
bridge port VLANs by updating the "bridge.vlan-default-pvid" property
and doing a reapply. Fix that.
Fixes: c5d1e35f99 ('device: support reapplying bridge-port VLANs')
(cherry picked from commit 261fa8db33)
(cherry picked from commit c647c060d6)
If the bridge default-pvid is zero, it means that the default PVID is
disabled. That is, the bridge PVID is not propagated to ports.
Currently NM tries to merge the existing bridge VLANs on the port with
the default PVID from the bridge, even when the PVID is zero. This
causes an error when setting the new VLAN list in the kernel, because
it rejects VLAN zero.
Skip the merge of the default PVID when zero.
Fixes: c5d1e35f99 ('device: support reapplying bridge-port VLANs')
(cherry picked from commit bf79fbd678)
(cherry picked from commit 956f9ba365)
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
(cherry picked from commit 46e0d2b4e4)
(cherry picked from commit dd0ca122e3)
Fix the following:
../src/core/nm-connectivity.c:958:1: warning: ‘check_platform_config’ defined but not used [-Wunused-function]
958 | check_platform_config(NMConnectivity *self,
| ^~~~~~~~~~~~~~~~~~~~~
Fixes: 91d447df19 ('device: don't start connectivity check on unconfigured devices')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2224
(cherry picked from commit 1253cbad5a)
(cherry picked from commit c1d94d7081)
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
(cherry picked from commit fd3eccfb16)
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')
(cherry picked from commit 94595332c4)
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')
(cherry picked from commit 6f6bb17a28)
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
(cherry picked from commit aeaf8ca23c)
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
(cherry picked from commit 14106431fb)
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
(cherry picked from commit 37d8945b13)
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')
(cherry picked from commit 163c2574d8)
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')
(cherry picked from commit 9edfc0438c)
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')
(cherry picked from commit ae7de5b353)
Add some missing "(nullable)" annotations to parameters of the
callback functions in NMSecretAgentOld. Otherwise, PyGObject complains
that those parameters cannot be NULL when implementing a secret agent.
Fixes: d595f7843e ('libnm: add libnm/libnm-core (part 1)')
(cherry picked from commit c01168f4f9)
When a device in IPv6 shared mode obtains a prefix, it adds a new l3cd
of type L3_CONFIG_DATA_TYPE_PD_6 for that prefix. However, that l3cd
is never removed later and so the address lingers on the interface
even after the connection goes down. Remove the l3cd on cleanup.
(cherry picked from commit 4a8bedcd89)
When a WG connection is connecting to an IPv6 endpoint, configures a
default route, and firewalld is active with IPv6_rpfilter=yes, it never
handshakes and doesn't pass traffic. This is because firewalld has a
IPv6 reverse path filter which is discarding these packets.
Thus, we add some firewall rules whenever a WG connection is brought up
that ensure the conntrack mark and packet mark are copied over.
These rules are largely inspired by wg-quick:
https://git.zx2c4.com/wireguard-tools/tree/src/wg-quick/linux.bash?id=17c78d31c27a3c311a2ff42a881057753c6ef2a4#n221
(cherry picked from commit db557908a2)
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".
(cherry picked from commit 79b1877c02)
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.
(cherry picked from commit 0540b3c9bc)
We're going to create connections on wired devices for OCI VM VNICs, and
they're going to also need the same user setting. Factor it out.
(cherry picked from commit 93960639e8)
