There isn't any 'host-name' option for DHCPv6. Read instead the
'fqdn-fqdn' option that carries the FQDN assigned by the server to the
client.
(cherry picked from commit 1f74ea52f5)
(cherry picked from commit 4e1da002a9)
(cherry picked from commit 7c46ff24e5)
The dhclient backend already exports all the option passed by
dhclient, including the FDQN. Export it also for the systemd backend.
(cherry picked from commit 1621a6ddb1)
(cherry picked from commit c6a7618f2b)
(cherry picked from commit 293b00c947)
Parse option 39 (Client Fully Qualified Domain Name, RFC 4704) from the DHCP
reply, which specifies the FQDN assigned by the server to the client.
c43eea9f2e
(cherry picked from commit 813fb7d64e)
(cherry picked from commit 504a3486ed)
Assertions are for programming errors; here the input comes directly
from the DHCP response packet.
af710b535b
(cherry picked from commit e2248143af)
(cherry picked from commit 555c7e4ee6)
Fixes: 5e71f01605 ('device: merge stage3 and stage4 ip-config function for IPv4 and IPv6')
(cherry picked from commit a017936223)
(cherry picked from commit 0adfcadc9d)
(cherry picked from commit 1438d5a9f0)
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)
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)
The matchfilecon API is deprecated for a very long time. Since selinux 3.1
the functions are also marked as deprecated in the header, which causes
compiler warnings and build failures.
Update the code to use selabel API instead.
(cherry picked from commit 173533c3b2)
(cherry picked from commit f5aafb9da4)
(cherry picked from commit bde9f1023f)
On Ubuntu 20.10, we build against ModemManager 1.14.0 and get a compiler warning:
../src/devices/wwan/nm-modem-broadband.c: In function 'try_create_connect_properties':
../src/devices/wwan/nm-modem-broadband.c:492:2: error: 'MMModemCapabilityDeprecated' is deprecated [-Werror=deprecated-declarations]
492 | if (MODEM_CAPS_3GPP (ctx->caps)) {
| ^~
Suppress it.
An alternative would be to drop the flag entirely. It seems the flag
was never used (and never will be used). But if that's true, there is
little harm done checking it. If it's not true, we better keep checking
for older versions.
0cd76bf1c4
(cherry picked from commit 03dc759026)
(cherry picked from commit 12e4a4a5df)
(cherry picked from commit b672944603)
Avoids a compiler warning:
../src/devices/nm-device.c:16079:26: error: cast to smaller integer type 'NMDeviceStateReason' from 'gpointer' (aka 'void *') [-Werror,-Wvoid-pointer-to-enum-cast]
deactivate_ready (self, (NMDeviceStateReason) reason);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 121c58f0c4 ('core: set number of SR-IOV VFs asynchronously')
(cherry picked from commit 918ebd600a)
(cherry picked from commit 32641b9fca)
(cherry picked from commit c24888be51)
On master this code was refactored and thereby the leak was
fixed. Instead of backporting that, do an original patch for
nm-1-24 to fix only the leak.
Fixes: 121c58f0c4 ('core: set number of SR-IOV VFs asynchronously')
(cherry picked from commit a28d4a305a)
This is a serious issue, because this is not guaranteed to be UTF-8
data.
Fixes: 07a9364d9c ('device: export list of LLDP neighbors through D-Bus')
(cherry picked from commit 8cd9b87c91)
(cherry picked from commit 94f8e9fbdc)
Reported by coverity:
>>> CID 210222: Null pointer dereferences (NULL_RETURNS)
>>> Dereferencing a pointer that might be "NULL" "f" when calling
"fseek".
Fixes: ac5206aa9c ('2007-11-21')
(cherry picked from commit 581aa981c2)
(cherry picked from commit bb40de0ca0)
It's unnecessary and makes the function unnecessarily not thread safe.
Of course, also ndp_msg_opt_route_prefix() uses static variables, so
it's still not thread safe.
Fixes: c3a4656a68 ('rdisc: libndp implementation')
(cherry picked from commit fbb65de32e)
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)
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)
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)
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)
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)
NetworkManager can't control the name of the PPP interface name
created by pppd; so it has to wait for the interface to appear and
then rename it. This happens in nm_device_take_over_link() called by
nm-device-ppp.c:ppp_ifindex_set() when pppd tells NM the ifindex of
the interface that was created.
However, sometimes the initial interface name is already correct, for
example when the connection.interface-name is ppp0 and this is the
first PPP interface created.
When this happens, nm_device_update_from_platform_link() is called on
the NMDevicePPP and it sets the device ifindex. Later, when pppd
notifies NM, nm_device_take_over_link() fails because the ifindex is
already set:
nm_device_take_over_link: assertion 'priv->ifindex <= 0' failed
Make nm_device_take_over_link() more robust to cope with this
situation.
https://bugzilla.redhat.com/show_bug.cgi?id=1849386
(cherry picked from commit 75bc21c4cf)
(cherry picked from commit 72d66fffac)
(cherry picked from commit 684a1a06cc)
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)
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)
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)
When the interface is in IPv4 or IPv6 shared mode and the user didn't
specify an explicit zone, use the nm-shared one.
Note that masquerade is still done through iptables direct calls
because at the moment it is not possible for a firewalld zone to do
masquerade based on the input interface.
The firewalld zone is needed on systems where firewalld is using the
nftables backend and the 'iptables' binary uses the iptables API
(instead of the nftables one). On such systems, even if the traffic is
allowed in iptables by our direct rules, it can still be dropped in
nftables by firewalld.
(cherry picked from commit 3e2b723532)
(cherry picked from commit 13438e041a)
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)
If a device only has an IPv6 link-local address, we don't generate an
assumed connection. Therefore, when a new slave connection (without IP
configuration) is activated on the device, we don't deactivate any
existing connection and the link-local address remains configured.
The IP configuration of an activated slave should be predictable and
not depend on the previous state; let's flush addresses and routes on
activation.
https://bugzilla.redhat.com/show_bug.cgi?id=1816517https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/480
(cherry picked from commit e302f5ff77)
(cherry picked from commit 0344a97105)
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)
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)
