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
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.
VPN plugin factory can never fail, it always returns an object, much
like g_object_new(). If the (GUI) editor is unavailable, it might be
okay for some use cases, notably import()/export(). In such case, the
absence of GUI editor is indicated via capability flags.
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 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]
As part of the conscious language efforts we are not writing offensive
terms into keyfiles anymore. This won't break users upgrading as we
still read such values if they are present into the keyfile.
For existing profiles, NetworkManager will remove the offensive terms
when editing the keyfile.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2009
At the moment, the access point mode uses 20MHz channels. Introduce a
new 'wifi.channel-width' property that allows the use of a larger
bandwidth, thus increasing performances.
Commit 345bd1b187 ('libnmc: fix secrets request on 2nd stage of 2FA
authentication') and commit 27c701ebfb ('libnmc: allow user input in
ECHO mode for 2FA challenges') introduced 2 new tags that hints for the
secret agents can have as prefix.
These tags were processed (and removed) in the secret agents, not in the
daemon. This is wrong because a system with an updated VPN plugin but a
not yet updated secret agent (like nm-plasma) will fail: it won't remove
the prefix and the daemon will save the secret with the prefix, i.e.
"x-dynamic-challenge:challenge-response" instead of just
"challenge-response". Then, VPN plugins doesn't recognize it, failing the
profile's activation. This is, in fact, an API break.
Also, if the VPN connection already existed before updating NM and the
VPN plugin, the secret flags are not added to the profile (they are only
added when the profile is created or modified). This causes the user's
first time response is saved to the profile, so the activation fails the
second and next times.
See:
- https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1536
- https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/142
Anyway, in a good design the daemon should contain almost all the logic
and the clients should keep as simple as possible. Fix above's problems
by letting the daemon to receive the secret names with the prefix
already included. The daemon will strip it and will know what it means.
Note that this is done only in the functions that saves the secrets from
the data received via D-Bus. For example, nm_setting_vpn_add_secret
doesn't need to do it because this value shouldn't come from VPN
plugin's hints.
Commit 797f3cafee ('device: fall back to saved use_tempaddr value
instead of rereading /proc') changed the behaviour of how to get the
last resort default value for ip6-privacy property.
Previously we read it from /proc/sys/net/ipv6/conf/default, buf after
this commit we started to read /proc/sys/net/ipv6/conf/<iface> instead,
because the user might have set a different value specific for that device.
As NetworkManager changes that value on connection activation, we used
the value read at the time that NetworkManager was started.
Commit 6cb14ae6a6 ('device: introduce ipv6.temp-valid-lifetime and
ipv6.temp-preferred-lifetime properties') introduced 2 new IPv6 privacy
related properties relying on the same mechanism.
However, this new behaviour is problematic because it's not predictable
nor reliable:
- NetworkManager is normally started at boot time. That means that, if a
user wants to set a new value to /proc/sys/net/ipv6/conf/<iface>,
NetworkManager is likely alread running, so the change won't take
effect.
- If NetworkManager is restarted it will read the value again, but this
value can be the one set by NetworkManager itself in the last
activation. This means that different values can be used as default in
the same system boot depending on the restarts of NetworkManager.
Moreover, this weird situation might happen:
- Connection A with ip6-privacy=2 is activated
- NetworkManager is stopped. The value in
/proc/sys/net/ipv6/conf/<iface>/use_tempaddr remains as 2.
- NetworkManager starts. It reads from /proc/sys/... and saves the value
'2' as the default.
- Connection B with no ip6-privacy setting is activated. The '2' saved
as default value is used. The connection didn't specify any value for
it, and the value '2' was set by another connection for that specific
connection only, not manually by a user that wanted '2' to be the
default.
A user shouldn't have to think on when NetworkManager starts or restarts
to known in an easy and predictable way what the default value for
certain property is. It's totally counterintuitive.
Revert back to the old behaviour of reading from
/proc/sys/net/ipv6/conf/default. Although this value is used by the
kernel only for newly created interfaces, and not for already existing
ones, it is reasonable to think on these settings as "systemwide
defaults" that the user has chosen.
Note that setting a different default in NetworkManager.conf still takes
precedence.
The D-Bus and C APIs admit setting the 802.1X certificates as blobs, as
the documentation of the properties explains. However, this is not
possible from nmcli, where only path to the certificates' files is possible.
This difference in nmcli was explained in the description message that
is shown in nmcli's editor, but this is a documentation that most users
won't ever see, and still the main documentation in nm-settings-nmcli is
missleading.
Add a nmcli specific documentation for the relevant properties and
remove the nmcli's editor descriptions as they are no longer needed.
In the gtkdoc comments, the text below tags like `Since: 1.2` is
discarded. In the property `autoconnect-slaves` a line indicating its
deprecation was below one of these tags. As a result, it was missing in
the man page. Fix it.
Fixes: 194455660d ('connection: deprecate NMSettingConnection autoconnect-slaves property')
GCC 14 with LTO complains with:
In function 'nm_team_link_watcher_new_ethtool',
inlined from 'nm_team_link_watcher_new_ethtool' at src/libnm-core-impl/nm-setting-team.c:106:1:
src/libnm-core-impl/nm-setting-team.c:130:33: error: array subscript 'struct NMTeamLinkWatcher[0]' is partly outside array bounds of 'unsigned char[16]' [-Werror=array-bounds=]
130 | watcher->ref_count = 1;
| ^
src/libnm-core-impl/nm-setting-team.c:128:15: note: object of size 16 allocated by 'g_malloc'
128 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^
even if the warning is disabled via pragma directives in that
code. This looks like the following GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
saying
We do not track warning options (and thus optimize pragmas /
attributes) across LTO because they are not saved in the function
specific optimization flag section.
We use a (NMTeamLinkWatcher *) to point to a memory area that is
shorter than the struct, because depending on the watcher type we need
to store different parameters; in this way we can save few bytes of
memory for some watcher types. However, this often breaks when
upgrading the compiler; instead just allocate the full struct.
When IPv6 privacy extensions are enabled, by default temporary addresses
have a valid lifetime of 1 week and a preferred lifetime of 1 day.
That's far too long for privacy-conscious users, some of whom want a new
address once every few seconds. Add connection options that correspond
to /proc/sys/net/ipv6/conf/*/temp_valid_lft and
/proc/sys/net/ipv6/conf/*/temp_prefered_lft to allow configuring the
address rotation time on a per-connection basis.
The new properties are defined as 32-bit signed integers to match the
sysctl parameters which are also signed, although currently only
positive numbers are valid.
This replaces the underlying type of mac_address_blacklist, which is currently GArray,
with a more re-usable NMValueStrv, which allows us to implement it as a direct property.
The comparison checking for MAC address equality had previously been flipped around.
Fixes: b084ad7f2b ('libnm-core: canonicalize hardware addresses in settings')
Setting for wpa_supplicant openssl_ciphers - openssl sometimes moves
ciphers among SECLEVELs. That is generaly a good thing, but some servers
are too old to support newer ciphers. Thus expert user should be allowed
to define openssl_ciphers per connection, so that they can connect to
old server, while not compromising security of other connections.
The purpose of this is to allow overriding to_dbus_fcn and from_dbus_fcn when
necessary (such as for special behavior regarding a deprecated/aliased properties).
Introduce a new option to NMSettingIpConfig. The new option is ternary
type being the default value set to disabled. When enabled,
NetworkManager will instruct the DHCP client to send RELEASE message
when IP addresses are being removed.
The new option at NMSettingConnection allow the user to specify if the
connection needs to be down when powering off the system. This is useful
for IP address removal prior powering off. In order to accomplish that,
we listen on "Shutdown" systemd DBus signal.
The option is set to FALSE by default, it can be specified globally on
configuration file or per profile.
If the device-handler of the generic connection is set, the connection
is virtual and the device is created by invoking the device-handler
via NetworkManager-dispatcher service.
With this change, a generic device now represents two different device
classes:
- existing interfaces that are not natively supported or recognized
by NetworkManager. Those devices have the `has_device_handler`
property set to FALSE;
- interfaces that are created by NM by invoking the device-handler;
they have `has_device_handler` set to TRUE.
Add a new "generic.device-handler" property that specifies the name of
a dispatcher script to be invoked to add and delete the interface for
this connection.
Add property to allow changing the eswitch mode between legacy SRIOV and
switchdev. Allow also to set "preserve" to prevent NM from modifying the
eswitch mode.
With a static array, we indicate that the argument must not be NULL.
Gcc-14.0.1-0.2.fc40 now warns against that:
CC src/libnm-base/libnm_base_la-nm-base.lo
In file included from ../src/libnm-std-aux/nm-default-std.h:102,
from ../src/libnm-glib-aux/nm-default-glib.h:11,
from ../src/libnm-glib-aux/nm-default-glib-i18n-lib.h:13,
from ../src/libnm-base/nm-base.c:3:
../src/libnm-base/nm-base.c: In function 'nm_net_devname_infiniband':
../src/libnm-std-aux/nm-std-aux.h:191:12: error: 'nonnull' argument 'name' compared to NULL [-Werror=nonnull-compare]
191 | if (expr) \
| ^
../src/libnm-std-aux/nm-std-aux.h:202:27: note: in expansion of macro '_NM_BOOLEAN_EXPR_IMPL'
202 | _NM_BOOLEAN_EXPR_IMPL(NM_UNIQ, expr))
| ^~~~~~~~~~~~~~~~~~~~~
../src/libnm-glib-aux/nm-macros-internal.h:1693:31: note: in expansion of macro 'NM_BOOLEAN_EXPR'
1693 | #define _G_BOOLEAN_EXPR(expr) NM_BOOLEAN_EXPR(expr)
| ^~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gmacros.h:1244:43: note: in expansion of macro '_G_BOOLEAN_EXPR'
1244 | #define G_LIKELY(expr) (__builtin_expect (_G_BOOLEAN_EXPR(expr), 1))
| ^~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gmessages.h:656:9: note: in expansion of macro 'G_LIKELY'
656 | if (G_LIKELY (expr)) \
| ^~~~~~~~
../src/libnm-base/nm-base.c:57:5: note: in expansion of macro 'g_return_val_if_fail'
57 | g_return_val_if_fail(name, NULL);
| ^~~~~~~~~~~~~~~~~~~~
../src/libnm-core-impl/nm-setting-wireguard.c: In function '_nm_wireguard_peer_set_public_key_bin':
../src/libnm-core-impl/nm-setting-wireguard.c:316:8: error: 'nonnull' argument 'public_key' compared to NULL [-Werror=nonnull-compare]
316 | if (!public_key)
| ^
Convert these checks to an nm_assert() to suppress the warning.
Otherwise, gcc-14.0.1-0.2.fc40 warns:
../src/libnm-core-impl/nm-utils.c: In function _nm_utils_strstrdictkey_create:
../src/libnm-core-impl/nm-utils.c:5076:16: error: allocation of insufficient size '1' for type 'NMUtilsStrStrDictKey' {aka 'struct _NMUtilsStrStrDictKey'} with size '2' [-Werror=alloc-size]
5076 | return g_malloc0(1);
| ^~~~~~~~~~~~
gcc-14.0.1-0.2.fc40 warns:
CC src/libnm-core-impl/libnm_core_impl_la-nm-setting-team.lo
../src/libnm-core-impl/nm-setting-team.c: In function nm_team_link_watcher_new_ethtool:
../src/libnm-core-impl/nm-setting-team.c:127:13: error: allocation of insufficient size 16 for type NMTeamLinkWatcher with size 48 [-Werror=alloc-size]
127 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^
Currently the internal DHCP client sets traffic class "CS6" in the DS
field of the IP header for outgoing packets.
dhclient sets the field according to the definition of TOS (RFC 1349),
which was was deprecated in 1998 by RFC 2474 in favor of DSCP.
Introduce a new property IPvX.dhcp-dscp (currently valid only for
IPv4) to specify a custom DSCP value for DHCP backends that support it
(currently, only the internal one).
Define the default value to CS0, because:
- section 4.9 of RFC 4594 specifies that DHCP should use the standard
(CS0 = 0) service class;
- section 3.2 says that class CS6 is for "transmitting packets
between network devices (routers) that require control (routing)
information to be exchanged between nodes", listing "OSPF, BGP,
ISIS, RIP" as examples of such traffic. Furthermore, it says that:
User traffic is not allowed to use this service class. By user
traffic, we mean packet flows that originate from user-controlled
end points that are connected to the network.
- we got reports of some Cisco switches dropping DHCP packets because
of the CS6 marking.
