The validation of embedded NUL character was skipped due to the wrong
order of arguments to memchr(). Fix it.
Fixes: 4043f82790 ('lldp: cleanup converting binary LLDP fields to string')
(cherry picked from commit ce17284c3f)
Linux UIDs/GIDs are 32-bit unsigned integer, with 4294967295 reserved
as undefined.
Before:
# useradd -u 4294967294 -M testuser
useradd warning: testuser's uid -2 outside of the UID_MIN 1000 and UID_MAX 60000 range.
# nmcli connection add type tun ifname tun1 owner 4294967294 ipv4.method disabled ipv6.method disabled
Error: Failed to add 'tun-tun1' connection: tun.owner: '4294967294': invalid user ID
After:
# useradd -u 4294967294 -M testuser
useradd warning: testuser's uid -2 outside of the UID_MIN 1000 and UID_MAX 60000 range.
# nmcli connection add type tun ifname tun1 owner 4294967294 ipv4.method disabled ipv6.method disabled
Connection 'tun-tun1' (5da24d19-1723-45d5-8e04-c976f7a251d0) successfully added.
# ip -d link show tun1
2421: tun1: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 500
link/none promiscuity 0 allmulti 0 minmtu 68 maxmtu 65535
tun type tun pi off vnet_hdr off persist on user testuser ...
^^^^^^^^^^^^^
Fixes: 1f30147a7a ('libnm-core: add NMSettingTun')
(cherry picked from commit 253800238e)
Currently the bug is hidden because the macro is only called with
NM_SETTING_BOND_OPTION_ARP_IP_TARGET.
Fixes: 45c95e9314 ('device/bond: rework setting of arp_ip_target bond options')
(cherry picked from commit 1229fe5abd)
When resolving the system hostname from DNS lookup, we use
nm_utils_validate_hostname() which checks that the result is a valid
hostname. A valid hostname is at most 64 characters on Linux. Anything
longer is discarded.
However, the reverse DNS lookup doesn't return a hostname, it returns
a DNS name. The DNS name can have multiple labels, each limited to 63
characters. The maximum length of the DNS name is 253 characters.
If the result is longer than 64 characters because it has multiple
labels, we should still accept it, provided that it is a valid DNS
name. Then when setting the hostname in the system, only the first
label will be kept.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2243
Resolves: https://issues.redhat.com/browse/RHEL-104357
(cherry picked from commit b019883a9a)
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)
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)
Currently, when a call to Reapply() results in stage3 being re-run, IPv6
ends up messed up. Like this:
$ nmcli device modify eth0 ipv4.address ''
$ nmcli device modify eth0 ipv4.address 172.31.13.37/24
$
NetworkManager[666]: <debug> [1751286095.2070] device[c95ca04a69467d81] (eth0): ip4: reapply...
...
NetworkManager[666]: <debug> [1751286095.2104] device[c95ca04a69467d81] (eth0): ip6: addrgenmode6: set none (already set)
NetworkManager[666]: <debug> [1751286095.2105] device[c95ca04a69467d81] (eth0): ip6: addrgenmode6: toggle disable_ipv6 sysctl after disabling addr-gen-mode
NetworkManager[666]: <debug> [1751286095.2105] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/eth0/disable_ipv6' to '1' (current value is '0')
NetworkManager[666]: <debug> [1751286095.2106] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/eth0/disable_ipv6' to '0' (current value is '1')
NetworkManager[666]: <debug> [1751286095.2106] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/eth0/accept_ra' to '0' (current value is identical)
NetworkManager[666]: <debug> [1751286095.2106] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/eth0/disable_ipv6' to '0' (current value is identical)
Not only is this unnecessary because addr-gen-mode already has the
desired value (as is logged), but also wipes off all IPv6 configuration.
This is fine on initial configuration, but not on Reapply().
Let's look at the device state first: if we've progressed past ip-config
state, then we can't possibly ever touch the offending sysctls. It's
okay -- we don't need to: addr-gen-mode is going to be set right if we
went through ip-config before.
Resolves: https://issues.redhat.com/browse/NMT-1681https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2232
(cherry picked from commit 9bbb113987)
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, ...
(cherry picked from commit 6f219aa649)
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)
It is not clear whether we can actually respect this value. For example,
we should not restore the kernel's default value on deactivation or
device's state change, but it is unclear if we can ensure that we'll
still have the connection's configuration in all possible changes of
state.
Also, it is unclear if it's a desirable value that we want to support.
At this point it is mostly clear that trying to configure NM managed
devices externally always ends being dissapointing, no matter how hard
we try.
Remove this value for now, while we discuss whether it makes sense or
not, so it doesn't become stable in the new 1.54 release.
(cherry picked from commit 82692cc75c)
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')
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.
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.
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')
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')
If we cannot get current FEC value probably we won't be able to set it a
few lines later. Also, if it fails to set, we try to use the value of
the old one that we tried to retrieve without success. In that case, the
variable old_fec_mode would be uninitialized. Fix it by returning early
if we cannot get the current value.
Fixes: 19bed3121f ('ethtool: support Forward Error Correction(fec)')
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.
When the carrier of an interface goes down, we defer the handling of
that event by some time (by default 6 seconds), to detect if the
carrier change was a spurious event.
It was observed that in some conditions the carrier goes down and we
register the timer for the deferred action on the device. Then the
link is deleted and recreated. At this point the timer fires and
aborts the new activation of the device.
Once the ifindex changes, cancel the timer for the deferred
carrier-down action.
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
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
The point is to get rid of device/connection type specific arguments, to
eventually be able to complete the connection on AddAndActivate before knowing
which factory is going to take care of creating the device.
Aside from that, the whole thing is pretty awful -- with complicated
macros and variadic argument (ugh). Let's get rid of that.
All of these are wrong asserting that a connection has a particular
setting. On AddAndActivate, the connection can be pretty much empty:
impl_manager_add_and_activate_connection ()
validate_activation_request ()
nm_manager_get_best_device_for_connection ()
iface = nm_manager_get_connection_iface ()
find_parent_device_for_connection ()
nm_device_factory_get_connection_parent () <====== *shriek*
nm_device_factory_get_connection_iface ()
find_device_by_iface (iface)
nm_device_complete_connection ()
Remove those assertions.
Some of them are wrong: they assert a connection has a particular
setting even though this can be called on AddAndActivate against a
connection that is not complete or normalized:
impl_manager_add_and_activate_connection ()
validate_activation_request ()
nm_manager_get_best_device_for_connection ()
iface = nm_manager_get_connection_iface ()
find_parent_device_for_connection ()
nm_device_factory_get_connection_parent ()
nm_device_factory_get_connection_iface () <====== here
find_device_by_iface (iface)
nm_device_complete_connection ()
Fix those by removing the assertions.
Some of them are also fall back to just calling
nm_connection_get_interface_name() which is a pretty useless thing to do
because nm_device_factory_get_connection_iface() only calls the
device-specific routine if nm_device_factory_get_connection_iface()
doesn't return anything, to give the factory a chance to make up a name
(like <parent>.<vlan-id> for Vlan) on its own. Drop those.
In the scenario for sending the release message, we need to guarantee
that NM only sends the release message when the client received a lease
from the server. However, there is some distinction between the
`l3cd_curr` and `l3cd_next` when ACD is pending, because `l3cd_curr` is
NULL but `l3cd_next` is not NULL when ACD is pending. Regardless of
whether ACD is pending or completed, these are all considered the client
have received the release from the server. Therefore, adapt the function
`nm_dhcp_client_get_lease()` to control whether to get next or current
lease.
