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)
The 'peer' property of ovs-patch is inserted into the 'options' column
of the ovsdb 'Interface' table. The ovs-vswitchd.conf.db man page says
about it:
options : peer: optional string
The name of the Interface for the other side of the patch. The
named Interface’s own peer option must specify this Interface’s
name. That is, the two patch interfaces must have reversed name
and peer values.
Therefore, it is wrong to validate the peer property as an IP address
and document it as such.
Backport: note that on nm-1-22, we have nm_utils_ifname_valid() function
for validating OVS interface names. We don't have that here, so we
re-implement the name validation differently.
Fixes: d4a7fe4679 ('libnm-core: add ovs-patch setting')
(cherry picked from commit beb1dba8c1)
(cherry picked from commit 5598c039e4)
(cherry picked from commit 9b82c62f33)
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)
Fixes: 2a4fb75d3b ('ifcfg: add support for "802-1x.system-ca-certs" setting')
(cherry picked from commit b4537f2c03)
(cherry picked from commit 5d8a0837b3)
(cherry picked from commit e11232de96)
Fixes: a83ab252ee ('ifcfg-rh: add support for 802-1x.password-raw property')
(cherry picked from commit 9fde21504e)
(cherry picked from commit 36ddd266a5)
(cherry picked from commit 52bb253f6b)
S390 options are stored in a separate [ethernet-s390-options] section.
This group must not be interpreted as a NMSetting name, otherwise we
log a bogus warning:
<warn> [1590523563.7757] keyfile: ethernet-s390-options: invalid setting name 'ethernet-s390-options'
Fixes: cf9b8d3bad ('libnm/keyfile: implement ethernet.s390-options in keyfile')
(cherry picked from commit 82a468c9ad)
(cherry picked from commit d611647997)
(cherry picked from commit e9f2831ab5)
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)
Otherwise the function is not usable via generated bindings.
Fixes: 9b9dce9486 ('all: add 'match' setting')
(cherry picked from commit 180cda7632)
(cherry picked from commit 805adec9ca)
(cherry picked from commit b5a66b88b3)
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)
