Fix the following error seen when running the build_clean.sh script
with LTO disabled:
In file included from ../src/libnm-glib-aux/nm-default-glib.h:66,
from ../src/libnm-glib-aux/nm-default-glib-i18n-prog.h:13,
from ../src/core/nm-default-daemon.h:11,
from ../src/core/platform/tests/test-link.c:6:
In function ‘_nm_auto_freev’,
inlined from ‘test_link_get_bridge_fdb’ at ../src/core/platform/tests/test-link.c:2732:33:
../src/libnm-glib-aux/nm-macros-internal.h:166:8: error: ‘addrs’ may be used uninitialized [-Werror=maybe-uninitialized]
166 | if (*p) {
| ^
../src/core/platform/tests/test-link.c: In function ‘test_link_get_bridge_fdb’:
../src/core/platform/tests/test-link.c:2732:33: note: ‘addrs’ was declared here
2732 | nm_auto_freev NMEtherAddr **addrs;
| ^~~~~
cc1: all warnings being treated as errors
Fixes: 16ef33d380 ('bond-slb: fix memory leak')
Commit c5d1e35f99 ('device: support reapplying bridge-port VLANs')
didn't update can_reapply_change() to accept the "bridge-port.vlans"
property during a reapply. So, it was only possible to change the
bridge port VLANs by updating the "bridge.vlan-default-pvid" property
and doing a reapply. Fix that.
Fixes: c5d1e35f99 ('device: support reapplying bridge-port VLANs')
If the bridge default-pvid is zero, it means that the default PVID is
disabled. That is, the bridge PVID is not propagated to ports.
Currently NM tries to merge the existing bridge VLANs on the port with
the default PVID from the bridge, even when the PVID is zero. This
causes an error when setting the new VLAN list in the kernel, because
it rejects VLAN zero.
Skip the merge of the default PVID when zero.
Fixes: c5d1e35f99 ('device: support reapplying bridge-port VLANs')
The function should modify the "ip6_address" member of the union. In
practice, it doesn't matter because the ifindex is the first member of
both "ip4_address" and "ip6_address".
verify() is setting an error without returning FALSE to make the
validation fail. When the parent is set, the device is a Infiniband
partition and it must have a p-key != -1.
Fixes: d595f7843e ('libnm: add libnm/libnm-core (part 1)')
If sendto() fails, the function returns and the remaining entries are
not deallocated. Use nm_auto_freev instead to free the array and the
pointer it contains.
Add a test to check that nm_auto_freev does the right thing on the
value returned by nm_linux_platform_get_bridge_fdb().
Fixes: 3f2f922dd9 ('bonding: send ARP announcement on bonding-slb link/carrier down')
Rename nm_linux_platform_get_link_fdb_table() to
nm_linux_platform_get_bridge_fdb(). The new name better indicates that
the function returns the bridge FDB entries.
The DHCP search list option (119) can use the "message compression"
algorithm specified in RFC 1035 section 4.1.4 to reduce the size of
the message in presence of subdomains that appear multiple times.
When using the compression a label starts with:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where the offset points to a previous domain.
Previously, the parsing code was taking the lower 6 bits of the first
byte, shifting them left 16 bits, and adding the next byte. Instead,
the shift should be of 8 bits.
The effect of this bug was that when the offset was greater than 255,
it was incorrectly parsed as a number larger than the message size,
and the parsing failed.
Note that while a single DHCP option can be at most 255 bytes, a DHCP
message can contain multiple instances of the same option. The
receiver must concatenate all the occurrences according to RFC 3396
and parse the resulting buffer.
Fixes: 6adade6f21 ('dhcp: add nettools dhcp4 client')
The validation of embedded NUL character was skipped due to the wrong
order of arguments to memchr(). Fix it.
Fixes: 4043f82790 ('lldp: cleanup converting binary LLDP fields to string')
Currently the bug is hidden because the macro is only called with
NM_SETTING_BOND_OPTION_ARP_IP_TARGET.
Fixes: 45c95e9314 ('device/bond: rework setting of arp_ip_target bond options')
Linux UIDs/GIDs are 32-bit unsigned integer, with 4294967295 reserved
as undefined.
Before:
# useradd -u 4294967294 -M testuser
useradd warning: testuser's uid -2 outside of the UID_MIN 1000 and UID_MAX 60000 range.
# nmcli connection add type tun ifname tun1 owner 4294967294 ipv4.method disabled ipv6.method disabled
Error: Failed to add 'tun-tun1' connection: tun.owner: '4294967294': invalid user ID
After:
# useradd -u 4294967294 -M testuser
useradd warning: testuser's uid -2 outside of the UID_MIN 1000 and UID_MAX 60000 range.
# nmcli connection add type tun ifname tun1 owner 4294967294 ipv4.method disabled ipv6.method disabled
Connection 'tun-tun1' (5da24d19-1723-45d5-8e04-c976f7a251d0) successfully added.
# ip -d link show tun1
2421: tun1: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 500
link/none promiscuity 0 allmulti 0 minmtu 68 maxmtu 65535
tun type tun pi off vnet_hdr off persist on user testuser ...
^^^^^^^^^^^^^
Fixes: 1f30147a7a ('libnm-core: add NMSettingTun')
The string is freed with g_free(), it needs to be allocated with
g_strdup(). In practice, the GLib allocator uses malloc() nowadays,
but it is better to be consistent.
We are missing some validations when parsing VLANs: a unexpected
argument can cause a crash, an assertion, or the connection being
dropped without any warning. Make it more robust.
Running the build script with LTO disabled
("contrib/fedora/rpm/build_clean.sh -W lto") gives the following error:
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-client-aux-extern/nm-default-client.h:11,
from ../src/nmcli/connections.c:6:
In function ‘_nm_auto_unref_ptrarray’,
inlined from ‘do_connection_add’ at ../src/nmcli/connections.c:6069:35:
../src/libnm-std-aux/nm-std-aux.h:1106:12: error: ‘props’ may be used uninitialized [-Werror=maybe-uninitialized]
1106 | if (*v) \
| ^
../src/libnm-glib-aux/nm-macros-internal.h:91:1: note: in expansion of macro ‘NM_AUTO_DEFINE_FCN0’
91 | NM_AUTO_DEFINE_FCN0(GPtrArray *, _nm_auto_unref_ptrarray, g_ptr_array_unref);
| ^~~~~~~~~~~~~~~~~~~
../src/nmcli/connections.c: In function ‘do_connection_add’:
../src/nmcli/connections.c:6069:35: note: ‘props’ was declared here
6069 | gs_unref_ptrarray GPtrArray *props;
| ^~~~~
cc1: all warnings being treated as errors
Fix it.
Fixes: bb850fda0e ('nmcli: connection: process port-type, type and controller first')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2236
Currently, when a call to Reapply() results in stage3 being re-run, IPv6
ends up messed up. Like this:
$ nmcli device modify eth0 ipv4.address ''
$ nmcli device modify eth0 ipv4.address 172.31.13.37/24
$
NetworkManager[666]: <debug> [1751286095.2070] device[c95ca04a69467d81] (eth0): ip4: reapply...
...
NetworkManager[666]: <debug> [1751286095.2104] device[c95ca04a69467d81] (eth0): ip6: addrgenmode6: set none (already set)
NetworkManager[666]: <debug> [1751286095.2105] device[c95ca04a69467d81] (eth0): ip6: addrgenmode6: toggle disable_ipv6 sysctl after disabling addr-gen-mode
NetworkManager[666]: <debug> [1751286095.2105] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/eth0/disable_ipv6' to '1' (current value is '0')
NetworkManager[666]: <debug> [1751286095.2106] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/eth0/disable_ipv6' to '0' (current value is '1')
NetworkManager[666]: <debug> [1751286095.2106] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/eth0/accept_ra' to '0' (current value is identical)
NetworkManager[666]: <debug> [1751286095.2106] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/eth0/disable_ipv6' to '0' (current value is identical)
Not only is this unnecessary because addr-gen-mode already has the
desired value (as is logged), but also wipes off all IPv6 configuration.
This is fine on initial configuration, but not on Reapply().
Let's look at the device state first: if we've progressed past ip-config
state, then we can't possibly ever touch the offending sysctls. It's
okay -- we don't need to: addr-gen-mode is going to be set right if we
went through ip-config before.
Resolves: https://issues.redhat.com/browse/NMT-1681https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2232
The URL to the tarball needs the git tag, that might be 1.54-rc1 instead
of 1.53.90. Allow to define it as a separate variable in the spec file.
It can be set as `git_tag_version %{real_version}` when they are
identical.
It is not really needed here in the upstream spec file, as the "Source"
line is commented out, but add it as a reference for donwstream spec
files.
Commit bb850fda0e ('nmcli: connection: process port-type, type
and controller first') started correctly rejecting IP configuration
on port connections.
However, previously nmcli would accept IP parameters for ports when
using a specific parameters order. To avoid breaking user scripts that
may have relied on this behavior, introduce a backward compatibility
quirk.
Specifically, nmcli accepts a disabled/ignore IP method on a port
connection. For any other IP setting on a port connection, a specific
error message is now shown.
https://issues.redhat.com/browse/RHEL-90756https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2227
Add a new capability to indicate that NetworkManager supports the
"sriov.preserve-on-down" connection property. With this, clients can
set the property only when supported, without the risk of creating an
invalid connection.
Fix the following build warning emitted by g-ir-scanner:
../src/libnm-core-public/nm-dbus-interface.h:103: Warning: NM: "@NM_VERSION_INFO_CAPABILITY_IP4_FORWARDING" parameter unexpected at this location:
* @NM_VERSION_INFO_CAPABILITY_IP4_FORWARDING: Indicates that NetworkManager supports
^
Fixes: 6a13e8d369 ('core: expose the version info capability of IPv4 forwarding support')
The RT_VIA attribute is used to specify a gateway of a different
address family. It is currently used only for IPv4 routes.
[bgalvani@redhat.com: amended the commit message]
This commit adds NM_VERSION_INFO_CAPABILITY_IPV4_FORWARDING to the
VersionInfo D-Bus property, allowing clients such as nmstate to check
the NetworkManager's support of configuring per-device IPv4 sysctl
forwarding setting directly via the capabilities bitmask instead of
relying on the NetworkManager version comparisons.
The function uses symbol sd_device_get_devtype() which is currently
commented out. Therefore, NM dynamically links to the symbol from the
libsystemd shared object, which breaks on machines without systemd.
Before:
$ nm -u build/src/core/NetworkManager | grep sd_device
U sd_device_get_sysattr_value@LIBSYSTEMD_240
$
After:
$ nm -u build/src/core/NetworkManager | grep sd_device
$
Fixes: 6a4e6fab40 ('merge: branch 'systemd' into jv/systemd-merge')
Revert systemd commit 6ebbdcc0ddba ("sd-device: use
sd_device_get_sysattr_value() to read special symlinks"). In the NM
codebase sd_device_get_sysattr_value() is currently commented out
because it depends on file chase.c which is not imported. Importing
that file would require another long chain of imports. Therefore,
revert the commit.
This reverts commit 6ebbdcc0ddbacce732001823cf2be2a1d4381c60.
Fixes: 6a4e6fab40 ('merge: branch 'systemd' into jv/systemd-merge')
Revert systemd commit 17dc9ec4b6e8 ("sd-device: use
sd_device_get_sysattr_value() to read uevent file"). In the NM
codebase sd_device_get_sysattr_value() is currently commented out
because it depends on file chase.c which is not imported. Importing
that file would require another long chain of imports. Therefore,
revert the commit.
This reverts commit 17dc9ec4b6e82fc2a4f9809011e154f538eb8b9c.
Fixes: 6a4e6fab40 ('merge: branch 'systemd' into jv/systemd-merge')
Fix the following:
../src/core/nm-connectivity.c:958:1: warning: ‘check_platform_config’ defined but not used [-Wunused-function]
958 | check_platform_config(NMConnectivity *self,
| ^~~~~~~~~~~~~~~~~~~~~
Fixes: 91d447df19 ('device: don't start connectivity check on unconfigured devices')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2224
It is not clear whether we can actually respect this value. For example,
we should not restore the kernel's default value on deactivation or
device's state change, but it is unclear if we can ensure that we'll
still have the connection's configuration in all possible changes of
state.
Also, it is unclear if it's a desirable value that we want to support.
At this point it is mostly clear that trying to configure NM managed
devices externally always ends being dissapointing, no matter how hard
we try.
Remove this value for now, while we discuss whether it makes sense or
not, so it doesn't become stable in the new 1.54 release.
It is useful when there is an already active device and we want to
bring it down preserving the SR-IOV VFs. For example:
$ nmcli connection add type ethernet ifname eni1np1 sriov.total-vfs 2 ipv4.method disabled ipv6.method disabled
$ nmcli connection up ethernet-eni1np1
$ ip link show eni1np1
342: eni1np1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 6e:cf:f0:08:74:f4 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, ...
vf 1 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, ...
$ nmcli device modify eni1np1 sriov.preserve-on-down yes
$ nmcli connection down ethernet-eni1np1
$ ip link show eni1np1
342: eni1np1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 6e:cf:f0:08:74:f4 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, ...
vf 1 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, ...
Add a new "sriov.preserve-on-down" property that controls whether
NetworkManager preserves the SR-IOV parameters set on the device when
the connection is deactivated, or whether it resets them to their
default value. The SR-IOV parameters are those specified in the
"sriov" setting, like the number of VFs to create, the eswitch
configuration, etc.
Even if WireGuard is supported since long time in NetworkManager, it
is still not possible to manage the list of peers via nmcli. The
reason is that in the past we wanted to introduce a special syntax
that would allow to manage the peer list more easily. However, this
requires heavy changes to the nmcli output formatting code, and so it
never happened.
Since perfection is the enemy of good, abandon the idea of a custom
handling of peers and treat them as any other composite property. The
property is named "wireguard.peers" and exposes the peers indexed by
public key, with optional attributes.
Example:
$ nmcli connection modify wg0 wireguard.peers "8Wgc1a0jJX3rQULwD5NFFLKrKQnbOnTiaNoerLneG1o= preshared-key=16uGwZvROnwyNGoW6Z3pvJB5GKbd6ncYROA/FFleLQA= allowed-ips=0.0.0.0/0 persistent-keepalive=10"
$ nmcli connection modify wg0 +wireguard.peers "fd2NSxUjkaR/Jft15+gpXU13hKSyZLoe4cp+g+feBCc= allowed-ips=192.168.40.0/24 endpoint=172.25.10.1:8888"
$ nmcli -g wireguard.peers connection show wg0
8Wgc1a0jJX3rQULwD5NFFLKrKQnbOnTiaNoerLneG1o= allowed-ips=0.0.0.0/0 persistent-keepalive=10, fd2NSxUjkaR/Jft15+gpXU13hKSyZLoe4cp+g+feBCc= allowed-ips=192.168.40.0/24 endpoint=172.25.10.1\:8888
$ nmcli connection modify wg0 -wireguard.peers 8Wgc1a0jJX3rQULwD5NFFLKrKQnbOnTiaNoerLneG1o=
$ nmcli -g wireguard.peers connection show wg0
fd2NSxUjkaR/Jft15+gpXU13hKSyZLoe4cp+g+feBCc= allowed-ips=192.168.40.0/24 endpoint=172.25.10.1\:8888
When using the netdev datapath, we wait that the tun link appears, we
call nm_device_set_ip_ifindex() (which also brings the link up) and
then we check that the link is ready, i.e. that udev has announced the
link and the MAC address is correct. After that, we schedule stage3
(ip-config).
In this, there is a race condition that occurs sometimes in NMCI test
ovs_datapath_type_netdev_with_cloned_mac. In rare conditions,
nm_device_set_ip_ifindex() bring the interface up but then ovs-vswitch
changes again the flags of the interface without IFF_UP. The result is
that the interface stays down, breaking communications.
To fix this, we need to always call nm_device_bring_up() after the tun
device is ready. The problem is that we can't do it in
_netdev_tun_link_cb() because that function is already invoked
synchronously from platform code.
Instead, simplify the handling of the netdev datapath. Every
"link-changed" event from platform is handled by
_netdev_tun_link_cb(), which always schedule a delayed function
_netdev_tun_link_cb_in_idle(). This function just assigns the
ip-ifindex to the device if missing, and starts stage3 if the link is
ready. While doing so, it also bring the interface up.
Fixes: 99a6c6eda6 ('ovs, dpdk: fix creating ovs-interface when the ovs-bridge is netdev')
https://issues.redhat.com/browse/RHEL-17358https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2218
When connecting to an AP configured for WPA3 transition mode, the
connection will fail if PMF is disabled on the client due to SAE and
FT-SAE being unconditionally added to the key_mgmt variable's
parameters.
By removing the "!is_ap ||" check, SAE and FT-SAE will no longer be
selected when PMF is disabled, allowing clients to connect via
WPA2/PSK mode as per the original intent of
a0988868ba.
Signed-off-by: Conn O'Griofa <connogriofa@gmail.com>
- ausearch is part of audit package
- mlocate is not available anymore
- "openvswitch2*" packages are not available anymore
- ipsec-tools is not available anymore
It appears that xsltproc is not installed there. It is generally needed
for the docs build too, so as a crude CI heuristic, don't build anywhere
that docs are disabled.
Currently, both man pages and gtk-doc HTML documentation are enabled by
the same build option. It is common for users to want to choose whether
to build HTML docs, as not everyone cares about HTML developer docs, but
manpages are intended directly for end-user consumption and should
always be available. At the very least, there should be a separate
option to disable them to avoid accidentally disabling them while trying
to disable HTML developer docs.
Resolves: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1653
When building from a release tarball of NetworkManager,
`meson.add_dist_script()` has copied various prebuilt manpages into the
tarball and building them again is not really necessary. We can just
install those directly.
This means that *all* manpages could be installed even without
introspection, even though some of them can only be *built* when
introspection is enabled.
It also means that manpages can be installed even when xsltproc is not
available at build time.
This was likely added during the port to meson. It's just a multiline
string, so it has no effect in meson, and it appears to be entirely for
things which are already implemented in meson, so there's no real point
in keeping it any longer.
It's intrinsically used when building manpages, and also part of the
introspection-specific parts of the documentation build. There's no
particular guarantee either of those will actually be invoked during a
build, so don't unconditionally look it up.
This allows building with one fewer dependency in many cases.
The Open VSwitch interfaces have corresponding platform links. When an
Open VSwitch interface is created while NetworkManager is running, the
OVS factory usually sees an OVSDB entry appear first, then creates a
NMDevice. After that, when a platform link appears, the device is
already there.
Upon a (re-)start, the link might be seen first, and then things
go south. The OVS factory rejects the device, which results in Generic
device being created instead. Another device, this time of an
appropriate is created for the same link once the OVSDB entry is seen.
Needless to say, with two NMDevices for the same platform link existing,
no end of mayhem ensues (an assertion is tripped).
Resolves: https://issues.redhat.com/browse/NMT-1634https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2207
A device has the "external-down" unmanaged flag when:
!is-created-by-nm AND (!is-up OR (!has-address AND !is-controller))
When the "is-up" or the "has-address" conditions change, we properly update
the unmanaged flag by calling _dev_unmanaged_check_external_down() in
_dev_l3_cfg_notify_cb(PLATFORM_CHANGE_ON_IDLE).
The "is-controller" condition changes when another link indicates the
current device as controller. We currently don't update the unmanaged flag
when that happens and so it's possible that the device stays unmanaged even
if it has a port. This can be easily reproduced by running this commands:
ip link add veth0 type veth peer name veth1
ip link add vrf0 type vrf table 10
ip link set vrf0 up
ip link set veth0 master vrf0
Sometimes, the device shows as "unmanaged" instead of "connected
(externally)".
Fix this by re-evaluating the "external-down" unmanaged flags on the
controller when a port is attached or detached.
Fixes: c3586ce01a ('device: consider a device with slaves configured')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2209
When calling to nm_device_is_available, the device types that requires a
parent like VLAN or MACVLAN checks that their parent exists.
nm_device_is_available is a function to check if the device is available
to activate a connection, so it makes sense that if the parent is not
present it can't be activated.
However, this is wrong for 2 reasons:
1. Most of they are virtual devices that might be unrealized when
checking its availability. If they're unrealized, their parent hasn't
been set yet.
2. Even if they're realized, their current parent might not be the one
that is defined in the connection that is being activated.
This is causing that unrealized devices are not being activated as ports
because nm_manager_get_best_device_for_connection thinks that they are
not available.
Get rid of these checks for the parent in the is_available callbacks.
Fixes: ba86c208e0 ('Revert "core: prevent the activation of unavailable OVS interfaces only"')
Fixes: 774badb151 ('core: prevent the activation of unavailable devices')
When defining an IPv6 address with square brackets and prefix, like
[dead::beef]/64, the prefix was silently ignored. The address was
accepted only accidentally, because get_word replaced ']' with '\0' so
it resulted in a valid IPv6 address string, but without the prefix.
The previous commit has fixed get_word with better logic to handle the
square brackets, uncovering this issue.
Fix it by explicitly splitting IP addresses and prefixes in
reader_parse_ip so we get a valid address and prefix.
Also, use a prefix different to 64 in the test test_if_ip6_manual. 64 is
the default one, making that the test passed despite the defined prefix
was actually ignored.
Fixes: ecc074b2f8 ('initrd: add command line parser')
If any bond option contains an IPv6 address it needs to be enclosed with
[]. Otherwise the ':' separators from the IP address can be confused
with the ':' separators from the 'bond=' cmdline arguments.
However, the square brackets were ignored:
$ nm-initrd-generator -s "bond=bond0:eth0,eth1:ns_ip6_target=[FC08::789:1:0:0:3]"
NetworkManager-Message: 08:46:55.114: <warn> [1745498815.1146] cmdline-reader: Ignoring invalid bond option: "ns_ip6_target" = "[FC08": '[FC08' is not a valid IPv6 address for 'ns_ip6_target' option
NetworkManager-Message: 08:46:55.114: <warn> [1745498815.1148] cmdline-reader: Ignoring extra: '789:1:0:0:3]'.
The opening '[' was only being considered if it was the first character
in `get_word`. Fix it and consider it if it's in the middle too.
If the brackets are used first and last, directly remove them as it is what
most callers expect. However, if it's in the middle there is no reasonable
way to remove them, so don't do it. Instead, the caller will have to consider
this possibility when processing the content.
Fixes: ecc074b2f8 ('initrd: add command line parser')
Fixes https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1755
NMDevices have a special "can_reapply_change_ovs_external_ids" boolean
field indicating whether the device type supports reapplying the
ovs-external-ids and ovs-other-config settings.
Remove this field and use the standard can_reapply_change() method. No
change in behavior is expected.
If a OVS bridge created via NM has a port created externally, when the
bridge connections goes down then NM detaches the NM-created
port. However, it finds that the bridge still has a port (the external
one) and so it doesn't remove the bridge from ovsdb.
This is a problem, because it means that an explicity deactivation of
the bridge leaves the bridge up. To fix this, only track the number of
port in the bridge actually created by NM. Also, leave alone bridges
not created by NM.
Skip the internal NBFT table parsing when nbft interfaces
are already defined on the cmdline, e.g. from the original
95nvmf dracut module.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Some firmware implementations incorrectly report v6 address prefix
of zero. Let's use /64 as a sane workaround.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Creates additional connections for VLANs, which are in fact
separate HFI records in the NBFT table. Uses MAC address for
linking parent interface as the interface naming is defined
by an external service.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
As suggested during the review process, NBFT is niche and most users
won't need it. So keep the initrd generator light and only open
libnvme when any NBFT table is found.
In a typical dracut host-only scenario the nbft dracut module will
be pulled in only when NBFT is present in the system, packing in
nvme-cli and libnvme in the initramfs image.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
The NVMe Boot Firmware Table (NBFT) is a mechanism of passing context
from a pre-OS Boot environment to an OS runtime, as defined by the
NVM Express Boot Specification. Exposed as an ACPI table it contains
network interface definitions along with NVMe subsystem and namespace
data structures.
This adds new nm-initrd-generator parser that uses libnvme NBFT parser
implementation.
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
We often forget to add new files to POTFILES, and also
have some paths in the skip file that have not existed
for 15+ years. We should ensure that these files include
the paths that should be there, and nothing more.
This commit adds a test that checks whether all the files
in the po lists exist, and vice versa, that all the files
in the source tree that should be included in this list,
are indeed included in this list.
Introduce some basic infrastructure to perform ethtool operations via
netlink. As a proof of concept, implement the pause settings.
Netlink has some advantages over ioctl():
- it can be easily extended with new attributes;
- it can return descriptive error messages via the extended ack
mechanism. For example, when setting the ring parameters to a value
outside the allowed range, userspace receives error code -EINVAL
and message "requested ring size exceeds maximum". ioctl() gets
only -EINVAL, which is shared among many error reasons;
- since it's possible to specify an ifindex in the request, there are
no race conditions when the interface name changes;
New ethtool API is available only via netlink; however it makes sense
to start using netlink also for the old API that NM is already using
(pause, eee, rings, etc.) over ioctl() because of the advantages
described above.
We're going to replace most of the ioctl-based ethtool functions with
a netlink-based equivalent. Move the ioctl ones to a separate file so
that it's easier to see what still needs to be converted. Also add a
common prefix to the function names.
Previously, when a generated connection was edited, and the
machine was rebooted, the connection would not apply, and a
new generated connection would be made, because autoconnect
was set to FALSE.
Set autoconnect to be true by default, so that the modified
generated connection is applied.
iproute2 and the kernel accept 0 as valid rto_min value:
# ip route add 172.16.0.1 dev enp1s0 rto_min 0ms
# ip route show
172.16.0.1 dev enp1s0 scope link rto_min lock 0ms
Even if a value of 0ms would not be useful in practice, it is better
to exactly track what kernel reports, instead of assuming that when
the value is zero it is "not set".
Settings "ovs-dpdk" and "ovs-patch" are currently marked with priority
NM_SETTING_PRIORITY_HW_BASE, which makes them "base" settings. This
means that they can be used as connection type, for example via "nmcli
connection add type ovs-dpdk ...".
This is wrong, as both settings can only belong to a connection of
type "ovs-interface". Decrease their priority and make them non-base
settings.
The problem was spotted when trying to add a ovs-patch connection via
nmcli:
# nmcli connection add type ovs-patch ifname p con-name q ovs-patch.peer r controller s port-type ovs-port
Warning: controller='s' doesn't refer to any existing profile.
(process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 1682 (_normalize_ovs_interface_type): should not be reached
(process:4580): nm-WARNING **: 10:15:42.807: connection did not verify after normalization: ??
(process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 2170 (_connection_normalize): should not be reached
Error: Failed to add 'q' connection: ovs-interface.type: A connection with 'ovs-patch' setting must be of connection.type "ovs-interface" but is "ovs-patch"
Fixes: d0ec501163 ('cli: assert that valid_parts are set for base types')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2178
When the dictionary contains keys "address" and "uri", the first value
is leaked.
==4730== 14 bytes in 1 blocks are definitely lost in loss record 51 of 1,755
==4730== at 0x4841866: malloc (vg_replace_malloc.c:446)
==4730== by 0x4CC5CB9: g_malloc (gmem.c:100)
==4730== by 0x4CDF518: g_strdup (gstrfuncs.c:323)
==4730== by 0x496A6B8: g_strdup_inline (gstrfuncs.h:321)
==4730== by 0x496A6B8: nm_inet_ntop_dup (nm-inet-utils.h:355)
==4730== by 0x496A95B: nm_inet_parse_str (nm-inet-utils.c:539)
==4730== by 0x48AF3A3: _notify_update_prop_nameservers (nm-ip-config.c:179)
Fixes: 4422b14704 ('core, libnm: support per-connection DNS URIs')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2184
When nmcli tries to match a controller it filters by its type. The
controller's type must match with the port's port-type. If no controller
matches, the printed warning was "doesn't refer to any existing
profile". However, the profile might exist, but with wrong type. Improve
the message so it makes that clear.
Fixes: aa12bb353b ('cli: discover slave type for a connection with a master')
Normally it is possible not to define port-type in nmcli and it deduces
it from connection.type or connection.controller. Some types like 'bond-slave'
have a single possible value for port-type. In other cases nmcli deduces
the port-type by getting the controller's type, like 'bond'.
For OVS connections, the second method of guessing by the controller's
type was used. However, in OVS it is common to have different devices
with the same name, causing nmcli to use "ovs-interface" as port-type
if it matched by controller name.
Fix if by deducing the port-type from the connection's type. An ovs-port
connection must always have port-type=ovs-bridge, and an ovs-interface
connection must always have port-type=ovs-port.
Note that this is something that should be done in the daemon, not in
the clients, but this is a small patch that makes it to work in nmcli,
at least. Without this, the mechanism of guessing from the parent would
act, leading to wrong results.
Ideally, all this should be done in the daemon, but currently many
checks in nmcli/libnm depends on having the port-type set, and it
would be lot of work to change it.
Fixes: c5324ed285 ('nmcli: streamline connection addition')
When processing the "type" property we deduce the port-type in some
cases and set it. If the user has chosen a port-type we must not
overwrite it. In any case, we should raise an error when validating the
connection.
Fixes: c5324ed285 ('nmcli: streamline connection addition')
If the connection is a port we need to set the connection.port-type
property. Usually this property is guessed by nmcli depending on the
connection type or the chosen controller, so it doesn't need to be
specified by the user. However, if it is explicitly set by the user
we should not guess, but just use it.
When we process arguments like "controller" or "type" we call custom
functions like set_connection_controller that will guess the port-type
if needed. By processing port-type first, it will be set in the
connection by the time that these other properties are processed, so they
won't try to guess.
After port-type, process connection.type and connection.controller, as we
are usually capable of deducing the port-type from them. Type needs to
be processed first because some types like bond-slave or ovs-port have
only one possible port-type value so we must not try to guess from the
controller.
Fixes: c5324ed285 ('nmcli: streamline connection addition')
Make sure nm_device_update_dynamic_ip_setup is called every time a carrier was down before and the link is now up again.
Previously the dhcp lease was not renewed if the carrier went down and then up again quickly enough.
This led to cases where an old IP was retained even though the device was connected to a different network with a different DHCP server.
This commit introduces device_link_carrier_changed_down
Fixes: d6429d3ddb ('device: ensure DHCP is restarted every time the link goes up')
It is a little odd that client tests connect "UNAVAILABLE" devices, and
the devices return to "DISCONNECTED" after deactivation.
It differs from what happens in reality, and some client tools
(hey nm-cloud-setup) can break when they rightly assume that the
device is not ready for activation when it's "UNAVAILABLE" not
"DISCONNECTED".
Make it possible to opt in or out of the behavior of creating
connections for disconnected devices. It's not clear why such policy was
in place, and the feature might come useful outside OCI.
Let's add an (undocumented) knob to configure the behavior. We might
remove it (and perhaps make the behaviour default everywhere), or
document and keep it if it turns out we need to use it.
The function n_dhcp4_c_connection_send_request does not release or take
ownership of its request argument. Because of that, setting it to NULL
in the caller prevents the auto-cleanup of the variable to be executed,
causing a resource leak. Fix it.
Fixes: e23b3c9c3a ('Squashed 'shared/n-dhcp4/' content from commit fb1d43449')
Fixes: 243cc433fb ('n-dhcp4: add new client probe function to send RELEASE message')
Detected by coverity, the ping_op pointers are used after being freed in
cleanup_ping_operations. Although calling to g_list_remove is probably
safe because it only needs the value of the pointer, not to dereference
it, better to follow best practices. One of the use after free was
actually an error because we dereference ping_op->log_domain.
Fixes: 658aef0fa1 ('connection: Support connection.ip-ping-addresses')
This has always been broken (libedit-0:3.1-17.20160618cvs.fc26 is too
old to work and libedit-0:3.1-20.20170329cvs.fc27.x86_64 has this type
mismatch), but new GCC complains (14, 15).
../src/nmcli/connections.c: In function ‘nmcli_editor_tab_completion’:
../src/nmcli/connections.c:6862:64: error: assignment to ‘void (*)(char **, int, int)’ from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types]
6862 | rl_completion_display_matches_hook = uuid_display_hook;
| ^
../src/nmcli/connections.c:6909:60: error: assignment to ‘void (*)(char **, int, int)’ from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types]
6909 | rl_completion_display_matches_hook = uuid_display_hook;
| ^
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2172
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)')
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.
When a device in IPv6 shared mode obtains a prefix, it adds a new l3cd
of type L3_CONFIG_DATA_TYPE_PD_6 for that prefix. However, that l3cd
is never removed later and so the address lingers on the interface
even after the connection goes down. Remove the l3cd on cleanup.
Add a new flag "print_hex_negative_as_base10" in the property
descriptor _NMMetaPropertyTypData.
Normally, when a property has "base = 16", it is printed as unsigned
even if the gtype is signed.
For some properties, we want to print the hexadecimal representation
for positive values, and the base10 representation with minus sign for
negative values. A typical use case is to encode the default value as
"-1" and use positive values as a hexadecimal number.
When the carrier of an interface goes down, we defer the handling of
that event by some time (by default 6 seconds), to detect if the
carrier change was a spurious event.
It was observed that in some conditions the carrier goes down and we
register the timer for the deferred action on the device. Then the
link is deleted and recreated. At this point the timer fires and
aborts the new activation of the device.
Once the ifindex changes, cancel the timer for the deferred
carrier-down action.
Previously, IPv4 shared method will automatically enable the IPv4
global forwarding, all the per-interface level IPv4 forwarding settings
may be changed to match the global setting. Also, all the per-inteface
level forwarding settings can not be restored when deactivating the
shared connection. This is problematic as it may disrupt custom
configurations and lead to inconsistent forwarding behavior across
different network interfaces.
To address this, the implementation now ensures that the original
per-interface forwarding settings are preserved. Upon activating a
shared connection, instead of enabling IPv4 global forwarding
automatically, the per-interface forwarding is enabled on all other
connections unless a connection explicitly has the forwarding set to
"no" in its configuration. Upon deactivating all shared connection,
per-interface forwarding settings are restored to sysctl's default
value. Furthermore, deactivating any connection explicitly sets the
forwarding to sysctl's default value ensuring that network forwarding
behavior remains consistent.
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
When a WG connection is connecting to an IPv6 endpoint, configures a
default route, and firewalld is active with IPv6_rpfilter=yes, it never
handshakes and doesn't pass traffic. This is because firewalld has a
IPv6 reverse path filter which is discarding these packets.
Thus, we add some firewall rules whenever a WG connection is brought up
that ensure the conntrack mark and packet mark are copied over.
These rules are largely inspired by wg-quick:
https://git.zx2c4.com/wireguard-tools/tree/src/wg-quick/linux.bash?id=17c78d31c27a3c311a2ff42a881057753c6ef2a4#n221
PyGObject 3.52 switched from gobject-introspection’s libgirepository 1.0
to glib’s libgirepository 2.0. As a result, the Python script would
no longer be able to find the `GIRepository` 2.0 typelib:
(process:1944): GLib-GIRepository-DEBUG: 15:25:14.521: Ignoring GIRepository-2.0.typelib because this libgirepository corresponds to GIRepository-3.0.typelib
We could update the script to support both versions of the typelib
but it is not really necessary. It was only used to add extra directories
from `$LD_LIBRARY_PATH` and the CLI argument to repository’s library path
but libgirepository already supports using `LD_LIBRARY_PATH` directly:
https://docs.gtk.org/girepository/method.Repository.prepend_library_path.html
Add some missing "(nullable)" annotations to parameters of the
callback functions in NMSecretAgentOld. Otherwise, PyGObject complains
that those parameters cannot be NULL when implementing a secret agent.
Fixes: d595f7843e ('libnm: add libnm/libnm-core (part 1)')
If an alias like `nmcli=nmcli --some-arguments` is used, bash completion
doesn't work. Fix it by using `command nmcli` from the nmcli-completion
script, so we ensure that the --complete-args is passed directly to
nmcli binary, not through an alias.
Contributed-by: Jonas Belouadi (@potamides)
Fixes https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1734
DBus errors were not properly handled after DBus calls and
that caused SIGSEGV. Now they are checked.
Fixes#1738
Fixes: b8714e86e4 ('dns: introduce configuration_serial support to the dnsconfd plugin')
Prevents NetworkManager from trying to determine the
transient hostname via DHCP or other means if "localhost"
is already configured as a static hostname, as the transient
hostname will be ignored by hostnamed if a static hostname
has already been set.
They cannot be used yet as Dracut need changes. They are not really
tested, neither, so better not to install them as they might cause
confusion about their purpose.
This allows us to drag in packages that replace something in the base
image. Notably, this fixes installing pppd on Fedora 42 that requires
systemd (whereas the image has conflicting systemd-standalone-sysusers).
(cherry picked from commit 979717df4e)
Attempting to install these takes time and they are no longer there
since ancient times. CentOS 9 and later are fine.
(cherry picked from commit 39efc8a394)
More fallout from set -e patch, encountered during a release.
Fixes: 64f8ec6099 ('rpm/build*.sh: trap failures')
(cherry picked from commit aea231f489)
The idea is to create a pair of VLAN and MACVLAN with AddAndActivate if
they are not present, and otherwise follow the ordinary (GetApplied &
Reapply) procedure if the devices are already present.
This reverts commit 87d7ccc5807011fe74aa653677f142c31b54329f.
(cherry picked from commit 7eee669217)
This will be useful for updating configuration of Vlans and MacVlans,
some of having same MAC addresses as devices of other type.
This reverts commit cee0515f1399fe05f650adec147435aa0a933d78.
(cherry picked from commit 6cedd594b6)
Baremetal instances in Oracle Cloud require special VLAN config. Parse
the metadata related to it.
This reverts commit 5eefd2d59c.
(cherry picked from commit 5c3efeef15)
This is done so that AddAndActivate() will return sensible errors in a
future patch that makes it support creating virtual devices.
In effect, all errors are logged in one place, therefore the log levels
are different. I don't think we're losing anything of value by being
a little less verbose here.
(cherry picked from commit 45d82f720c)
The idea is to create a pair of VLAN and MACVLAN with AddAndActivate if
they are not present, and otherwise follow the ordinary (GetApplied &
Reapply) procedure if the devices are already present.
This reverts commit 87d7ccc5807011fe74aa653677f142c31b54329f.
This will be useful for updating configuration of Vlans and MacVlans,
some of having same MAC addresses as devices of other type.
This reverts commit cee0515f1399fe05f650adec147435aa0a933d78.
This is done so that AddAndActivate() will return sensible errors in a
future patch that makes it support creating virtual devices.
In effect, all errors are logged in one place, therefore the log levels
are different. I don't think we're losing anything of value by being
a little less verbose here.
Decouple from a specific initrd generator (dracut) the systemd services that
provide networking in the initrd using NM, thus allowing other systemd-based
initrd generators to take advantage of it.
These new services are:
- `NetworkManager-config-initrd.service`: it starts very early at boot, parses
the kernel command line using `nm-initrd-generator` and sets the
`/run/NetworkManager/initrd/neednet` flag to activate the other initrd services,
and also sets the hostname if needed.
- `NetworkManager-initrd.service`: it basically does the same job as the
`NetworkManager.service`, but in the initrd.
- `NetworkManager-wait-online-initrd.service`: ordered before
`network-online.target`, it will allow other services that require networking to
delay their start until NM has finished.
This allows us to drag in packages that replace something in the base
image. Notably, this fixes installing pppd on Fedora 42 that requires
systemd (whereas the image has conflicting systemd-standalone-sysusers).
Domains are exported via D-Bus and so they must be valid UTF-8.
RFC 1035 specifies that domain labels can contain any 8 bit values,
but also recommends that they follow the "preferred syntax" which only
allows letters, digits and hypens.
Don't introduce a strict validation of the preferred syntax, but at
least discard non UTF-8 search domains, as they will cause assertion
failures later when they are sent over D-Bus.
The variable 'change' may be used uninitialized.
Fixes: 7acc66699a ('policy: always reset retries when unblocking children or ports')
(cherry picked from commit af6aca3527)
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)
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)
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)
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.
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.
When Dnsconfd service is enabled but not started, NetworkManager
should attempt to start it through DBus at least once.
Fixes: c6e1925dec ('dns: Add dnsconfd DNS plugin')
(cherry picked from commit 1463b1c0a3)
When Dnsconfd service is enabled but not started, NetworkManager
should attempt to start it through DBus at least once.
Fixes: c6e1925dec ('dns: Add dnsconfd DNS plugin')
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)
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')
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)
Stop passing "connection-*" entries in the update method to
dnsconfd. The plugin tries to determine the connection from the
ifindex, but it's not possible to do it right at the moment because
the same ifindex can be used at the same time e.g. by a policy-based
VPN like ipsec and a normal device. Instead, it should be NM that
explicitly passes the information about the connection to the DNS
plugin. Anyway, these variables are not used at the moment by
dnsconfd.
Fixes: c6e1925dec ('dns: Add dnsconfd DNS plugin')
(cherry picked from commit 4d84e6cddf)
After every state change of the plugin there should be an invocation
of _nm_dns_plugin_update_pending_maybe_changed() to re-evaluate
whether we are waiting for an update. send_dnsconfd_update() doesn't
change the state and so there is need to check again afterwards.
(cherry picked from commit 8ff1cbf38b)
Stop passing "connection-*" entries in the update method to
dnsconfd. The plugin tries to determine the connection from the
ifindex, but it's not possible to do it right at the moment because
the same ifindex can be used at the same time e.g. by a policy-based
VPN like ipsec and a normal device. Instead, it should be NM that
explicitly passes the information about the connection to the DNS
plugin. Anyway, these variables are not used at the moment by
dnsconfd.
Fixes: c6e1925dec ('dns: Add dnsconfd DNS plugin')
After every state change of the plugin there should be an invocation
of _nm_dns_plugin_update_pending_maybe_changed() to re-evaluate
whether we are waiting for an update. send_dnsconfd_update() doesn't
change the state and so there is need to check again afterwards.
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.
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.
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.
The current mess of code seems like a hodgepodge of complex ideas,
partially copied from systemd, but then subtly different, and it's a
mess. Let's simplify this drastically.
First, assume that getrandom() is always available. If the kernel is too
old, we have an unoptimized slowpath for still supporting ancient
kernels, a path that should be removed at some point. If getrandom()
isn't available and the fallback path doesn't work, the system has much
larger problems, so just crash. This should basically never happen.
getrandom() and having randomness available in general is a critical
system API that should be expected to be available on any functioning
system.
Second, assume that the rng is initialized, so that asking for random
numbers should never block. This is virtually always true on modern
kernels. On ancient kernels, it usually becomes true. But, more
importantly, this is not the responsibility of various daemons, even
ones that run at boot. Instead, this is something for the kernel and/or
init to ensure.
Putting these together, we adopt new behavior:
- First, try getrandom(..., ..., 0). The 0 flags field means that this
call will only return good random bytes, not insecure ones.
- If this fails for some reason that isn't ENOSYS, crash.
- If this fails due to ENOSYS, poll on /dev/random until 1 byte is
available, suggesting that subsequent reads from the rng will almost
have good random bytes. If this fails, crash. Then, read from
/dev/urandom. If this fails, crash.
We don't bother caching when getrandom() returns ENOSYS. We don't apply
any other fancy optimizations to the slow fallback path. We keep that as
barebones and minimal as we can. It works. It's for ancient kernels. It
should be removed soon. It's not worth spending cycles over. Instead,
the goal is to eventually reduce all of this down to a simple boring
call to getrandom(..., ..., 0).
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2127
Add support for two new command line arguments:
- `rd.net.dns-backend` used to control the "dns" option in
NetworkManager configuration;
- `rd.net.dns-resolve-mode` used to control the "resolve-mode" in the
global DNS configuration.
The use case for them is the installation of a new system where the
administrator wants to configure aspects of the DNS resolution
starting from the early boot, for example to enable DNS over TLS and
avoid that any query goes out unencrypted.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2123
Move nm_keyfile_add_group() to libnm-glib-aux so that it can be used
by other components such as nm-initrd-generator. Rename it to
nm_key_file_add_group() to be consistent with the GLib API names
(g_key_file_*()).
Add the DNS routing rules explicitly instead of tracking them via the
NMGlobalTracker mechanism. Since we do not plan to ever remove them,
there is no reason to track the rules. Also, the current
implementation is buggy because in some situations the rules are
wrongly removed when they should not.
Fixes: bf3ecd9031 ('l3cfg: fix DNS routes')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2125
"configuration_serial" dbus property ensures that the plugin
can mark update 'not pending' when the update is trully finished.
This mechanism exists because of underlying problem of having
to restart, or perform similarly time consuming operation, to change
certain configuration parameters of resolver. If Dnsconfd would
block the update call until the update is finished, we could not
respond to any other requests until the call is finished.
Resolve-mode allows user to specify way how the global-dns domains
and DNS connection information should be merged and used.
Certification-authority allows user to specify certification
authority that should be used to verify certificates of encrypted
DNS servers.
Fix the following error with GCC 15:
../src/libnm-glib-aux/nm-shared-utils.c:35:42: error: initializer-string for array of 'char' is too long [-Werror=unterminated-string-initialization]
35 | const char _nm_hexchar_table_lower[16] = "0123456789abcdef";
| ^~~~~~~~~~~~~~~~~~
../src/libnm-glib-aux/nm-shared-utils.c:36:42: error: initializer-string for array of 'char' is too long [-Werror=unterminated-string-initialization]
36 | const char _nm_hexchar_table_upper[16] = "0123456789ABCDEF";
| ^~~~~~~~~~~~~~~~~~
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2116
This resulted in what looked like more significant bits of GType pointer
sometimes falling off the cliff, presumably because of a cast to
NMDeviceType enum (that probably ends up actually being a char).
This was silent enough to not emit compiler warnings and only occurring
with some very rare situations (needs GCC with LTO and some of the
optimization flags used by Fedora 41).
Fixes: cf6af54ffa ('cloud-setup: allow VETH along with ETHERNET too')
Fixes: 6ff4b9e57c ('cloud-setup: create VLANs for multiple VNICs on OCI')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2119
Always explicitly tear down pexpect instances and collect their
results. Assert on the results after orderly teardowns.
Track the current pexpect instance in test context so that it could be
still collected if the test blows up. That could provide more clue into
what went wrong in the test if it's due to a crash the testee.
Before:
[1573928.02238] <debug> config device C0:00:00:00:00:10: creating vlan connection for VLAN 700 on C0:00:00:00:00:10...
[1573928.02330] <debug> config device C0:00:00:00:00:10: connection "vlan2" (ac3c08f5-3e5c-38a3-a366-c16253de6db2) created
======================================================================
ERROR: test_oci_vlans (__main__.TestNmCloudSetup.test_oci_vlans)
----------------------------------------------------------------------
Traceback (most recent call last):
...
pexp.expect("some changes were applied for provider oci")
~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
pexpect.exceptions.EOF: End Of File (EOF). Exception style platform.
After:
[1573928.02238] <debug> config device C0:00:00:00:00:10: creating vlan connection for VLAN 700 on C0:00:00:00:00:10...
[1573928.02330] <debug> config device C0:00:00:00:00:10: connection "vlan2" (ac3c08f5-3e5c-38a3-a366-c16253de6db2) created
*** pexpect'd process killed by SIGABRT ***
======================================================================
ERROR: test_oci_vlans (__main__.TestNmCloudSetup.test_oci_vlans)
----------------------------------------------------------------------
Traceback (most recent call last):
...
pexp.expect("some changes were applied for provider oci")
~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
pexpect.exceptions.EOF: End Of File (EOF). Exception style platform.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2119
Allow running the following locally (for quick loval nm-c-s valgrind check),
without requiring $NM_TEST_CLIENT_NMCLI_PATH to be set.
$ NM_TEST_CLIENT_CLOUD_SETUP_PATH=build/src/nm-cloud-setup/nm-cloud-setup \
NMTST_USE_VALGRIND=1 python src/tests/client/test-client.py TestNmCloudSetup
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2119
The list describing the order of DHCP clients is confusing because it
doesn't take into account what clients are disabled at build
time. Instead, just show the available clients in the preferred order.
Describe in the NetworkManager.conf man page what DHCP clients the
user can set in this build, instead of showing a generic list and
letting the user try each one.
Pairs of veth devides are used for CI testing in place of real
ethernets. Use GLib types instead of NM numbers, since it's possible to
match them in hierarchical manner, with NMDeviceVeth being a subclass of
NMDeviceEthernet.
Fixes: 6ff4b9e57c ('cloud-setup: create VLANs for multiple VNICs on OCI')
The idea is to create a pair of VLAN and MACVLAN with AddAndActivate if
they are not present, and otherwise follow the ordinary (GetApplied &
Reapply) procedure if the devices are already present.
It attempts to modify attributes clearly belong to TestNmcli such as
_skip_test_for_l10n_diff or call methods that are in unittest.TestCase:
======================================================================
ERROR: test_002 (__main__.TestNmcli.test_002)
----------------------------------------------------------------------
Traceback (most recent call last):
File ".../src/tests/client/test-client.py", line 1508, in f
self.ctx.run_post()
~~~~~~~~~~~~~~~~~^^
File ".../src/tests/client/test-client.py", line 1185, in run_post
self.fail(
^^^^^^^^^
AttributeError: 'NMTestContext' object has no attribute 'fail'
It has presumably been moved out of TestNmcli at some point, but that
seems to have been in error, as it's also pretty specific to the nmcli
test cases. Not useful for cloud-init tests that also utilize
NMTestContext. Move it back.
This message is useless for non-interactive use and clobbers over
otherwise very appealing test output.
The callers knows what we're going to listen on, it passed us the file
descriptor.
Right now, on any baremetal only max. 2 physical NICs are available.
This might change in the future, so better to directly accept larger
nicIndex if we receive it. No behaviour change with this, just remove
an artificial limit.
There is no need to avoid including the full header, they are small
headers with some GLib type system stuff and no more. Just include them
where they are needed.
If the connection didn't exist in advance, there's no unrealized device,
and find_device_by_iface() is not going to get us one.
Call system_create_virtual_device() afrer nm_utils_complete_generic()
completes the connection for virtual devices. Make sure we do proper
cleanup if we happen to fail the activation later, so that de device
doesn't end up hanging there.
Make validate_activation_request() only do the validation -- split the
determination of the device into find_device_for_activation().
The point of this is to be able complete the connection and actually
create a virtual device after the validation.
I believe this is also somewhat easier to follow now that the procedure
does what its name says.
The point is to get rid of device/connection type specific arguments, to
eventually be able to complete the connection on AddAndActivate before knowing
which factory is going to take care of creating the device.
Aside from that, the whole thing is pretty awful -- with complicated
macros and variadic argument (ugh). Let's get rid of that.
All of these are wrong asserting that a connection has a particular
setting. On AddAndActivate, the connection can be pretty much empty:
impl_manager_add_and_activate_connection ()
validate_activation_request ()
nm_manager_get_best_device_for_connection ()
iface = nm_manager_get_connection_iface ()
find_parent_device_for_connection ()
nm_device_factory_get_connection_parent () <====== *shriek*
nm_device_factory_get_connection_iface ()
find_device_by_iface (iface)
nm_device_complete_connection ()
Remove those assertions.
Some of them are wrong: they assert a connection has a particular
setting even though this can be called on AddAndActivate against a
connection that is not complete or normalized:
impl_manager_add_and_activate_connection ()
validate_activation_request ()
nm_manager_get_best_device_for_connection ()
iface = nm_manager_get_connection_iface ()
find_parent_device_for_connection ()
nm_device_factory_get_connection_parent ()
nm_device_factory_get_connection_iface () <====== here
find_device_by_iface (iface)
nm_device_complete_connection ()
Fix those by removing the assertions.
Some of them are also fall back to just calling
nm_connection_get_interface_name() which is a pretty useless thing to do
because nm_device_factory_get_connection_iface() only calls the
device-specific routine if nm_device_factory_get_connection_iface()
doesn't return anything, to give the factory a chance to make up a name
(like <parent>.<vlan-id> for Vlan) on its own. Drop those.
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.
Previously, the coverity scheduled job seemed to fail
randomly because the image that it expected to use was
not available, due to not depending on the "prep" job.
This commit resolves the problem by making sure
the image is always built when coverity runs.
The current approach is flawed. During a commit of the L3
configuration we do a RTM_GETROUTE to find the next-hop to the DNS
server on the current interface, in order to create the DNS route to
inject into the l3cd. However, we haven't added routes to kernel yet
and so the result of the RTM_GETROUTE is going to be wrong.
In some cases, for example when IPv4 DAD is enabled, the bug can't be
easily noticed because we perform multiple commits for the interface,
and the regular routes are already set in kernel from the 2nd commit
on.
To fix the problem, do the following: during a commit we first add
addresses and routes to platform. Then, we create a list of DNS routes
to configure, we collect the old DNS routes, and do a comparison. If
they changed, we need to add the DNS routes to platform in a 2nd step.
Note that in the previous approach we tracked the routes in the
committed-l3cd object of the l3cfg, and so they were applied to kernel
automatically. Because of the 2-step requirement, that no longer works
and we must apply the DNS routes manually.
Fixes: 5449b18a94 ('core: support automatically adding DNS routes')
Don't try to add the routing rule that points to the table containing
DNS routes at every commit.
Instead, look into the platform cache to see if the rule already
exists and add it only when needed.
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).
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.
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.
Now "fedpkg prep" command is generating a directory with the "-build"
suffix containing the build directory inside. We need to extract it.
Real example:
If the script is used for a branch related to nm-1-46, the "fedpkg prep"
command will generate a NetworkManager-1.46-build/ directory containing
the NetworkManager-1.46/ sources directory. We just need to move the
NetworkManager-1.46/ out.
In the "Action()" D-Bus method, the "nameservers" key used to contain
an array of binary addresses. If we change the key to contain
something else, there can be problems when the NM and the
NM-dispatcher versions mismatch (right after an upgrade or a
downgrade).
To avoid such problem, still send the old key in the old format, and
introduce a new key for the new format. The new format carries the
name servers as a string list, and can encode encrypted DNS servers.
Introduce a new kernel command line option named "rd.net.dns" that can
be used to specify a global name server. It accepts name server in a
URI-like form, as for example:
rd.net.dns=dns+tls://[fd01::1]:5353#mydomain.com
Accept name servers specified with an URI syntax in the global
configuration. A plugin that doesn't support a specific scheme can
decide to ignore it and use only the servers it understands. At the
moment there is no plugin that supports DNS-over-TLS servers in the
global configuration.
Introduce new functions to parse and normalize name servers. Their
name contains "dns_uri" because they also support a URI-like syntax
as: "dns+tls://192.0.2.0:553#example.org".
Remove unused "server_name" argument. It is still possible to pass the
server name, if needed, with the nm_l3_config_data_add_nameserver()
function. After this change, rename the function to
nm_l3_config_data_add_nameserver_addr(), since the function only
accepts an address.
We only add to Tier 3 distro versions that ship a version of NM equal or
older to the one that we are testing. As CentOS Stream uses "main", no
stable version will be tested on it.
Force to test CentOS Stream as Tier 3.
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.
Now we are using scheduled pipelines for various purposes like
regenerating the container images and triage the issues and MRs. That
means that the last pipeline ran for main might not be the pipeline with
the jobs building and testing the code.
Use `source=push` to retrieve only pipelines that are not scheduled.
The help text is read from the comments at the top of the script itself.
However, to detect what lines belongs to the help text, a range was
defined as:
- Start: any line starting with `# `
- End: any line starting `# Run with --no-test`
If any later line starts with `# ` is considered as a new matching
range, and from it to the end of the file is printed too.
Fix it by defining the range:
- Start: line 2
- End: blank line
GNOME has changed the process to publish releases to download.gnome.org.
Now, it is required to do it from the CI of projects hosted in GNOME's
repositories.
As we don't have the project hosted there, we have 2 options:
- Create a mirror and set up the CI so we continue using
download.gnome.org.
- Stop publishing the tarballs there and do it in gitlab.freedesktop.org
from now on.
After a brief discussion we have decided that the second makes more
sense, so adapt release.sh to do that.
https://discourse.gnome.org/t/gnome-release-service-ftpadmin-replacement-coming-11th-december/25487https://handbook.gnome.org/maintainers/making-a-release.html
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')
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.
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
Versions that has branched out from Rawhide but are still not released
still have many changes that breaks the CI.
As we want the CI to be more stable for Tier 1, which runs for every MR,
do not make the switch as soon as Rawhide has branched, but when we choose so.
I always struggle to understand what 'check_run' means, as it suggests
that the run is executed and the results checked. What it acutally does
is to check if the run passed as argument is selected. Rename to
is_run_selected.
Also, remove check_run_clean which was only a check_run + do_clean. Just
call directly to do_clean.
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}
NetworkManager relies on the ping command provided by `/usr/bin/ping`
from the iputils package to proceed the gateway or ip addresses
connectivity check. This change ensures that iputils is recommended as a
dependency, making the ping command available for use during runtime but
not enforcing its installation as mandatory since NM can still proceed
to activate the connection even if the ping operation failed.
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.
Since NMSettingIPConfig is an abstract type that cannot be
instantiated, the overrides for the direct properties are defined on
the subclasses (NMSettingIP4Config and NMSettingIP6Config).
Silence the warning about using direct properties.
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')
from its previous location unter the users `$HOME` directory to
`$XDG_CACHE_HOME/nmcli-history`. This makes `nmcli` compliant with the
[XDG Base Directory Specification][1].
[1]: https://specifications.freedesktop.org/basedir-spec/latest/
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.
nm-connection-editor (and presumably the Control Center) expects the
nm_vpn_editor_plugin_factory() to fail if the editor plugin (the thing
that goes into the *-gnome subpackage in Fedora) is not installed.
However, factory() never fails, because the plugin is checked for
existence only when get_editor() is called.
The plugins tend to exit right away after receiving the "quit" signal,
which may come before the ConnectInteractive() response went out.
This may make NM miss the response, and the error details it contains.
Let's make sure we flush the pending traffic out.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2045
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
Use a blocking thread to remember the maintainers to run the CI. The
idea is that the maintainers have to run it manually and resolve the
thread.
Due to a limitation in gitlab-triage it has to be done in a weird way:
it is possible to check if the author is member of the project and it is
possible to check if he/she is member of the parent group, but it is not
possible to check if it's member of either one in a single rule. Because
of this a simple rule "author is not member" cannot be created.
To workaround this we create 2 rules to detect if the author IS a member
of the project or the group. If he/she is, we add a label to indicate
it. Then, a 3rd rule checks if this label is missing, and if it's
missing, it means that he/she is not a member.
This issue has been reported to gitlab-triage but it doesn't seem to be
in active maintenaince: https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/362
This was causing test_nml_dbus_meta() unit test to fail and also it was
affecting the notification when the object changed.
Fixes: 5426bdf4a1 ('HSR: add support to HSR/PRP interface')
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.
The setting was missing from the script. The patch is adding it and also
regenerates the docs.
Fixes: 5426bdf4a1 ('HSR: add support to HSR/PRP interface')
The HSR DBus metadata was defined properly but not exported on the libnm
library properly. This was causing that clients were not showing the HSR
devices.
Fixes: 5426bdf4a1 ('HSR: add support to HSR/PRP interface')
The "StartLimitIntervalSec" and "StartLimitBurst" directives should be
in the [Unit] section instead of the [Service] one.
Fixes: 927cff9f17 ('cloud-setup: allow bigger restart bursts')
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
Add option --all to distros_support.py to show all the NM versions that
are being actively used by any active distro. This will be useful to
decide what stable branches are we interested into actively backporting
fixes and which ones we're not.
Passing a version number of NetworkManager to this new script, it prints
what distros are using that NM version and generates a new content for
.gitlab-ci/config.yml.
Automatically generating the config.yml content is useful because we can
easily update what distros we test in the CI and the Tier that they
belong, depending on what version of NM do they ship and whether they
have reached EOL or not.
Important: when generating a config.yml for an stable branch, not for
main, it must be generated from main. This is because we are not going
to keep distros-info.yml up to date in all branches, only in main.
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.
Previously, the "edit" or "delete" buttons were clickable even
if there were no available connections, which was not expected
and caused an assertion to fail when clicked. This is because
the connections list could contain connections that were later
filtered out and not displayed in the final list, but the check
did not take this into account.
Make it so that the buttons are clickable only if we *actually*
have any available connections to edit or delete.
Fixes: 3bda3fb60c ('nmtui: initial import of nmtui')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1991
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
The code handling options with supposes, that options
are split by `=`, which is not the case. This fixes the following:
```
nmcli -f ipv4.ad\t\t
nmcli -f ipv4.ad=ipv4.addresses
nmcli --field ipv4.ad\t\t
nmcli --field ipv4.ad=ipv4.addresses
```
Using options with values separated with `=` remains broken,
but this change doesn't affect it:
```
nmcli --field=ipv4.ad\t\t
nmcli --field=ipv4.ad
```
Also, `man` and `usage` uses `--color auto|yes|no`,
not `--color=auto|yes|no`. So, this fix should be sufficient.
Bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2115827
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.
The primary address is that placed at position 0 of all the IP Addresses
of the interface. Sometimes we put it in a different position in the
ipv4s array because we insert them in the order we receive, but it might
happen that the HTTP responses comes back in wrong order.
In order to solve this, we pass the index of the IPv4 address to the
callback and the address is added in the right position directly.
Co-authored-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
On daemon startup, we may end up enqueueing many nm-cloud-setup.service
restarts in very a short time. That is perfectly fine, just bump the
thresholds so that systemd doesn't get in the way too quickly.
100 requests in 1 seconds seem like a fair choice -- little bit on the
conservative side, yet still giving the service manager some room to
interfere on a chance things really go awry.
https://issues.redhat.com/browse/RHEL-49694
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
Commit c19b5d76c2 ('contrib: install "policykit-1" package on Debian')
added policykit-1 because it was needed to get a translation file.
In recent Debian versions it has been removed. It was only a
transitional package to install polkitd and pkexec. Install polkitd
directly instead.
Attempt to tab-complete a property from a setting which does not exist
results in an assertion failure:
nmcli > set lala.lala<TAB>
(process:597363): nm-CRITICAL **: 16:30:21.642: nm_meta_setting_info_editor_find_by_name: assertion 'setting_name' failed
Thread 1 "nmcli" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff780dc28 in g_logv () from /lib64/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff780dc28 in g_logv () at /lib64/libglib-2.0.so.0
#1 0x00007ffff780dea3 in g_log () at /lib64/libglib-2.0.so.0
#2 0x000000000044a2c2 in nm_meta_setting_info_editor_find_by_name (setting_name=<optimized out>, use_alias=use_alias@entry=0)
at src/libnmc-setting/nm-meta-setting-access.c:35
#3 0x000000000042eb07 in get_setting_and_property (prompt=<optimized out>, line=<optimized out>, setting_out=0x7fffffffcf10, property_out=0x7fffffffcf18)
at src/nmcli/connections.c:6639
#4 0x000000000042ec38 in get_allowed_property_values (out_to_free=out_to_free@entry=0x7fffffffcf50) at src/nmcli/connections.c:6711
#5 0x000000000042ed8c in should_complete_property_values (prompt=prompt@entry=0x5befb0 "nmcli 802-1x.pac-file> ", line=line@entry=0x0, multi=multi@entry=0x7fffffffcfe4)
at src/nmcli/connections.c:6735
#6 0x000000000042f5d8 in nmcli_editor_tab_completion (text=0x5bef90 "lala", start=<optimized out>, end=13) at src/nmcli/connections.c:6899
#7 0x00007ffff776dcdc in gen_completion_matches () at /lib64/libreadline.so.8
...
Do not proceed resolving the setting name if it does not pass
check_valid_name().
In case the user selects a setting/property with "goto" command, and
then attempts to tab-complete a setting/property pair, the original sett
and prop strings are overriden without freeing:
nmcli > goto 802-1x.pac-file
nmcli 802-1x.pac-file> set 802-1.lal<TAB>
Fixes: 79bc271685 ('cli: TAB-completion for enum-style property values (rh #1034126)')
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
If the socket's RX buffer is full it's probably because other
process is doing lot of changes very quickly, faster than we
can process them. Let's give the writer a small time to finish:
1. Avoid contending the kernel's RTNL lock, so we don't make
the whole situation even worse and it can finish earlier.
2. Avoid having to resync again and again due to trying to
resync while the writer is still doing quick changes, so
we are unable to catch up yet.
This won't help if this situation takes a long time or is
continuous, but that's unlikely to happen, and if it does,
it's the writer's fault for starving the whole system.
There is no need to progresively increase the backoff time
for the same reason: if this situation takes lot of time,
it's the writer's fault. It's neither a good idea because the whole NM
process will end being sleeping long times, not doing anything at all,
without being able to react when the Netlink messages burst stops.
Add a function to compare two arrays of NMPlatformBridgeVlan. It will
be used in the next commit to compare the VLANs from platform to the
ones we want to set.
To compare in a performant way, the vlans need to be normalized (no
duplicated VLANS, ranges into their minimal expression...). Add the
function nmp_utils_bridge_vlan_normalize.
Co-authored-by: Íñigo Huguet <ihuguet@redhat.com>
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
As part of the conscious language effort we must provide an alternative
option to configure autoconnect-ports system-wide on NetworkManager
configuration file.
The in_buffer is initialized with a NULL buffer. If we never receive and
data, the buffer might still be NULL.
Maybe it actually can never happen, but it's not clear that this is
always the case. To be sure, ensure we don't return a NULL buffer on
success.
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
In case the platform fails dumping a specific route protocol, retry
multiple times. If all attempts fail, emit a warning and proceed as
there is nothing more to do.
When doing a dump of routes, we want to exclude routes having
protocols we do not care about. Since the netlink socket has
STRICT_CHK enabled, we can request multiple dumps for the protocols we
need.
While doing 6 dumps is less efficient than doing 1, it normally
doesn't matter. However, the new implementation is more efficient when
there are e.g. millions of BGP routes that can be excluded from the
results.
Introduce an array of tracked route protocols that will be used in the
next commit. To have the list of protocols defined in a single place,
define a macro.
When building on musl systems ( with out systemd ), and using LLD linker
from LLVM project we fail to link with undefined symbols.
This symbol is in sd_id128.c but its disabled, so let disable the functions
which need this function.
| x86_64-yoe-linux-musl-ld.lld: error: undefined symbol: sd_id128_get_machine_app_specific
| >>> referenced by sd-dhcp-duid.c:202 (/usr/src/debug/networkmanager/1.48.0/../NetworkManager-1.48.0/src/libnm-systemd-core/src/libsystemd-network/sd-dhcp-duid.c:202)
| >>> libnm-systemd-core.a.p/src_libsystemd-network_sd-dhcp-duid.c.o:(sd_dhcp_duid_set_uuid) in archive src/libnm-systemd-core/libnm-systemd-core.a
| x86_64-yoe-linux-musl-clang: error: linker command failed with exit code 1 (use -v to see invocation)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Not all setting names are valid values for the value of the connection's "type".
However, if a shortened value is introduced, all setting names are
considered, like in:
Error: bad connection type: 'eth' is ambiguous: ethernet, ethtool
Note that ethtool is not a valid value for "type".
Fix it by considering only "base" settings names.
It is possible that we learn the link is ready on stage3_ip_config
rather than in link_changed event due to a stage3_ip_config scheduled by
another component. In such cases, we proceed with IP configuration
without allocating the resources needed like initializing DHCP client.
In order to avoid that, if we learn during stage3_ip_config that the
link is now ready, we need to schedule another stage3_ip_config to
allocate the resources we might need.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2004
Fixes: 83bf7a8cdb ('ovs: wait for the link to be ready before activating')
If we add multiple default routes with the same metric and different
preferences, kernel merges them into a single ECMP route, with overall
preference equal to the preference of the first route
added. Therefore, the preference of individual routes is not
respected.
To avoid that, add routes with different metrics if they have
different preferences, so that they are not merged together.
We could configure only the route(s) with highest preference ignoring
the others, and the effect would be the same. However, it is better to
add all routes so that users can easily see from "ip route" that there
are multiple routers available.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1468https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1983
Fixes: 032b4e4371 ('core: use router preference for IPv6 routes')
When activating an ovs-interface we already wait for the cloned MAC
address to be set, ifindex is present and platform link also present but
in some cases this is not enough.
If an udev rule is in place it might modify the interface when it is in
a later stage of the activation causing some race conditions or
problems. In order to solve that, we must wait until the link is fully
initialized.
We are currently asserting that the list of devices waiting for
auto-activation in NMPolicy is not empty. This condition is always
false because:
- NMDevice holds a reference to NMManager
- NMManager holds a reference to NMPolicy
- on dispose, NMDevice asserts that it's not in NMPolicy's
auto-activate list
Therefore if there is any NMDevice alive, NMPolicy must be alive as
well. Instead, if there is no NMDevice alive the list must be empty.
The assertion could fail only when the NMPolicy instance gets
disposed, which usually doesn't happen because it's still referenced
at shutdown.
Fixes: aede228974 ('core: assert that devices are not registered when disposing NMPolicy')
When activating a port with its controller deactivating by new
activation, NM will register `state-change` signal waiting controller to
have new active connections. Once controller got new active connection,
the port will invoke `nm_active_connection_set_controller()` which lead
to assert error on
g_return_if_fail(!nm_dbus_object_is_exported(NM_DBUS_OBJECT(self)))
because this active connection is already exposed as DBUS object.
To fix the problem, we remove the restriction on controller been
write-only and notify DBUS object changes for controller property.
Signed-off-by: Gris Ge <fge@redhat.com>
It's deprecated. Warn any time it is being considered for loading,
instead of at load time, so that the user gets a warning when they got
the plugin in configuration, even if it's build time disabled.
https://issues.redhat.com/browse/RHEL-24622
Prioritize internal, which is what most people should be using. Try
dhclient last, so that it's not attempted when not explicitly
configured or everything else fails.
Make it off by default. Point out it's deprecated in a config summary.
It's not maintained upstream. There's probably not much justification for
using it any more and we'd like to remove it at some point.
https://issues.redhat.com/browse/RHEL-24622
Make it off by default. Point out it's deprecated in a config summary.
It's not maintained upstream. There's probably not much justification for
using it any more and we'd like to remove it at some point.
https://issues.redhat.com/browse/RHEL-24622
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.
Instead of asking the Wi-Fi password in advance (or not at all, if we're
creating a new connection for "nmcli d conn"), use the secret agent.
This makes things consistent with other places where we handle the secrets
for an activating connection in nmcli ("nmcli c up", "nmcli d con" with
an existing connection).
This also fixes the situation where the secrets would stop being
required, such as on enrollment via WPS button press on a router.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1960
Script to create a RHCOS custom image containing a NetworkManager rpm from
a copr repository.
In order to have a custom RHCOS image, we cannot modify the image itself but
we can add a custom layered image that includes all RHCOS functionality and
adds additional functionality to it.
Requirements:
- A quay.io registry where you have push access.
- You must have your pull-secret in the same directory where the script is
being run. You can download your pull-secret from:
https://console.redhat.com/openshift/install/pull-secret
In order to install this on nodes from a cluster that already exists it must
be done using MachineConfig operator. In essence the following YAML file
must be created.
```
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: <role>
name: os-layer-custom-nm
spec:
osImageURL: <registry>
```
Please, notice that the role and registry need to be set to your needs.
Then, it can be applied by:
$ oc create -f <yaml file>
Finally, the machines will be ready once the field UPDATED has the True value
in the output of this command.
$ oc get mcp
Before introducing the hostname lookup via nm-daemon-helper and
systemd-resolved, we used GLib's GResolver which internally relies on
the libc resolver and generally also returns results from /etc/hosts.
With the new mechanism we only ask to systemd-resolved (with
NO_SYNTHESIZE) or perform the lookup via the "dns" NSS module. In both
ways, /etc/hosts is not evaluated.
Since users relied on having the hostname resolved via /etc/hosts,
restore that behavior. Now, after trying the resolution via
systemd-resolved and the "dns" NSS module, we also try via the "files"
NSS module which reads /etc/hosts.
Fixes: 27eae4043b ('device: add a nm_device_resolve_address()')
Introduce a new argument to specify a comma-separated list of NSS
services to use for the "resolve-address" command. For now only accept
"dns" and "files"; the latter can be used to do a lookup into
/etc/hosts.
Note that previously the command failed in presence of extra
arguments. Therefore, when downgrading NetworkManager without
restarting the service, the previously-installed version of the daemon
(newer) would spawn the helper with the extra argument, and the
newly-installed version of the helper (older) would fail. This issue
only impacts hostname resolution and can be fixed by just restarting
the daemon.
In the upgrade path everything works as before, with the only
difference that the helper will use by default both "dns" and "files"
services.
Don't strictly check for the absence of extra arguments, so that in
the future we can introduce more arguments without necessarily break
the downgrade path.
When ModemManager become available, NetworkManager resets
GDBusObjectManagerClient object.
But there is a race condition if object-added is emitted before
modm_ensure_manager(), we need to check existing objects if we want to be
in sync with ModemManager.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1957
Also check for gateway equality when deduplicate routing entries. This
allows to support multiple routes to the same network using different
gateways. This is useful for Thread networks where multiple BRs route
to the same Thread network. If one of these BRs go offline, fallback to
a different router will be much quicker if multiple entries are present.
Note that quick fallback to a different router requires IPv6
reachability probe to be active. Typically Linux disables reachability
probes on Linux machines which act as IPv6 gateway (when forwarding is
enabled).
It might happen that write() returns -1, but the errno is not EINTR.
In that case, the length would be incremented by 1, and the data pointer
to the data being written would be moved back by 1 byte on every error.
Make it so that the function exits with an error if it indicates an error.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1971
Fixes: 3bda3fb60c ('nmtui: initial import of nmtui')
Useful to have easily accessible the info of all the distros that we
test, including the version of NM that they ship and their EOL dates so
we can know when to stop testing them.
For now this is only informative, but we can use this info, for example,
to generate the `.gitlab-ci/config.yml` file automatically for each
stable branch.
When the lease expires, the DHCP client emits a LEASE_UPDATE event
with a NULL l3cd. After returning from the handler, it sends
immediately a DHCP DISCOVER message to try to get a new lease.
It is important that when the DISCOVER gets sent the address is no
longer configured on the interface. Otherwise, the server could see
that it is already in use and assign a different one. Therefore,
remove the address synchronously when handling the event.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1532
Currently, when the agent manager is sent a registration request
containing UTF-8 characters, it will form an invalid error message
using only one of the bytes from the UTF-8 sequence, which causes
an assertion in glib to fail, which replaces the returned error message
with "[Invalid UTF-8]". It will also print an assertion failure to the
console, or crash NetworkManager on non-release builds.
This commit makes it so that it instead prints out the character in
hexadecimal form if it isn't normally printable, so that it is once
again a valid UTF-8 string.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1965
Fixes: a30cf19858 ('agent: add agent manager and minimal agent class')
A signal handler is not the only place where we need to clean up after
an in-progress readline() on exit; we may do so when erroring out as
well:
Before (not also the missing line break, which is part of the cleanup):
$ (sleep 10; nmcli c del 'Red Hat Wi-Fi')
$ nmcli --ask d wifi connect 'Red Hat Wi-Fi'
Passwords or encryption keys are required to access the wireless network 'Red Hat Wi-Fi'.
Password (802-11-wireless-security.psk): Error: Connection activation failed: The device's active connection disappeared.
$ [terminal messed up, no echo]
After:
$ (sleep 10; nmcli c del 'Red Hat Wi-Fi')
$ nmcli --ask d wifi connect 'Red Hat Wi-Fi'
Passwords or encryption keys are required to access the wireless network 'Red Hat Wi-Fi'.
Password (802-11-wireless-security.psk):
Error: Connection activation failed: The device's active connection disappeared.
$ hello [terminal echo fine, wheee]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1959
We currently submit builds to Coverity manually every now and then,
but it would make sense to submit them more frequently and periodically,
so that it can detect defects sooner.
Add a "coverity" stage to the pipeline, which submits a build to Coverit
(the scheduls currently set to run every week).
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1973
In the future we might want to specify filters when requesting netlink
dumps; this requires that strict check is enabled on the socket.
When enabling strict check, we need to pass a full struct in the
netlink message, otherwise kernel ignores it.
This commit doesn't change behavior.
Adds an option in the connectivity section to change the timeout before
the interface is deemed "limited". Previously, it was hardcoded to
20 seconds, but for our usecase (failing over to cell modem if
hardwired ethernet drops), it's nice to be able to failover to another
interface more quickly.
The OVS interface can be matched via MAC address; in that case, the
"connection.interface-name" property of the connection is empty.
When populating the ovsdb, we need to pass the actual interface name
from the device, not the one from the connection.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
https://issues.redhat.com/browse/RHEL-34617
Currently, the Dockerfile expects /etc/systemd/journald.conf to exist on the base container,
but sometimes this may not be the case, for example on Fedora 40, which causes
the build process to fail if the host machine is also running Fedora 40.
Update the dockerfile to create a conf.d file instead, which has higher precedence.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1972
The comment makes it sounds as if we could do without CAP_DAC_OVERRIDE
if we don't use OpenVSwitch, which is not true. At the very least it's
needed by the VPN plugins we spawn to access cert/key material from
users' homes.
For [connection*] and [device*] sections, any suffix is allowed in
the group.
However (at least for configuration snippets we ship upstream), we
want to give a suffix that matches the name of the configuration
snippet.
It seems more common to use [connection-*] instead of [connection.].
See also "examples/nm-conf.d/*.conf" and "15-carrier-timeout.conf" file
which contains a [device-15-carrier-timeout] section.
Note that this file (in Fedora) is not configuration (installed in
/usr/lib). It is thus not problematic to modify.
Fixes: ea8dbd7a6d ('contrib/rpm: add "22-wifi-mac-addr.conf" to F40+')
The group interface is only used during activation; there is no need
to add a pending action for it, because when the device is in
activating state it already delays "startup-complete" via other
pending actions.
The daemon is now capable of understanding and removing these prefix
tags by itself. It is better than this is not a responsibility of the
secret agent because it requires changes in all secret agents to work
properly (see https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1536).
If the secret agent knows what these prefix tags are, it can remove them
only in the text that is displayed in the UI, but maintaining the
original string as the secret name that is returned to the daemon.
Secret agents that doesn't know what these prefix tags are won't do
anything with them, and they will also return the same string as secret
name, as expected. The only drawback is that they might display the full
string to the user, which is not a nice UX but it will at least work.
Also, allow to translate the secret name for the UI in libnmc.
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.
Add explanation of how to indicate the new issues workflow to
MAINTAINERS.md: triage -> investigation -> devel. The different
stages are indicated using Gitlab's scoped labels (mutually exclusive).
These stages try to hightlight that the issue cannot be fixed and it's
not moving forward because more info is needed, already. Also, add a
section to CONTRIBUTING.md highlighting the importance of helping in
the triage and investigation stages: developers often cannot fix bugs
because lack of time to investigate, but even users that doesn't know
how to fix it due to lack of knowledge of the code base can help thanks
to their knowledge on networking.
Finally, make the 'triage:issues' CI job to work again, adding some
new policies with new automations. The automation will add or remove the
labels: stale, help-needed::{triage, investigation, devel} and
unassigned.
The labels help-needed::* and unassigned will be automatically added to
all issues without an assignee. This reflects better the reality of not
having enough time to work on most of the issues unless there is some
external help.
With the deprecation of autotools, use meson by default. For the moment,
it's still possible to build with autotools passing -a/--autotools.
Additionally, as we allow to specify different build directories other
than './build', let's not asume that the user wants to overwrite it
by default. Instead, the script will asume ./build if the user doesn't
specify the build directory, but only if it doesn't exist. If it does,
the user will have to force overwritting it with `--meson ./build`.
Instead of forcing to use ./build directory, let's make the the user
specify what directory he wants to use. This will allow to have multiple
build directories with different configurations as meson is designed to
allow, without having to overwrite the existing build one.
As Fedora 41 (currently Rawhide) is migrating to DNF5 [1], the
debuginfo-install command is not available anymore according to the
documentation. Instead, the user need to add the package suffix
"-debuginfo" when using the install command.
The implementation of the debuginfo-install plugin is under development
and tracked upstream. [2]
[1] https://fedoraproject.org/wiki/Changes/SwitchToDnf5
[2] https://github.com/rpm-software-management/dnf5/issues/389
Note: here I refer to the numbers in a version as MAJOR.MINOR.MICRO.
Having stable and development releases do make sense for the MINOR
version, because we maintain separate branches for them and they
evolve separately. We have 1.47.z where we put all the changes so
anyone can pick the latest development release and test it. At the
same time, we have 1.46.z with the latest stable released version.
However, it does not make sense to have 1.46.2 and 1.46.3-dev because
the latter is not a development version. It is identical to 1.46.2,
only the version number has been bumped, there are no changes to test.
When we add commits, we will be actually testing 1.46.3-dev + some
commits, which is exactly the same as testing 1.46.2 + some commits.
So, basically, someone can use the releases of a development BRANCH,
like 1.47.4, to test the development version of NM. But using a
development MICRO version is exactly the same as using a
non-development one.
From now on, we will just increment the MICRO version each time we do a
release on a stable branch and won't create the '-dev' tag. Update
release.sh to do it this way.
Although VPN plugins are developed separately, better to document here
how to do the release of those that we maintain to avoid having to do
the changes on every repository each time.
Usually, when the method is "auto" we want to avoid configuring routes
until the automatic method completes. To achieve that, we clear the
"allow_routes_without_address" flag of l3cds when the method is "auto".
For VPNs, IP configurations with only routes are perfectly valid,
therefore set the flag.
The name "dhcp_enabled" is misleading because the flag is set for
method=auto, which doesn't necessarily imply DHCP. Also, it doesn't
convey what the flag is used for. Rename it to
"allow_routes_without_address".
An IPv4-over-IPv6 (or vice-versa) IPsec VPN can return IP
configurations with routes and without addresses. For example, in this
scenario:
+---------------+ +---------------+
| fd01::10/64 <-- VPN --> fd02::20/64 |
| host1 | | host2 |
+-------^-------+ +-------^-------+
| |
+-------v-------+ +-------v-------+
| subnet1 | | subnet2 |
| 172.16.1.0/24 | | 172.16.2.0/24 |
+---------------+ +---------------+
host1 and host2 establish a IPv6 tunnel which encapsulates packets
between the two IPv4 subnets. Therefore, in routed mode, host1 will
need to configure a route like "172.16.2.0/24 via ipsec1" even if the
host doesn't have any IPv4 address on the VPN interface.
Accept IP configurations without address from the VPN; only check that
the address and prefix are sane if they are provided.
Translatable strings were added to nm-setting-generic.c. Add this file to
POTFILES.in.
Fixes: 9322c3e9db ('libnm: add generic.device-handler property')
Connection timestamps are updated (saved to disk) on connection up and
down. This way, the last used connection will take precedence for
autoconnect if they have the same priority.
But as we don't actually do connection down when NM stops, the last
connection timestamp of all active connections is the timestamp of when
they were brought up. Then, the activation order might be wrong on next
start.
One case where timestamps are wrong (although it is not clear how
important it is because the connections are activated on different
interfaces):
1. Activate con1 <- timestamp updated
2. Activate con2 <- timestamp updated
3. Deactivate con2 <- timestamp updated
4. Stop NM <- timestamp of con2 is higher than con1, but con1 was still
active when con2 was brought down.
Other case that is reproducible (from
https://issues.redhat.com/browse/RHEL-35539):
1. Activate con1
2. Activate con2 on same interface:
- As a consequence con1 is deactivated and its timestamp updated
- The timestamp of con2 is also updated
3. Stop NM <- timestamp of con1 and con2 is the same, next activation
order will be undefined.
Fix by saving the timestamps on NM shutdown.
Problem:
Given a OVS port with `autoconnect-ports` set to default or false,
when reactivation required for checkpoint rollback,
previous activated OVS interface will be in deactivate state after
checkpoint rollback.
The root cause:
The `activate_stage1_device_prepare()` will mark the device as
failed when controller is deactivating or deactivated.
In `activate_stage1_device_prepare()`, the controller device is
retrieved from NMActiveConnection, it will be NULL when NMActiveConnection
is in deactivated state. This will cause device been set to
`NM_DEVICE_STATE_REASON_DEPENDENCY_FAILED` which prevent all follow
up `autoconnect` actions.
Fix:
When noticing controller is deactivating or deactivated with reason
`NM_DEVICE_STATE_REASON_NEW_ACTIVATION`, use new function
`nm_active_connection_set_controller_dev()` to wait on controller
device state between NM_DEVICE_STATE_PREPARE and
NM_DEVICE_STATE_ACTIVATED. After that, use existing
`nm_active_connection_set_controller()` to use new
NMActiveConnection of controller to move on.
Resolves: https://issues.redhat.com/browse/RHEL-31972
Signed-off-by: Gris Ge <fge@redhat.com>
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.
We are planning on completely dropping Autotools in the future.
This breaks the build process with an argument to ignore the deprecation,
so that anyone building NM is warned of this change.
This job was supposed to run periodically. However, it stopped working
when a "workflow" section was added to .gitlab-ci.yml because it
prevented pipelines of the type "scheduled" to be created.
7fa72645e5 ('gitlab-ci: make detached MR pipeline for external contributor's pipelines to run')
Now, if it's run, it fails with error:
multi_xml requires Ruby version >= 3.1.4. The current ruby version is 2.7.8.225.
Let's disable the job until we fix it and we decide what triage we want
to do. When we do it, we will need to adapt the jobs to be run with the
right periodicity, maybe using custom pipeline variables.
This will force to regenerate the various images of the distributions
that we want to test so we get an updated snapshot on them. Otherwise we
might be testing a months old version of them.
A bug in ci-fairy was making the deletion of the images to partially
fail. It is fixed in the latest version of ci-fairy, so we need to
update the value of templates_sha to pick it.
The task will run only on pipelines of type "scheduled". Then we can
create a weekly scheduled pipeline in Gitlab.
- placeholder-job # The job mostly waits on network requests, so use only one CPU:https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/1358#note_2457416
- placeholder-job # The job mostly waits on network requests, so use only one CPU: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/1358#note_2457416
(Please see the DEBUGGING section of "[man NetworkManager](https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/NetworkManager.html)" and attach any relevant log)
Help other maintainers with the triage following these guidelines. This way, it
will be easier to find issues that require attention.
-Assign an issue to yourself if you are going to take care of providing the
required help. Assign it to another person if he/she is more suitable to help,
but do this quite rarely so we take care of not overloading to anyone.
-Workflow: indicate the current stage with the corresponding label:
-Add suitable labels to indicate the state of open issues:
-`workflow::triage`: needs triage to determine whether is a bug, an RFE or we
should close it.
-`workflow::investigation`: has been triaged but more info is needed to start
working on a fix. This step can be skipped if enough information is provided
during triage.
-`workflow::devel`: on development (or waiting for it).
- Closed: the issue is already solved, either via a code fix or via providing
the required info. Also if the request is clearly incorrect or doesn't fit
at all in the project.
- Assignee: assign the issue to the person that is working on it. This will
remove the `unassigned` and `help-needed::*` labels.
- Manual labels: add suitable labels to indicate the state of open issues:
-`need-info`: waiting for info or feedback from anyone.
-`good-first-issue`: the task is simple and well suited for a first time
contributor.
-`triaged::bug` / `triaged::RFE`: type of issue.
-`need-discussion`: something is not clear about what to do, or about if
something has to be done at all. The problem should be discussed by the
maintainers and/or with the reporter and/or other interested parts.
-`triaged`: if the problem is properly explained and understood. Add also
one of the labels `bug` or `RFE` as corresponds.
-`help-wanted`: request external contributors to work on this. If it's a
simple fix, add `good-first-issue` too.
-`work-in-progress`: anyone is already working on a Merge Request, so others.
-`blocked`: the issue is waiting for something that blocks its progress
-`close-proposed`: there are good reasons to reject the request (explain
those reasons when adding the label). If after a reasonable time there is no
additional info that is good enouch to reconsider it, the issue will be
closed.
It is not mandatory to always use this tag before closing an issue, but
usually desirable.
those reasons when adding the label) but a chance to others to provide
reasons against it is desired.
It is not mandatory to always use this tag.
-`Spam`: mark as spam, blocking the author. See [damspam](https://gitlab.freedesktop.org/freedesktop/damspam/-/blob/main/README.md?ref_type=heads).
-Close an issue if the problem is already solved, either via a code fix or via
some information that has been provided. Also if the request is clearly
incorrect or doesn't fit at all in the project.
-Automatic labels: some labels are automatically added and removed by a bot and
the maintainers don't need to care much about them. The label `stale` is
used for issues without activity for a long time. The labels `unassigned` and
`help-needed::{triage, investigation, devel}` are used for issues without an
assignee.
Merging Merge Requests
@@ -159,14 +172,116 @@ In practice when we want to backport new API from main we have two options:
19d7e66099ee43f47d6be0e740dc710fc365d200. Then, on main we add duplicate
symbols with commit 5eade4da11ee38a0e7faf4a87b2c2b5af07c5eeb.
### Reimporting systemd
NetworkManager release process
------------------------------
It's mostly automated by [release.sh](contrib/fedora/rpm/release.sh).
Before running the script:
- For stable releases, remember to backport all commits with "Fixes:" tag that
are applicable. Use the [find-backports](contrib/scripts/find-backports)
script to find them.
- Start all the jobs in the latest Gitlab pipeline of the right branch. The
script checks that they ran successfully.
Tiers 1 and 2 must pass, failed Tier 3 jobs can be fixed after the release.
The script also takes care of choosing the right version number depending on the
release type that you specify, like devel, rc1, rc, major, major-post, etc.
Run the script with `--help` to see all options.
Notes:
- You need a private token from gitlab.freedesktop.org with 'api' level access
to the project. It can be saved to `~/.config/nm-release-token` or passed to
the `--gitlab-token` argument of `release.sh`.
- The GPG key used to sign the tags must be exported to a keyserver.
Versioning scheme, automatically handled by the script (version numbers are
called MAJOR.MINOR.MICRO):
- Development releases has an odd MINOR version number (i.e. `1.47.2`).
- Stable releases has an even MINOR version number (i.e. `1.48.1`).
- Release candidates (RC) are tagged like `1.48-rc1`, `1.48-rc2`, etc. But in
NM's internal code they looks like `1.47.90`, `1.47.91`, etc. (MINOR is one
number less, and MICRO is >= 90).
The main differences between the different kind of releases are:
- Development releases: for development and testing purposes only.
- Release candidates (RC): stabilization phase before a stable release. Normally
there are one or two RCs with ~2 weeks cadence. More RCs can be releases if
they are needed.
- Stable releases: Releases within the same stable branch should remain very
stable while fixing important bugs, backported from `main`. New features are
added very rarely.
Stable branches are branched out from `main` to prepare the first release
candidate (RC) of the next stable branch. These branches are called `nm-MAJOR-MINOR`
(i.e. `nm-1-48`). As they are used to release stable versions, the last number
is always even.
There are some additional tasks that the script doesn't handle:
- For RC releases:
- The NEWS file should reflect a curated summary of the changes that the new
stable release will include.
- The release should be announced on the mailing list.
- For stable releases:
- The official documentation must be updated on the website when there is a new
stable release. Use the [import-docs.sh](https://gitlab.freedesktop.org/NetworkManager/networkmanager.pages.freedesktop.org/-/blob/main/scripts/import-docs.sh)
script from the website's repo.
- The release should be announced on the mailing list.
VPN plugins and nm-applet release process
-----------------------------------------
The same versioning scheme and release process is used for the VPN plugins,
nm-applet (including nm-connection-editor) and libnma.
Note that each of them is hosted in its own repository, but this is documented
here to avoid duplication, as the process is the same for all (at least for
those that we maintain).
Also note that there are no stable branches or development versions. Everything
is developed on main, and releases are done on main.
Versioning scheme (version numbers are called MAJOR.MINOR.MICRO):
- Small changes increments only the MICRO number.
- Bigger changes or new features increments the MINOR number.
- There is no strict criteria to define what change is small or big, but try to
adhere mostly to [semantic versioning](https://semver.org/).
- Use only even numbers for MINOR, skipping odd ones. That way we use the same
versioning scheme than the main NM project despite there are no development
versions here.
When doing a release, follow this process:
1. Ensure that `NEWS` file is up to date.
2. Increment the version in `meson.build`, commit and tag the commit. Example:
`git tag -s 1.2.8 -m 'Tag 1.2.8'`.
3. Ensure that you are on the right commit and create the tarball:
if ! check_gitlab_pipeline "$CUR_BRANCH""$CUR_HEAD";then
echo"Check the pipelines for branch \"$CUR_BRANCH\" at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/pipelines?ref=$CUR_BRANCH"
echo"Check the pipelines for branch \"$CUR_BRANCH\" at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/pipelines?ref=$CUR_BRANCH&source=push"
echo"Wait for pipeline with \`ci-fairy wait-for-pipeline --project NetworkManager/NetworkManager --sha \"$CUR_HEAD\"\`"
die "It seems not all gitlab-ci jobs were running/succeeding. Skip this check with --no-check-gitlab"
fi
@@ -511,27 +512,23 @@ case "$RELEASE_MODE" in
esac
build_tag(){
localBUILD_TAG="$1"
localTAR_FILE="NetworkManager-$2.tar.xz"
localSUM_FILE="$TAR_FILE.sha256sum"
git checkout "$BUILD_TAG"|| die "failed to checkout $BUILD_TAG"
./contrib/fedora/rpm/build_clean.sh -r || die "build release failed"
test -f"./build/meson-dist/$RELEASE_FILE"\
|| die "release file \"./build/meson-dist/$RELEASE_FILE\" not found"
cp "./build/meson-dist/$RELEASE_FILE" /tmp/ || die "failed to copy release tarball to /tmp"
@@ -203,7 +203,7 @@ complain ("Don't use g_direct_equal() for hash tables, pass NULL for pointer equ
complain("Prefer nm_pint_hash()/nm_pint64_hash()/nm_pdouble_hash() over g_int_hash()/g_int64_hash()/g_double_hash(). Those use siphash24")if$line=~ /\b(g_int_hash|g_int64_hash|g_double_hash)\b/;
complain("Prefer nm_pint_equal()/nm_pint64_equal()/nm_pdouble_equal() over g_int_equal()/g_int64_equal()/g_double_equal(). Those names mirror our nm_p*_hash() functions")if$line=~ /\b(g_int_equal|g_int64_equal|g_double_equal)\b/;
complain("Avoid g_clear_pointer() and use nm_clear_pointer() (or nm_clear_g_free(), g_clear_object(), etc.)")if$line=~ /\b(g_clear_pointer)\b/;
complain("Define setting properties with _nm_setting_property_define_direct_*() API")if$line=~ /g_param_spec_/and$filename=~ /\/libnm-core-impl\/nm-setting/;
complain("Define setting properties with _nm_setting_property_define_direct_*() API")if$line=~ /g_param_spec_/and$filename=~ /\/libnm-core-impl\/nm-setting/and(not$filename=~ /\/nm-setting-ip-config.c$/);
complain("Use nm_g_array_{index,first,last,index_p}() instead of g_array_index(), as it nm_assert()s for valid element size and out-of-bound access")if$line=~ /\bg_array_index\b/;
complain("Use spaces instead of tabs")if$line=~ /\t/;
complain("Prefer implementing private pointers via _NM_GET_PRIVATE() or _NM_GET_PRIVATE_PTR() (the latter, if the private data has an opqaue pointer in the header file)")if$line=~ /\b(g_type_class_add_private|G_TYPE_INSTANCE_GET_PRIVATE)\b/;
@@ -304,8 +304,8 @@ Note that the unmanaged flags are tracked via two variables
practice a tri-state variable with possible values TRUE (unmanaged),
FALSE (managed) and UNSET.
External devices and sys-iface-state
------------------------------------
External devices and managed-type
---------------------------------
Even if a device is managed, that doesn't mean that NetworkManager is
actively configuring it. When a device is created externally (for
@@ -314,9 +314,9 @@ creates a in-memory connection representing the configuration
parameters on the interface such as IP addresses, routes, DNS, etc.;
the connection appears as active but NetworkManager doesn't actually
touch the interface. The external status is tracked in the
`sys-iface-state` member, which can have the following values:
`managed-type` member, which can have the following values:
- EXTERNAL: the interface is not touched by NM.
- ASSUME: this value is deprecated; it used to mean that NM should manage the device without fully reconfiguring it. Now, the interface is either managed on external.
<mxCell id="SsSxIaJ2XBONRL21woKM-4" value="Build a sorted list of devices eligible for hostname evaluation" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" vertex="1" parent="WIyWlLk6GJQsqaUBKTNV-1">
<mxCell id="SsSxIaJ2XBONRL21woKM-8" value="For each device in the list" style="swimlane;whiteSpace=wrap;html=1;strokeWidth=2;strokeColor=#7EA6E0;" vertex="1" parent="WIyWlLk6GJQsqaUBKTNV-1">
echo"WARNING: The generated documentation has issues. Patch your gtk-doc (see https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/2). Let this check fail with NMTST_CHECK_GTK_DOC=1";\
@connection: The optional connection settings that will be reapplied on the device. If empty, the currently active settings-connection will be used. The connection cannot arbitrarily differ from the current applied-connection otherwise the call will fail. Only certain changes are supported, like adding or removing IP addresses.
@version_id: If non-zero, the current version id of the applied-connection must match. The current version id can be retrieved via GetAppliedConnection. This optional argument allows to catch concurrent modifications between the GetAppliedConnection call and Reapply.
@version_id: If non-zero, the current version id of the applied-connection must match. The current version id can be retrieved via GetAppliedConnection. This optional argument allows one to catch concurrent modifications between the GetAppliedConnection call and Reapply.
@flags: Flags which would modify the behavior of the Reapply call. Invalid flags are rejected.
Attempts to update the configuration of a device without deactivating it.
@@ -337,7 +337,7 @@
settings-connection, or call Reapply. The Reapply call allows you to
directly update the applied-connection and reconfigure the device. Reapply
can also be useful if the currently applied-connection is equal to the
connection that is about to be reapplied. This allows to reconfigure the
connection that is about to be reapplied. This allows one to reconfigure the
device and revert external changes like removing or adding an IP address
(which NetworkManager doesn't revert automatically because it is assumed
that the user made these changes intentionally outside of NetworkManager).
<listitem><para>Whether it is sufficient for any ping check to succeed among the list of target addresses, or if all ping checks must succeed for the entire list of target addresses.</para></listitem>
<listitem><para>If unspecified, MUD URL defaults to <literal>"none"</literal>.</para></listitem>
@@ -933,6 +941,13 @@ ipv6.ip6-privacy=0
<term><varname>ip-tunnel.mtu</varname></term>
<listitem><para>If configured explicitly to 0, the MTU is not reconfigured during device activation unless it is required due to IPv6 constraints. If left unspecified, a DHCP/IPv6 SLAAC provided value is used or a default of 1500.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ipv4.forwarding</varname></term>
<listitem><para>Whether to configure IPv4 sysctl interface-specific forwarding. When enabled, the interface will act as a router to forward the IPv4 packet from one interface to another. If left unspecified, "auto" is used, so NetworkManager sets the IPv4 forwarding if any shared connection is active, or it will use the kernel default value otherwise. The "ipv4.forwarding" property is ignored when "ipv4.method" is set to "shared", because forwarding is always enabled in this case. The accepted values are: 0: disabled, 1: enabled, 2: auto, 3: ignored (leave the forwarding unchanged).</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ipv4.routed-dns</varname></term>
</varlistentry>
<varlistentry>
<term><varname>ipv4.dad-timeout</varname></term>
</varlistentry>
@@ -946,10 +961,18 @@ ipv6.ip6-privacy=0
<term><varname>ipv4.dhcp-iaid</varname></term>
<listitem><para>If left unspecified, it defaults to "ifname".</para></listitem>
<listitem><para>Whether a hostname is sent to the DHCP server when acquiring a lease. When the property is not specified in the connection, the global value from NetworkManager configuration is looked up. If the global value is not set, the value from ipv4.dhcp-send-hostname-deprecated, which defaults to true, is used for backwards compatibility. In the future this will change and, in absence of a global default, it will always fallback to true.</para></listitem>
<listitem><para>Whether a hostname is sent to the DHCP server when acquiring a lease. When the property is not specified in the connection, the global value from NetworkManager configuration is looked up. If the global value is not set, the value from ipv6.dhcp-send-hostname-deprecated, which defaults to true, is used for backwards compatibility. In the future this will change and, in absence of a global default, it will always fallback to true.</para></listitem>
error('Building manpages requires xsltproc and -Dintrospection=true, and no prebuilt manpages were found. Try building from a release tarball or using -Dman=false.')
option('nbft',type:'boolean',value:true,description:'Enable NBFT support in the initrd generator')
# configuration plugins
option('config_plugins_default',type:'string',value:'',description:'Default configuration option for main.plugins setting, used as fallback if the configuration option is unset')
option('config_dns_rc_manager_default',type:'combo',choices:['auto','symlink','file','netconfig','resolvconf'],value:'auto',description:'Configure default value for main.rc-manager setting')
option('config_dhcp_default',type:'combo',choices:['dhcpcanon','dhclient','dhcpcd','internal','nettools'],value:'internal',description:'Default configuration option for main.dhcp setting, used as fallback if the configuration option is unset')
option('config_dhcp_default',type:'combo',choices:['dhclient','dhcpcd','internal','nettools'],value:'internal',description:'Default configuration option for main.dhcp setting, used as fallback if the configuration option is unset')
# miscellaneous
option('introspection',type:'boolean',value:true,description:'Enable introspection for this build')
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
