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.
In the original addition of the ModemManager backend for mobile
broadband, IPv6 was set to be disabled/ignored by default. The original
motivation for this is not obvious, but it should be gone after 11
years. Some carriers have IPv6-only networks for which the default
IPv4-only connection attempt is inappropriate. Enable IPv6 by default to
support more WWAN networks without special configuration.
Changing the default does not affect IPv4-only support thanks to
fallbacks implemented in nm_modem_get_connection_ip_type().
Link: https://gitlab.com/postmarketOS/pmaports/-/issues/2752
Fixes: a9032724cb ('modem-manager: new `NMModemBroadband'')
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>
We always sync routes in the main table, but routes in tables other
than main are only pruned if were added by NM, by default. Get the list
of routes to prune from other tables using obj_state->os_nm_configured,
as this tracks what routes were effectively added by NM.
The list should be the same that the one obtained from l3cfg_old. It
could be different if we commited the l3cfg with an NMIPRouteTableSyncMode
of NM_IP_ROUTE_TABLE_SYNC_MODE_MAIN, thus not deleting some routes at
commit time. However, since the previous commit, we never do it.
What all this shows is that starting to use different NMIPRouteTableSyncModes
is probably a bad idea: it will be a source of bugs of routes not being
always synced as users expect, and the use case for them is still to be
known.
By default, on reapply we were only syncing the main routes table. This
causes that routes added by NM to other tables are not removed on
reapply. This was done to preserve routes added externally, but routes
added by NM itself should be removed.
Add a new route table syncing mode "main + NM routes". This mode
maintains the normal behaviour of syncing completely the main table,
and for other tables removes only routes that were added by us, leaving
the rest untouched. Use this mode by default, as this is what a user
would expect on reapply.
Note: this might not work if NM is restarted between the profile being
modified and the reapply, because NM forgets what routes were added by
itself because of the restart. This is a rare corner case, though.
Use the D-Bus property "VersionInfo" to expose a capability flag
indicating that this bug is fixed. It is the first capability that we
expose in this way. However, it is convenient to do it this way as it's
something that clients like nmstate needs to know, so they can decide
whether a conn down is needed or not. It is not enough to decide that by
version number because it might be fixed via a downstream patch in distros
like RHEL.
https://issues.redhat.com/browse/RHEL-67324https://issues.redhat.com/browse/RHEL-66262
Fixes: e9c17fcc9b ('l3cfg: default to 'main' route table sync mode')
The difference between FULL and ALL was not obvious without reading the
documentation. Moreover, a new mode is going to be introduced so the
confusion could grow. Rename to a more explicit name.
Remove the `+ 31u` that was making that it would search for bit 1 at
array's element 1, instead of element 0. Fixed comparison >len that
shoudl be >=len. Fix a few typos.
Fixes: bc6098d441 ('libnm: add internal nmc_client_has_{version_info_v,version_info_capability,capability}() helper')
when the kernel boot parameter ipv6.disable=1 is set, NetworkManager
attempts to read files under /proc/sys/net/ipv6, resulting in numerous
error messages in the debug logs. For example:
NetworkManager[758]: <debug> [1726699000.9384] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/disable_ipv6: Failed to open file "/proc/sys/net/ipv6/conf/lo/disable_ipv6": No such file or directory
NetworkManager[758]: <debug> [1726699000.9400] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/accept_ra: Failed to open file "/proc/sys/net/ipv6/conf/lo/accept_ra": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/disable_ipv6: Failed to open file "/proc/sys/net/ipv6/conf/lo/disable_ipv6": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/hop_limit: Failed to open file "/proc/sys/net/ipv6/conf/lo/hop_limit": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/use_tempaddr: Failed to open file "/proc/sys/net/ipv6/conf/lo/use_tempaddr": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/temp_valid_lft: Failed to open file "/proc/sys/net/ipv6/conf/lo/temp_valid_lft": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/temp_prefered_lft: Failed to open file "/proc/sys/net/ipv6/conf/lo/temp_prefered_lft": No such file or directory
...
This also results unnecessary system calls by attempting to open non-existent sysfs.
This patch adds checks in some ipv6 sysctl functions to verify the existence of /proc/sys/net/ipv6.
While there are still other paths that attempts to open IPv6 sysfs, this
eliminates many reading errors.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2040
RFC 4191 section-3.1 says:
When processing a Router Advertisement, a type C host first updates a
::/0 route based on the Router Lifetime and Default Router Preference
in the Router Advertisement message header. [...] The Router Preference
and Lifetime values in a ::/0 Route Information Option override the
preference and lifetime values in the Router Advertisement header.
Fix the RA parsing so that the parameters from a default route option
are applied to the gateway.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1666https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2072
Fixes: c3a4656a68 ('rdisc: libndp implementation')
The keyfile format allows to specify the gateway in two ways: with a
separate "gateway" key, or by appending the gateway address to one of
the address$N lines:
[ipv4]
address1=192.0.2.1/24
gateway=192.0.2.254
[ipv4]
address1=192.0.2.1/24,192.0.2.254
The former syntax is self-documenting and easier to understand for
users, but NetworkManager defaults to the latter when writing
connection files, for historical reasons. Change that and use the
explicit form.
Note that if a users has scripts manually parsing keyfiles, they could
stop working and so this can be considered an API breakage. OTOH,
those scripts are buggy if they don't support both forms, and they can
already break with perfectly valid user-generated keyfiles.
I think it's acceptable to change the default way to persist keyfiles;
the only precaution would be that this patch should not be applied
during a stable release cycle of a distro.
We already check that a connection doesn't not change when it's
written and re-read from disk. Add another check to verify that the
generated keyfile matches a static one, so that we don't introduce
unwanted changes. The reference keyfiles can be generated by running
the test with "NM_TEST_REGENERATE=1".
The "closure" annotation needs to be set on the callback parameter
instead of on the data for the callback function.
This patch fixes the following warning:
"""
../src/libnm-core-impl/nm-utils.c:3632: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:4778: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:5776: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:5849: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:5976: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6091: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6448: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6521: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6581: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6663: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6728: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:974: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1014: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1041: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:974: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1014: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1041: Warning: NM: invalid "closure" annotation: only valid on callback parameters
"""
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}
To have a consistent setting name conversion between
`dhcp-send-hostname` and `dhcp-send-hostname-v2` with nmcli and global
config, convert dhcp-send-hostname <-> dhcp-send-hostname-v2 during
keyfile settings read and write.
In nmcli we have renamed dhcp-send-hostname and dhcp-send-hostname-v2 to
dhcp-send-hostname-deprecated and dhcp-send-hostname so users don't need
to worry about the details of the weird workarounds that we sometimes
need to do to expand and/or deprecate some properties.
However, the autogenerated documentation didn't include this names. Add
---nmcli--- specific documentation, adding a new property-infos field
called "rename" with the new name used in nmcli. This field can be used
for more properties if we use the same strategy in the future.
Since introducing the setting ipv[46].dhcp-send-hostname-v2 internally
in NM for supporting global default behavior of DHCP send hostname,
confusion arises for setting the dhcp-send-hostname-v2 and old
dhcp-send-hostname in nmcli. To avoid any confusion from user
configuring dhcp-send-hostname-v2 and old dhcp-send-hostname using
nmcli, introduce the mapping from nmcli argument dhcp-send-hostname to
internal dhcp-send-hostname-v2 property and the mapping from nmcli
argument dhcp-send-hostname-deprecated to internal old dhcp-send-hostname
property.
The change in split_required_fields_for_con_show makes that properties
specified with -g or -f are converted to the libnm's "internal" names.
The change in _print_fill makes that the names are converted to the
"external" user facing names.
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
Initial support for OCI. It doesn't support VLAN configuration yet as
the requirements are not clear. It doesn't support secondary IP
addresses because the IMDS server doesn't expose them.
Instead of using plain text format, it gets a single response in JSON
format and parses it. The dependency to jansson is now mandatory for
that.
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>
