Calling c_list_link_tail() on a list entry that already belongs to
another list corrupts the other list, in this case 'old_lst_head';
this is explained in the documentation of c_list_link_before():
* @what is not inspected prior to being linked. Hence, it better not
* be linked into another list, or the other list will be corrupted.
This can be reproduced by invoking "nmcli device wifi rescan ssid x"
multiple times; in this way, _scan_request_ssids_track() reuses the
previous SSID data, the list gets corrupted and this causes a crash.
Fixes: 7500e90b53 ('wifi: rework scanning of Wi-Fi device')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2076
After upgrading to RHEL-9.4, customers have reported that `ip monitor`
repeatedly logs the same route additions every 30 seconds. This issue
appears to stem from NetworkManager continually retrying to add the same
routes due to keep retrying Address Conflict Detection (ACD) on NOARP
interfaces.
To prevent unnecessary route additions and reduce log noise, this change
modifies NetworkManager's behavior to stop retrying ACD on interfaces
with the NOARP flag.
This fix addresses route instability and excessive logging for affected
NOARP configurations.
https://issues.redhat.com/browse/RHEL-59125
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>
We have encountered multiple incidents where users face connectivity
issues after booting, particularly due to hardware like switches that do
not pass traffic for a few seconds after startup. And services such as
NFS fail to mount because they try to initiate before the network is
fully reachable. Therefore, we are supporting
`connection.ip-ping-addresses` and `connection.ip-ping-timeout` to
allow administrators to configure the network to verify connectivity to
a specific target(such as a service like NFS) instead of relying on
gateway reachability, which may not always be relevant in certain
network configurations.
Resolves: https://issues.redhat.com/browse/RHEL-21160https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2034https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1797
Since we are adding the ping check for the connection.ip-ping-addresses,
it makes more sense to improve the logging to differentiate between the
started ping operations for gateway and connection.ip-ping-addresses.
When there is a non-empty internal configuration file, print it in the
output of "NetworkManager --print-config".
Before:
NetworkManager --print-config:
# NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf, /usr/lib/NetworkManager/conf.d/{00-server.conf,22-eth-mac-addr.conf}
...
After:
NetworkManager --print-config:
# NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf, /usr/lib/NetworkManager/conf.d/{00-server.conf,22-eth-mac-addr.conf}, /var/lib/NetworkManager/NetworkManager-intern.conf
...
Tests needs to be changed because now writing to the internal file
causes a change of the description of the NMConfigData and therefore
the NM_CONFIG_CHANGE_CONFIG_FILES flag is set.
The tracking of variable "has_intern" in intern_config_read() is
wrong: we set it when adding any entry to the keyfile, but then we
remove the global DNS section without updating the variable.
The effect is that the function might return an empty keyfile instead
of NULL.
Fix this by moving the check on global DNS above.
Fixes: 55c204b9a3 ('core: add support for reading global DNS configuration from keyfile')
In the output of "NetworkManager --print-config" we currently print
the list of configuration snippets in an abbreviated form:
... (lib: 00-server.conf, 22-wifi-mac-addr.conf) (etc: 08-unmanaged.conf)
While it is concise and unambiguous, it can be cryptic for
users. Instead, print the full paths:
... /usr/lib/NetworkManager/conf.d/{00-server.conf,22-wifi-mac-addr.conf}, /etc/NetworkManager/conf.d/{08-unmanaged.conf}
The user does not want to send machine hostname to the DHCP server
globally by default to avoid ddns record getting created in IPAM.
otherwise, IPAM creates ddns records which might interfere with user's
regular host record. Thus, introduce the ternary property
dhcp_send_hostname_v2 to warrant this behavior.
Notice that we set the GSpec of dhcp-send-hostname-v2 to int, because
defining it as enum would make that it cannot be expanded in a backwards
compatible way if we need to add more values: old clients using libnm
would reject it due to the new value being unknown. Follow the same
strategy than _nm_setting_property_define_direct_enum, defining the
NMSettInfoPropertType as enum, but the glib's GSpec as int.
Resolves: https://issues.redhat.com/browse/RHEL-56565https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2029https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1765
When the "ipvX.routed-dns" property is set to true, add a route for
each DNS server via the current interface. The feature works in the
following way.
A new routing rule is created ("priority $PRIO not fwmark $MARK lookup
$TABLE") where $PRIO, $MARK and $TABLE are fixed values and are the
same for all interfaces. This rule is evaluated before standard rules
and tries to look up routes in table $TABLE, where NM adds the routes
to DNS servers.
To determine the next-hop to the name server, NM issues a RTM_GETROUTE
netlink request to kernel, specifying to return the route via the
current interface. In order to avoid results from $TABLE, NM also sets
the fwmark as $MARK in the request.
I think the current semantics of the NMDevice's "l3cd-changed" signal
is not useful, as it reports that the layer-3 configuration changed
before it is committed to platform.
In this way, the only current subscriber (NMPolicy), reacts to the
change too early: it updates the DNS servers in the system when the
interface doesn't have yet addresses and routes ready. Therefore, the
resolver (libc, systemd-resolved, ...) will try to contact the DNS
server using the wrong parameters.
Change the semantics so that the signal is emitted *after* the commit
to platform.
During a commit of layer-3 configuration, multiple signals are
emitted:
- if the combined l3cd configuration changes, we first emit a
L3CD_CHANGED signal, with flag `commited` FALSE;
- if the previously committed configuration is different from the one
we want to commit, we emit again the same signal with `commited`
TRUE;
- a PRE_COMMIT signal
- a POST_COMMIT signal
The usefulness of the first and third signals is questionable: there
is no need to signal that the configuration changes if we are not
going to commit it. Also, PRE_COMMIT is redundant as we just emitted
L3CD_CHANGED. Nobody is using those 2 signals.
Simplify this by leaving only PRE_COMMIT and POST_COMMIT, which are
always emitted during a commit and provide information on the l3cd
changes.
This commit doesn't change behavior.
When performing integration tests for the IPv6-only DHCP option, we
want to test that the option is honored and that NM restarts DHCP if
the option goes away. However, the minimum wait time according to the
RFC is 5 minutes, which makes the test take long time.
Allow changing the value via the "NM_TEST_IPV6_ONLY_MIN_WAIT"
environment variable.
Add support for handling the IPv6-Only Preferred option. When enabled,
the client adds the option code to the "Parameter Request List" option
of the DHCPDISCOVER and DHCPREQUEST messages. If the server sends the
option back in the DHCPOFFER and DHCPACK, the host stops the DHCP
client for the time interval specified in the option. After the
timeout expires, DHCP is restarted.
In the next commit, a mechanism will be added to stop the DHCP plugin
and restart it without destroying the NMDhcpClient object. For this to
work, we must reset some members of the object when stopping or
starting the plugin.
Add a new "ipv4.dhcp-ipv6-only-preferred" property to control the
"IPv6-Only Preferred" DHCPv4 option (RFC 8925). The option indicates
that a host supports an IPv6-only mode and is willing to forgo
obtaining an IPv4 address if the network provides IPv6 connectivity.
Store the effective IP method computed by evaluating the profile,
checking kernel support, or querying device's method
get_ip_method_auto().
The value will be used in a next commit to enable or disable features.
NetworkManager current code will refuse to activate a connection if its
interface has no SRIOV capacity but holding a empty SRIOV settings.
This patch only valid SRIOV capacity when it is enabled(total_vfs > 0).
Resolves: https://issues.redhat.com/browse/RHEL-58397
Signed-off-by: Gris Ge <fge@redhat.com>
Add chains and rules to steer the IGMP reports to the primary member
port. This rules are adapted from the script provided by Eric Garver.
https://gitlab.com/egarver/virtual-networking/-/blob/master/mlag.sh
Fixes: e9268e3924 ('firewall: add mlag firewall utils for multi chassis link aggregation (MLAG) for bonding-slb')
When the attach_port()/detach_port() methods do not return immediately
(currently, only for OVS ports), the following situation can arise:
- nm_device_controller_attach_port() starts the attachment by sending
the command to ovsdb. Note that here we don't set
`PortInfo->port_is_attached` to TRUE yet; that happens only after
the asynchronous command returns;
- the activation of the port gets interrupted because the connection
is deleted;
- the port device enters the deactivating state, triggering function
port_state_changed()
- the function calls nm_device_controller_release_port() which checks
whether the port is already attached; since
`PortInfo->port_is_attached` is not set yet, it assumes the port
doesn't need to be detached;
- in the meantime, the ovsdb operation succeeds. As a consequence,
the kernel link is created even if the connection no longer exists.
Fix this by turning `port_is_attached` into a tri-state variable that
also tracks when the port is attaching. When it is, we need to perform
an explicit detach during deactivation.
Fixes: 9fcbc6b37d ('device: make attach_port() asynchronous')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2043
Resolves: https://issues.redhat.com/browse/RHEL-58026
This patch add support to IPVLAN interface. IPVLAN is a driver for a
virtual network device that can be used in container environment to
access the host network. IPVLAN exposes a single MAC address to the
external network regardless the number of IPVLAN device created inside
the host network. This means that a user can have multiple IPVLAN
devices in multiple containers and the corresponding switch reads a
single MAC address. IPVLAN driver is useful when the local switch
imposes constraints on the total number of MAC addresses that it can
manage.
When using the netdev datapath, we wait for the link to appear in
different steps:
1. initially, in act_stage3_ip_config() connects to platform's
"link-changed" signal to detect when the TUN interface appears;
2. when the interface appears, _netdev_tun_link_cb() schedules
_set_ip_ifindex_tun() in a idle handler;
3. _set_ip_ifindex_tun() checks if the link is ready (e.g. if the MAC
address is correct) and in that case it reschedules stage3, which
will move forward with the activation;
4. if the link is not ready in _set_ip_ifindex_tun(), the function
connects again to platform's "link-changed" signal to react to link
changes;
5. after the link changes and it is ready, _netdev_tun_link_cb()
reschedules stage3, which moves forward with the activation;
With the current implementation it is possible that after step 2, if
act_stage3_ip_config() runs because it was already scheduled, it
registers again to the "link-changed" event; then when
_set_ip_ifindex_tun() is invoked it will hit assertion:
nm_assert(!priv->wait_link.tun_link_signal_id);
Fix this by preventing that the signal gets registered again after
step 2.
Fixes-test: @ovs_datapath_type_netdev_with_cloned_mac
Fixes: acf485196c ('ovs-interface: wait that the cloned MAC changes instead of setting it')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2024
The string array returned by nm_l3_config_data_get_searches() is not
NULL-terminated; we need to pass the exact length to
nm_utils_buf_utf8safe_escape_strv() instead of letting the function
scan for the NULL terminator.
Fix the following error reported by valgrind:
Conditional jump or move depends on uninitialised value(s)
at 0x4B287DB: g_strv_length (gstrfuncs.c:2948)
by 0x6EBDBE: nm_utils_buf_utf8safe_escape_strv (nm-shared-utils.c:3047)
by 0x59A3F1: get_property_ip (nm-ip-config.c:198)
by 0x4A6E150: UnknownInlinedFun (gobject.c:2140)
by 0x4A6E150: g_object_get_property (gobject.c:3454)
by 0x56FB1A: nm_dbus_utils_get_property (nm-dbus-utils.c:95)
by 0x44B343: _obj_get_property (nm-dbus-manager.c:880)
by 0x44DC4F: _nm_dbus_manager_obj_notify (nm-dbus-manager.c:1201)
by 0x56EE77: dispatch_properties_changed (nm-dbus-object.c:253)
by 0x4A5BF1E: g_object_notify_queue_thaw.lto_priv.0 (gobject.c:755)
by 0x5997BD: _handle_l3cd_changed (nm-ip-config.c:837)
by 0x59A129: _l3cfg_notify_cb (nm-ip-config.c:147)
by 0x4A5B649: g_closure_invoke (gclosure.c:834)
Fixes: 522a7d6baf ('nm-ip-config: escape searches when exposing to dbus')
Previously, when a connection was configured with search domains
that contained non-ASCII characters, GLib would try to parse the
search name as UTF-8, and an assertion would fail (which meant
that if NM was running with fatal assertions, it would crash).
Expose the search domains only as an escaped string to avoid this.
When a connection with ipv4.method=auto (DHCP) is configured with
ipv4.link-local=enable we were leaving the link-local address forever,
but this is not correct according to RFC3927[1] which says:
a host SHOULD NOT have both an operable routable address and an IPv4
Link-Local address configured on the same interface.
This adds a new mode that is more compliant, which only sets an IPv4
link-local address if no other address is set (through either DHCP lease
or ivp4.addresses setting)
Closes#1562
Link: https://github.com/systemd/systemd/issues/13316
Link: https://datatracker.ietf.org/doc/html/rfc3927#section-1.9 [1]
Add a new l3cfg DatFlag to specify that a given l3cd has a
non-link-local IPv4 set.
This will be used to enable or disable IPv4LL automatically in fallback
mode.
Move the static _ip4_address_is_link_local() check to a new global
nm_platform_ip4_address_is_link_local() helper so we can check if
an IPv4 is link local in other files
When lease is lost we would keep the DHCP state to READY, but we are
trying to get a new lease at this point so it is closer to PENDING.
Note this does not change how the device is displayed in `nmcli device`,
a connection with an expired lease is still displayed as `connected`.
When handling event TIMEOUT, "acd_data->probing_timeout_msec" needs to
be always initialized before jumping to "handle_start_probing:";
otherwise, an assertion failure is triggered at:
static void
_l3_acd_data_timeout_schedule_probing_restart(AcdData *acd_data, gint64 now_msec)
{
...
nm_assert(acd_data->probing_timeout_msec > 0);
Even if the ACD data is already in state PROBE, that doesn't mean that
the timeout is already initialized because the PROBE state can also be
reached from a INSTANCE_RESET event; and depending on the previous
state "acd_data->probing_timeout_msec" could be uninitialized.
Fixes-test: @iptunnel_restart
Fixes: b8f9d7b5dd ('l3cfg: rework ACD handling in NML3Cfg to support handling conflicts')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2023
Managed type = managed is a bit unclear, because all managed types are
for devices that are managed, but with different levels. Managed type =
managed could be interpreted as other types are unmanaged. Change it to
managed type = full.
Don't enforce IP cleanup when devices are in deactivating state, to
make sure that network connection is still available for pre-down
dispatcher phase.
Fixes ac4e63ddda ('ip: support dhcp-send-release in NMSettingIpConfig')
https://bugzilla.suse.com/show_bug.cgi?id=1228154
Currently if the system hostname can't be determined, NetworkManager
only retries when something changes: a new address is added, the DHCP
lease changes, etc.
However, it might happen that the current failure in looking up the
hostname is caused by an external factor, like a temporary outage of
the DNS server.
Add a mechanism to retry the resolution with an increasing timeout.
https://issues.redhat.com/browse/RHEL-17972
For now, always reapply the VLANs unconditionally, even if they didn't
change in kernel.
To set again the VLANs on the port we need to clear all the existing
one before. However, this deletes also the VLAN for the default-pvid
on the bridge. Therefore, we need some additional logic to inject the
default-pvid in the list of VLANs.
Co-authored-by: Íñigo Huguet <ihuguet@redhat.com>
Currently, nm_platform_link_set_bridge_vlans() accepts an array of
pointers to vlan objects; to avoid multiple allocations,
setting_vlans_to_platform() creates the array by piggybacking the
actual data after the pointers array.
In the next commits, the array will need to be manipulated and
extended, which is difficult with the current structure. Instead, pass
separately an array of objects and its size.
During nm_lldp_neighbor_parse(), the NMLldpNeighbor is not yet added to
the NMLldpRX instance. Consequently, n->lldp_rx is NULL.
Note how we use lldp_x for logging, because we need it for the context
for which interface the logging statement is.
Thus, those debug logging statements will follow a NULL pointer and lead
to a crash.
Fixes: 630de288d2 ('lldp: add libnm-lldp as fork of systemd's sd_lldp_rx')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1550
