Break the loop as soon as we've found the value.
Fixes: 19bed3121f ('ethtool: support Forward Error Correction(fec)')
(cherry picked from commit 245f0e0b35)
(cherry picked from commit 094a542546)
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)')
(cherry picked from commit cbdd0d9cca)
(cherry picked from commit b7e34f225a)
Introducing support of ethtool FEC mode:
D-BUS API: `fec-mode: uint32_t`.
Keyfile:
```
[ethtool]
fec-mode=<uint32_t>
```
nmcli: `ethtool.fec-mode` allowing values are any combination of:
* auto
* off
* rs
* baser
* llrs
Unit test cases included.
Resolves: https://issues.redhat.com/browse/RHEL-24055
Signed-off-by: Gris Ge <fge@redhat.com>
(cherry picked from commit 19bed3121f)
The variable 'change' may be used uninitialized.
Fixes: 7acc66699a ('policy: always reset retries when unblocking children or ports')
(cherry picked from commit af6aca3527)
(cherry picked from commit 949c7b84a3)
An IPv6 endpoint is not usable until the address is non-tentative. Add
a mechanism to wait until the address is ready.
(cherry picked from commit 227cd6307b)
(cherry picked from commit ceef38d9a5)
Skip the configuration of the MPTCP endpoint when the address is in
the l3cd but is not yet configured in the platform. This typically
happens when IPv4 DAD is enabled and the address is being probed.
If we configure the endpoint without the address set, the kernel will
try to use the endpoint immediately but it will fail. Then, the
endpoint will not be used ever again after the address is added.
(cherry picked from commit 6bf859af79)
(cherry picked from commit 2c5a51201d)
The name suggests that the function always removes all the watchers
with the given tag; instead it removes only "dirty" ones when the
"all" parameter is FALSE. Split the function in two variants.
(cherry picked from commit b6e67c6abc)
(cherry picked from commit a301c259f2)
Preventing the activation of unavailable devices for all device types is
too aggresive and leads to race conditions, e.g when a non-virtual bond
port gets a carrier, preventing the device to be a good candidate for
the connection.
Instead, enforce this check only on OVS interfaces as NetworkManager
just makes sure that ovsdb->ready is set to TRUE.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2139
Fixes: 774badb151 ('core: prevent the activation of unavailable devices')
(cherry picked from commit a1c05d2ce6)
(cherry picked from commit b8ef2a551e)
When calling activate_port_or_children_connections() we are unblocking
the ports and children but we are not resetting the number of retries if
it is an internal activation.
This is wrong as even if it's an internal activation the number of
retries should be reset. It won't interferfe with other blocking reasons
like USER_REQUESTED or MISSING_SECRETS.
(cherry picked from commit 7acc66699a)
(cherry picked from commit 2daeef668d)
When autoconnecting ports of a controller, we look for all candidate
(device,connection) tuples through the following call trace:
-> autoconnect_ports()
-> find_ports()
-> nm_manager_get_best_device_for_connection()
-> nm_device_check_connection_available()
-> _nm_device_check_connection_available()
The last function checks that a specific device is available to be
activated with the given connection. For virtual devices, it only
checks that the device is compatible with the connection based on the
device type and characteristics, without considering any live network
information.
For OVS interfaces, this doesn't work as expected. During startup, NM
performs a cleanup of the ovsdb to remove entries that were previously
added by NM. When the cleanup is terminated, NMOvsdb sets the "ready"
flag and is ready to start the activation of new OVS interfaces. With
the current mechanism, it is possible that a OVS-interface connection
gets activated via the autoconnect-ports mechanism without checking
the "ready" flag.
Fix that by also checking that the device is available for activation.
(cherry picked from commit 774badb151)
Rename "unavailable_devices" to "exclude_devices", as the
"unavailable" term has a specific, different meaning in NetworkManager
(i.e. the device is in the UNAVAILABLE state). Also, use
nm_g_hash_table_contains() when needed.
(cherry picked from commit 6c1eb99d32)
Using `n_dhcp4_c_connection_start_request()` will cause staying in
`connection->request`, as a result, it will cause the resending of
DHCPRELEASE and DHCPDECLINE message, thus, use
`n_dhcp4_c_connection_send_request()` directly instead to avoid
unnecessary retransmission timeout, as suggested by
f030927a54 (r1531834009).
(cherry picked from commit 55710d3d7c)
We should not send the DHCP release message when udp socket is still in
the PACKET state, this state is typically used during the discovery and
offer phases, where the client broadcasts DHCP packets like DHCPDISCOVER
and receives responses like DHCPOFFER. At this point, the client has no
lease because it has not yet completed the DHCP handshake.
(cherry picked from commit bccf031591)
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.
(cherry picked from commit 5993ee8a8a)
Old branches tend to be formatted with a different versions of
clang-format, so when patches are backported, they introduce some
differences in formatting, making the check-tree job to fail.
These changes in formatting are normally small, and we don't pay much
attention to them, causing that the pipelines are always red, increasing
the work required to check if there are important failures or not.
Make check-tree optional for branches other than main. This way,
failures will be shown as a "warning", and if a pipeline only shows a
warning we don't need to inspect it.
(cherry picked from commit 9e47c9bc6a)
Previously, NM create direct route to gateway to main(254) route table
regardless `ipvx.route-table` value.
Fixed by setting `NMPlatformIP4Route.table_any` to `TRUE`.
Resolves: https://issues.redhat.com/browse/RHEL-69901
Signed-off-by: Gris Ge <fge@redhat.com>
(cherry picked from commit 6d06286f1d)
ci-templates only supported alpine:latest, but support for any other
version has been introduced. Use it so our Alpine pipelines stop
failing.
(cherry picked from commit 9354fabaa8)
When a bond in balance-slb is created, the ports are enabled or disabled
based on carrier and link state. If the link/carrier goes down, the port
becomes disabled and we must make sure the MAC tables of the switches
are updated properly so the traffic is redirected.
In order to solve this, we send a GARP or RARP broadcast packet on the
bond. This fix cover 3 different balance-slb scenarios.
Scenario 1: The bond in balance-slb mode has IPv4 address configured and
some ports connected. Here the bond is acting like active-backup as the
packets will always have as source MAC the address of the bond
interface. When a port goes down, NetworkManager will send a GARP
broadcast announcing the address configured on the bond with the MAC
address configured on the port.
Scenario 2: The bond in balance-slb mode is connected to a bridge and has
some ports connected. The bridge has IPv4 configured. When a port goes
down, NetworkManager will send a GARP broadcast announcing the address
configured on the bridge with the MAC address configured on the port.
Scenario 3: The bond in balance-slb mode is connected to a bridge and
has some ports connected. The bridge does not have IP configuration and
therefore everything is L2. When a port goes down, NetworkManager will
query the FDB table and filter the entries by the ones belonging to the
bridge and the bond ifindexes. Then, it will send a RARP broadcast
announcing every learned MAC address from FDB.
Fixes: e9268e3924 ('firewall: add mlag firewall utils for multi chassis link aggregation (MLAG) for bonding-slb')
(cherry picked from commit 3f2f922dd9)
The function introduced queries the FDB table via netlink socket. It
accepts a list of ifindexes to filter out the FDB content not related to
it. It returns an array of MAC addresses.
To cltarify this function is unusually exposed directly on
nm-linux-platform.h as we don't want this be part of the whole
NMPlatform object or cache. This, is an exception to the rule to
simplify the integration of this functionality on NetworkManager.
In addition, it also doesn't use the async mechanism that is widely used
on netlink communication across nm-linux-platform. Again, the reason is
to simplify its use, as async communication won't provide a benefit to
the use cases we have planned for this, i.e balance-slb RARP announcing.
(cherry picked from commit 00f47efcb2)
Add a hash generation helper for NMEtherAddr struct. This can be used
for HashTables containing pointers to NMEtherAddr structs.
(cherry picked from commit a63eec924c)
This function would be useful when performing operations related to the
IPv4 addresses configured on the l3cfg. E.g this function will be used
for getting the IPv4 to announce on a GARP on bonding-slb when one of
the ports failover.
(cherry picked from commit 69f3493670)
The regex for "Fixes" also matches with "Ignore-Fixes", so the commit is
added twice and then removed only once by the "Ignore-Fixes". It still
remains once in the list of commits to backport, making that
"Ignore-Fixes" does not work. Fix it.
