We need to reset the OVS_PORT and OVS_PORT_UUID variables.
Otherwise, clearing the slave type doesn't work.
On master this is solved differently, by automatically clearing all
variables that are not explicitly set.
Reproducer:
nmcli con del t-eth1
nmcli con add type ethernet autoconnect no ifname eth1 master port0 con-name t-eth1 slave-type ovs-port
echo "
remove ovs-interface
remove connection.master
remove connection.slave-type
print
save
quit
" | nmcli c edit t-eth1
nmcli con show t-eth1 | grep 'ovs\|slave-type'
Fixes: 1440fe6a88 ('ifcfg: don't forget master of ovs interfaces')
https://bugzilla.redhat.com/show_bug.cgi?id=1804167
(cherry picked from commit 0c8046574e)
It is undefined behavior and can lead to crashes or memory corruption.
In practice, this only had an issue on Big Endian systems.
Fixes: fdbf4ae5e6 ('ifcfg-rh: add IPV4_DHCP_TIMEOUT key for ipv4.dhcp-timeout property')
(cherry picked from commit 9b82d29f5f)
(cherry picked from commit fe6c3f0867)
When moving a lease file from initramfs directory to NetworkManager
run directory, SELinux label for that file retains tmpfs_t type.
Fix it by using sendfile() instead of rename(). That way, the
lease file will have the default type: NetworkManager_var_run_t.
Since we take ownership of the lease file, also drop it from the
old location.
* Before the patch:
ls -Z /var/run/NetworkManager/dhclient-*.lease
system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease
* After:
ls -Z /var/run/NetworkManager/dhclient-*.lease
system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease
Fixes: f2fe6c03ee ('manager: don't treat the initramfs-configured DHCP connections as generated')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
(cherry picked from commit ce1f9e6eb9)
(cherry picked from commit abeaf6ffc3)
In the past, kernel (and NetworkManager) did not support the onlink
flags for IPv6 routes. That is no longer the case.
Fixes: f5e8bbc8e0 ('libnm,core: enable "onlink" flags also for IPv6 routes')
(cherry picked from commit e7816a2508)
First I wanted to fix
test:ERROR:../src/ndisc/tests/test-ndisc-fake.c:373:test_preference_changed_cb: assertion failed (_a->timestamp == (data->timestamp1 + 3)): (9 == 10)
but that leads to a different failure:
test:ERROR:../src/ndisc/tests/test-ndisc-fake.c:375:test_preference_changed_cb: assertion failed (_a->lifetime == (9)): (10 == 9)
Instead, the start and end times must match exact (in their duration),
we only allow them to be shifted by up to one second.
Fixes: 8209095ee1 ('ndisc/tests: relax the assertion in "test-ndisc-fake.c"')
(cherry picked from commit b2f03544a7)
(cherry picked from commit 838777a891)
(cherry picked from commit 1470212f4c)
(cherry picked from commit 6f2731b6cb)
By having it a function, the assertion failure does not show the line
number of the origin. Make them a macro, so that we see where exactly it
failed.
(cherry picked from commit 3b896cc642)
(cherry picked from commit b1a7eda71d)
(cherry picked from commit 8316943338)
(cherry picked from commit 017bfbf4d7)
nm_device_cleanup() can be called when the device no longer has an
ifindex. In such case, don't try to reset the MAC address as that
would lead to an assertion failure.
(cherry picked from commit 77b6ce7d04)
(cherry picked from commit 791a888cad)
(cherry picked from commit e1f76e7044)
(cherry picked from commit 5f22c06c53)
We already set the MAC of OVS interfaces in the ovsdb. Unfortunately,
vswitchd doesn't create the interface with the given MAC from the
beginning, but first creates it with a random MAC and then changes it.
This causes a race condition: as soon as NM sees the new link, it
starts IP configuration on it and (possibly later) vswitchd will
change the MAC.
To avoid this, also set the desired MAC via netlink before starting IP
configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1852106https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/483
(cherry picked from commit 47ec3d14d4)
(cherry picked from commit 60d10b146d)
(cherry picked from commit 0139995590)
(cherry picked from commit 69c5c5e767)
When a user creates a ovs-interface with the same name of the parent
ovs-bridge, openvswitch considers the interface as the "local
interface" [1] and assigns the MAC address of the bridge to the
interface [2].
This is confusing for users, as the cloned MAC property is ignored in
some cases, depending on the ovs-interface name.
Instead, detect when the interface is local and set the MAC from the
ovs-interface connection in the bridge table.
[1] https://github.com/openvswitch/ovs/blob/v2.13.0/vswitchd/vswitch.xml#L2546
[2] https://github.com/openvswitch/ovs/blob/v2.13.0/vswitchd/bridge.c#L4744
(cherry picked from commit 5d4c8521a3)
(cherry picked from commit 7548c29a89)
(cherry picked from commit 127294babc)
(cherry picked from commit f54c5400c8)
A connection that fails due to dependency-failed is not able to
reconnect until the master connection activates again; when this
happens, the master clears the blocked reason for all its slaves in
activate_slave_connections() and tries to reconnect them. For this to
work, the slave should be marked as blocked when it fails with
dependency-failed.
(cherry picked from commit 725fed01cf)
(cherry picked from commit e1755048e3)
(cherry picked from commit ecb134ac34)
(cherry picked from commit bb4781cc58)
If the device state change (to disconnected or unmanaged) triggered by
a sleep event happens after the wake, the devices becomes wrongly
unmanaged and it's necessary to manually manage it again, or restart
NM.
During the wake event we should disconnect the device_sleep_cb()
callback for all devices because we don't want to react to state
changes anymore; in particular we don't need to detect when the device
becomes disconnected to unmanage it.
(cherry picked from commit fe2d93980b)
(cherry picked from commit 971897195a)
(cherry picked from commit 7913275b02)
(cherry picked from commit 6d0e8a2acf)
When there are two patch ports connected, each of them must reference
the other; however they can't be created in a single transaction
because they are part of different bridges (so, different
connections). Therefore, the first patch that gets activated will
always fail with "No usable peer $x exists in 'system' datapath" until
the second patch exists.
In theory we could also match the error message, however this doesn't
seem very robust as the message may slightly change in the future.
(cherry picked from commit ffeac35f04)
(cherry picked from commit 75cbf21738)
(cherry picked from commit 399aad15bf)
When the server is restarted the write to unix socket fails with
EPIPE. In such case, don't fail all the calls in queue; instead, after
a sync of the ovsdb state (through a monitor call), start processing
the queue again, including the call that previously failed.
Add a retry counter to avoid that calls are stuck in the queue forever
in a hypothetical scenario in which the write always fails.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/459
(cherry picked from commit db37e530e8)
(cherry picked from commit 54254bf6fe)
If we change the the MTU of an ovs interface only through netlink, the
change could be overridden by ovs-vswitchd at any time when other
interfaces change. Set the MTU also in the ovsdb to prevent such
changes.
Note that if the MTU comes from the connection, we already set the
ovsdb MTU at creation time and so this other update becomes
useless. But it is needed when changing the MTU at runtime (reapply)
or when the MTU comes from a different source (e.g. DHCP).
(cherry picked from commit c2a9712945)
(cherry picked from commit e27a59c69e)
The ovs-vswitchd.conf.db(5) man page says about the the mtu_request
column in the Interface table:
"Requested MTU (Maximum Transmission Unit) for the interface. A
client can fill this column to change the MTU of an
interface [...] If this is not set and if the interface has
internal type, Open vSwitch will change the MTU to match the
minimum of the other interfaces in the bridge."
Therefore, if the connection specifies a MTU, set it early when adding
the interface to the ovsdb so that it will not be changed to the
minimum of other interfaces.
(cherry picked from commit ad12f26312)
(cherry picked from commit 7311d5e294)
Introduce a nm_ovsdb_set_interface_mtu() function to update the MTU of
an ovs interface in the ovsdb.
(cherry picked from commit a4c2c1a843)
(cherry picked from commit c1be15a66e)
When the ovs interface gets deactivated, it is released from the
master port and we call nm_device_update_from_platform_link (dev,
NULL) to ignore any later event for the interface. This is important
especially because it sets a zero ifindex on the interface and so,
later when the link disappears, we don't unmanage the device but
directly remove it.
However, since ovs commands are queued, the link could appear during
the deactivation and we need to ignore such events. Add a new device
method can_update_from_platform_link() for such purpose.
(cherry picked from commit e9fc1dea43)
(cherry picked from commit c4eb0c6852)
Tracking the deletion of link by ifindex is difficult because the
ifindex of the device is updated through delayed (idle) calls in
NMDevice and so there is the possibility that at a certain time the
device ifindex is not in sync with platform state. It seems simpler to
watch instead the interface name. The ugly thing is that the interface
name can be changed externally, but if users do that on an activating
device they are looking for trouble.
Also change the deactivate code to deal with the scenario where we
already created the interface in the ovsdb but the link didn't show up
yet. To ensure a proper cleanup we must wait that the link appears and
then goes away; however the link may never appear if vswitchd sees
only the last state in ovsdb, and so we must use a ugly timeout to
avoid waiting forever.
https://bugzilla.redhat.com/show_bug.cgi?id=1787989
(cherry picked from commit 9c49f8a879)
(cherry picked from commit 2e5e409bf2)
When we deactivate a virtual device, we usually schedule the deletion
of the link in an idle handler. That action will be executed at a
later time when the device is already in the disconnected state.
Similarly, for ovs interfaces we send the deletion command to the
ovsdb and then proceed to the disconnected state.
However, in the first case there is the guarantee that the link will
be deleted at some point, while for ovs interfaces it may happen that
ovs decides to reuse the same link if there is an addition
queued. Since reusing the same link confuses NM, let's implement
deactivate_async() for ovs-interfaces and wait that the link actually
goes away before proceeding.
https://bugzilla.redhat.com/show_bug.cgi?id=1782701https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/402
(cherry picked from commit 623a1e1f99)
(cherry picked from commit a1b0edd24b)
The commit breaks many nmstate CI tests. It also breaks the
autoconnect-slaves functionality: if the master gets reactivated and
the slave was active, the slave is not reconnected.
A different solution is needed for the original issue.
This reverts commit 024e983c8e.
(cherry picked from commit 6e02622f57)
(cherry picked from commit 877599c390)
(cherry picked from commit 359f2ef1f2)
Autoconnect-slaves currently forces an activation of all slaves, even
if there is already an active connection for them. This is bad because
at boot slaves first try to autoconnect, then the autoconnect-slaves
of the master kicks in and disconnects/reactivates them.
The only reason why the forceful reactivation was added was to fix
[1]; in that scenario, a slave connection is already active as
non-slave; then it is updated to be a slave; later, the master with
autoconnect-slaves is manually activated. NetworkManager should detect
that the slave connection must now be activated by autoconnect-slaves.
Add a specific check for such situation, instead of always
reactivating all slaves.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1845018
Fixes: 4985ca5ada ('manager: allow autoconnect-slaves to reconnect the same connection')
(cherry picked from commit 024e983c8e)
(cherry picked from commit d07d515dd7)
(cherry picked from commit 4df63b205e)
For ip-tunnel modes that encapsulate layer2 packets (gretap and
ip6gretap) we allow the presence of an ethernet setting in the
connection and honor the cloned-mac-address specified in it.
For all other modes, the ethernet setting is removed during
normalization, but a value different from 'preserve' could be set via
global default.
The kernel doesn't allow setting a MAC for layer3 devices, don't do
it.
(cherry picked from commit 0494a84878)
(cherry picked from commit 78ed14166c)
(cherry picked from commit d69d92c658)
Expect a failure when writing to /proc if the file system is mounted
read-only.
(cherry picked from commit 211eb3ff8a)
(cherry picked from commit cd056b664b)
Sometimes these function may set errno to unexpected values like EAGAIN.
This causes confusion. Avoid that by using our own wrappers that retry
in that case. For example, in rhbz#1797915 we have failures like:
errno = 0;
v = g_ascii_strtoll ("10", 0, &end);
if (errno != 0)
g_assert_not_reached ();
as g_ascii_strtoll() would return 10, but also set errno to EAGAIN.
Work around that by using wrapper functions that retry. This certainly
should be fixed in glib (or glibc), but the issues are severe enough to
warrant a workaround.
Note that our workarounds are very defensive. We only retry 2 times, if
we get an unexpected errno value. This is in the hope to recover from
a spurious EAGAIN. It won't recover from other errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1797915
(cherry picked from commit 7e49f4a199)
(cherry picked from commit eec2740d71)
Avoid g_ascii_strtoull() calling directly. It has subtle issues, which is why
we have a wrapper for it.
(cherry picked from commit 659ac9cc12)
(cherry picked from commit 62469c1401)
Be more graceful and allow whitespaces around the floating point number
for DEVTIMEOUT. Note that _nm_utils_ascii_str_to_int64() is already graceful
against whitespace, so also be it with the g_ascii_strtod() code path.
(cherry picked from commit 2e4771be5e)
(cherry picked from commit 5a44792e41)
Fail the enslavement of the ovs port if the bridge device is not
found, instead of generating assertions and potentially crash later.
https://bugzilla.redhat.com/show_bug.cgi?id=1797696
Fixes: 101e65d2bb ('ovs: allow changing mac address of bridges and interfaces')
(cherry picked from commit c5c49995b1)
(cherry picked from commit 7494a2e37a)
The previous code tried to get the bridge active connection and it
used the port active connection instead in case of failure. This
doesn't seem right, as in nm-ovsdb.c the bridge AC is used to get the
bridge settings (including the uuid, interface name, and cloned mac).
In case of failure getting the bridge AC we should just fail.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
(cherry picked from commit c8b5a3f91a)
(cherry picked from commit d8fb95d22b)
Surisingly, the compiler may detect the remaining obj_type in
the default switch. Then, inlining nmp_class_from_type() it may detect
that this is only possible to hit with an out or range access to
_nmp_classes array.
Rework the code to avoid that compiler warning. It's either way not
supposed to happen.
Also, drop the default switch case and explicitly list the enum values.
Otherwise it is error prone to forget a switch case.
(cherry picked from commit 9848589fbf)
(cherry picked from commit 6f189da7b6)
curl_multi_setopt() accepts CURLMOPT_* options, not CURLOPT_*
ones. Found by GCC 10:
clients/cloud-setup/nm-http-client.c:700:38: error: implicit conversion from ‘enum <anonymous>’ to ‘CURLMoption’ [-Werror=enum-conversion]
700 | curl_multi_setopt (priv->mhandle, CURLOPT_VERBOSE, 1);
Fixes: 69f048bf0c ('cloud-setup: add tool for automatic IP configuration in cloud')
(cherry picked from commit c11ac34f4c)
(cherry picked from commit 7ba2040caa)
GCC 10 complains about accesses to elements of zero-length arrays that
overlap other members of the same object:
src/platform/nm-platform-utils.c: In function ‘nmp_utils_ethtool_get_permanent_address’:
src/platform/nm-platform-utils.c:854:29: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u8[0]’ {aka ‘unsigned char[0]’} [-Werror=zero-length-bounds]
854 | if (NM_IN_SET (edata.e.data[0], 0, 0xFF)) {
./shared/nm-glib-aux/nm-macros-internal.h:731:20: note: in definition of macro ‘_NM_IN_SET_EVAL_N’
Fix this warning.
(cherry picked from commit d892a35395)
(cherry picked from commit c1417087c8)
GCC 10 complains about accesses to elements of zero-length arrays that
overlap other members of the same object:
src/platform/nm-platform-utils.c: In function ‘ethtool_get_stringset’:
src/platform/nm-platform-utils.c:355:27: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u32[0]’ {aka ‘unsigned int[0]’} [-Werror=zero-length-bounds]
355 | len = sset_info.info.data[0];
| ~~~~~~~~~~~~~~~~~~~^~~
In file included from src/platform/nm-platform-utils.c:12:
/usr/include/linux/ethtool.h:647:8: note: while referencing ‘data’
647 | __u32 data[0];
| ^~~~
Fix this warning.
(cherry picked from commit 16e1e44c5e)
(cherry picked from commit 286bb2f029)
g_ascii_strtoull() returns a guint64, which is very wrong to directly pass
to the variadic argument list of g_object_set(). We expect a guint there
and need to cast.
While at it, use _nm_utils_ascii_str_to_int64() to parse and validate the input.
(cherry picked from commit d506823d4f)
(cherry picked from commit 24177569c1)
