Introduce a new "prefix-delegation" setting. It contains properties
related to the configuration of downstream interfaces using IPv6
prefix-delegation. The only property at the moment is "subnet-id",
which specifies which prefix to choose when the delegation contains
multiple /64 networks.
Add support for configuring per-interface IPv4 sysctl forwarding setting
in NetworkManager. The feature allows users to configure the
net.ipv4.conf.<interface>.forward setting directly through
NetworkManager, enabling targeted forwarding configurations for
interfaces. This is particularly useful for cases such as enabling
forwarding for MetalLB load balancing without requiring a global
ip_forward=1 setting.
While forwarding setting can be managed via /etc/sysctl.conf,
configuring sysctl options for dynamically created or
software-configured interfaces (e.g., bridges) poses challenges. With
this feature, NetworkManager can configure these settings when
interfaces are created or updated, users no longer need to rely on
nm-dispatcher scripts for per-interface sysctl configuration, which can
be error-prone and complex. This feature ensures a more seamless and
integrated way to manage per-interface forwarding configurations,
reducing user overhead and improving usability in complex network
setups.
We do not support configuring per-device IPv6 sysctl forwarding because
in order to make per-device IPv6 sysctl forwarding work, we also need to
enable the IPv6 global sysctl forwarding setting, but this has potential
security concerns because it changes the behavior of the system to
function as a router, which expose the system to new risks and
unintended traffic flows, especially when enabling forwarding on the
interface the user previously explicitly disabled. Also enabling
per-device IPv6 sysctl setting will change the behavior of router
advertisement (accept_ra), which is not expected. Therefore, we
only support configuring per-device IPv4 sysctl forwarding option in
NetworkManager.
Resolves: https://issues.redhat.com/browse/RHEL-60237https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2071https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1833
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
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.
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.
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.
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.
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.
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.
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.
(cherry picked from commit e686ab35b3)
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.
(cherry picked from commit c61c87f8a6)
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.
(cherry picked from commit fcd907e062)
To embrace inclusive language, deprecate the NMSettingConnection
autoconnect-slaves property and introduce autoconnect-ports property.
(cherry picked from commit 194455660d)
To embrace inclusive language, deprecate the NMSettingConnection
slave-type property and introduce port-type property.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
The supervision address is read-only. It is constructed by kernel and
only the last byte can be modified by setting the multicast-spec as
documented indeed.
As 1.46 was not released yet, we still can drop the whole API for this
setting property. We are keeping the NMDeviceHsr property as it is a
nice to have for reading it.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1823
Fixes: 5426bdf4a1 ('HSR: add support to HSR/PRP interface')
This patch add support to HSR/PRP interface. Please notice that PRP
driver is represented as HSR too. They are different drivers but on
kernel they are integrated together.
HSR/PRP is a network protocol standard for Ethernet that provides
seamless failover against failure of any network component. It intends
to be transparent to the application. These protocols are useful for
applications that request high availability and short switchover time
e.g electrical substation or high power inverters.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1791
Some Applications require to explicitly enable or disable EEE.
Therefore introduce EEE (Energy Efficient Ethernet) support with:
* ethtool.eee on/off
Unit test case included.
Signed-off-by: Johannes Zink <j.zink@pengutronix.de>
ethtool "channels" parameters can be used to configure multiple queues
for a NIC, which helps to improve performances. Until now, users had
to use dispatcher scripts to change those parameters. Introduce native
support in NetworkManager by adding the following properties:
- ethtool.channels-rx
- ethtool.channels-tx
- ethtool.channels-other
- ethtool.channels-combined
Parse the access point announced bandwidth in MHz. This is considering
both HT and VHT. Please notice that for VHT 80+80 MHz we are representing it
as 160 MHz.
This ABI was backported all the way to 1.42.8 and 1.40.20 and to rhel-8.9.
Move the ABI to a separate symbol version, which we have in all those
versions.
Add per port priority support for bond active port re-selection during
failover. A higher number means a higher priority in selection. The
primary port still has the highest priority. This option is only
compatible with active-backup, balance-tlb and balance-alb modes.
The symbol "nm_active_connection_get_controller" was backported to
1.42.1+. Since 1.44 is not yet released, move the symbol from
libnm_1_44 to libnm_1_42_2, like it is on 1.42.2 release. That way, we
don't need to duplicate the symbol while 1.44 being forward compatible
with 1.42.2.
NM 1.44 is not released yet and 1.42.2 will happen before 1.44.0, so we
can introduce the new API with version libnm_1_42_2 in both releases
without having duplicate symbols on 1.44.
This setting allows the user to remove the local route rule that is
autogenerated for both IPv4 and IPv6. By default, NetworkManager won't
touch the local route rule.
The configure flag and APN for the initial EPS bearer are used when
bringing up cellular modem connections. These settings are only relevant
for LTE modems.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
Reapply() is supposed to make sure that the system (the interface)
is configured as indicated by the applied-connection. That means,
it will remove/add configuration to make the system match the requested
configuration.
Add a flag "preserve-external-ip" which relaxes this. During reapply,
IP addresses/routes that exist on the interface and which are not known
(or added) by NetworkManager will be left alone.
This will be used by nm-cloud-setup, so that it can reconfigure the
interface in a less destructive way, which does not conflict with
external `ip addr/route` calls.
Note that the previous commit just adds "VersionInfo" and the
possibility to expose capabilities (patch-level). This is not used
for the new reapply flag, because, while we might backport the
reapply flag, we won't backport the "VersionInfo" property. Exposing
new capabilities via the "VersionInfo" property will only become useful
in the future, where we can backport a capability to older NM versions
(but those that have "VersionInfo" too).
This exposes NM_VERSION as number (contrary to the "Version", which is a
string). That is in particular useful, because the number can be
compared with <> due to the encoding of the version.
While at it, don't make it a single number. Expose an array of numbers,
where the following numbers are a bitfield of capabilities.
Note that before commit 3c67a1ec5e ('cli: remove version check against
NM'), we used to parse the "Version" string to detect the version. As
such, the information that "VersionInfo" exposes now, was already
(somewhat) available, you just had to parse the string. The main benefit of
"VersionInfo" is that it can expose capabilities (patched behavior) in
in a lightweight bitfield. To include the numerical version there is
just useful on top.
Currently no additional capabilities are exposed. The idea is of course
to have a place in the future, where we can expose additional
capabilities. Adding a capability flag is most useful for behavior that we
backport to older branches. Otherwise, we could just check the daemon version
alone. But since we only add "VersionInfo" property only now, we cannot backport
any capability further than this, because the "VersionInfo" property itself
won't be backported. As such, this will only be useful in the future by having
a place where we can add (and backport) capabilities.
Note that there is some overlap with the existing "Capability" property
and NMCapability enum. The difference is that adding a capability via "VersionInfo"
is only one bit, and thus cheaper. Most importantly, having it cheaper means
the downsides of adding a capability flag is significantly removed. In
practice, we could live without capabilities for a long time, so they
must be very cheap for them to be worth to add. Another difference might be,
that we will want that the VersionInfo is about compile time defaults (e.g.
a certain patch/behavior that is in or not), while NM_CAPABILITY_TEAM depends on
whether the team plugin is loaded at runtime.
