NM_DHCP_STATE_DONE is for when the client reports that it is shutting
down. If we manually stop it, we should set the TERMINATED state, so
that NMDevice doesn't start a grace period waiting for a renewal.
This fixes the:
device (enp1s0): DHCPv4: trying to acquire a new lease within 90 seconds
message printed when NM is shutting down.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/802
(cherry picked from commit 4784c7dccd)
This reverts commit 389575a6b1.
When the command line contains BOOTIF and there is another ip=
argument specifying an interface name, we can follow 2 approaches:
a) BOOTIF creates a new distinct connection with DHCP
(the behaviour before the commit)
b) the connection generated for ip= will be also be bound to the
BOOTIF MAC (the behavior introduced by the commit)
Restore a) because we can't be sure that the MAC address refers to the
same interface. In that case it's preferable to generate a different
connection.
https://bugzilla.redhat.com/show_bug.cgi?id=1915493#c35
(cherry picked from commit c21d4ce125)
The goal of this code is to detect python, but prefer python3 while
also allowing the user to override the path.
That did not work in all cases, due to what seems like a bug in
AM_PATH_PYTHON(). AM_PATH_PYTHON() is documented to ignore failure
if [action-if-not-found] is given. So one might assume that:
AM_PATH_PYTHON([3], [], [PYTHON=])
if test -z "$PYTHON"; then
AM_PATH_PYTHON([], [], [PYTHON=python])
fi
first tries to look for v3, and if that fails search for any python
interpreter. That did not work however with:
$ ./configure PYTHON=/usr/bin/python2
...
checking pkg-config is at least version 0.9.0... yes
checking whether /usr/bin/python2 version is >= 3... no
configure: error: Python interpreter is too old
because the first AM_PATH_PYTHON() is fatal.
Work around that.
Fixes: 54a1cfa973 ('build: prefer python3 over python2 in autotools's configure script')
(cherry picked from commit 91bf576a43)
It's not entirely clear how to treat %NULL.
Clearly "match.interface-name=eth0" should not
match with an interface %NULL. But what about
"match.interface-name=!eth0"? It's now implemented
that negative matches still succeed against %NULL.
What about "match.interface-name=*"? That probably
should also match with %NULL. So we treat %NULL really
like "".
Against commit 11cd443448 ('iwd: Don't call IWD methods when device
unmanaged'), we got this backtrace:
#0 0x00007f1c164069f1 in __strnlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
#1 0x00007f1c1637ac9e in __fnmatch (pattern=<optimized out>, string=<optimized out>, string@entry=0x0, flags=flags@entry=0) at fnmatch.c:379
p = 0x0
res = <optimized out>
orig_pattern = <optimized out>
n = <optimized out>
wpattern = 0x7fff8d860730 L"pci-0000:03:00.0"
ps = {__count = 0, __value = {__wch = 0, __wchb = "\000\000\000"}}
wpattern_malloc = 0x0
wstring_malloc = 0x0
wstring = <optimized out>
alloca_used = 80
__PRETTY_FUNCTION__ = "__fnmatch"
#2 0x0000564484a978bf in nm_wildcard_match_check (str=0x0, patterns=<optimized out>, num_patterns=<optimized out>) at src/core/nm-core-utils.c:1959
is_inverted = 0
is_mandatory = 0
match = <optimized out>
p = 0x564486c43fa0 "pci-0000:03:00.0"
has_optional = 0
has_any_optional = 0
i = <optimized out>
#3 0x0000564484bf4797 in check_connection_compatible (self=<optimized out>, connection=<optimized out>, error=0x0) at src/core/devices/nm-device.c:7499
patterns = <optimized out>
device_driver = 0x564486c76bd0 "veth"
num_patterns = 1
priv = 0x564486cbe0b0
__func__ = "check_connection_compatible"
device_iface = <optimized out>
local = 0x564486c99a60
conn_iface = 0x0
klass = <optimized out>
s_match = 0x564486c63df0 [NMSettingMatch]
#4 0x0000564484c38491 in check_connection_compatible (device=0x564486cbe590 [NMDeviceVeth], connection=0x564486c6b160, error=0x0) at src/core/devices/nm-device-ethernet.c:348
self = 0x564486cbe590 [NMDeviceVeth]
s_wired = <optimized out>
Fixes: 3ced486f41 ('libnm/match: extend syntax for match patterns with '|', '&', '!' and '\\'')
https://bugzilla.redhat.com/show_bug.cgi?id=1942741
(cherry picked from commit 420784e342)
When adding an IPv4 address, kernel automatically adds a local route.
This is done by fib_add_ifaddr(). Note that if the address is
IFA_F_SECONDARY, then the "src" is the primary address. That means, with
nmcli connection add con-name t type ethernet ifname t autoconnect no \
ipv4.method manual ipv6.method disabled \
ipv4.addresses '192.168.77.10/24, 192.168.77.11/24'
we get two routes:
"local 192.168.77.10 dev t table local proto kernel scope host src 192.168.77.10"
"local 192.168.77.11 dev t table local proto kernel scope host src 192.168.77.10"
Our code would only generate instead:
"local 192.168.77.10 dev t table local proto kernel scope host src 192.168.77.10"
"local 192.168.77.11 dev t table local proto kernel scope host src 192.168.77.11"
Afterwards, this artificial route will be leaked:
#!/bin/bash
set -vx
nmcli connection delete t || :
ip link delete t || :
ip link add name t type veth peer t-veth
nmcli connection add con-name t type ethernet ifname t autoconnect no ipv4.method manual ipv4.addresses '192.168.77.10/24, 192.168.77.11/24' ipv6.method disabled
nmcli connection up t
ip route show table all dev t | grep --color '^\|192.168.77.11'
sleep 1
nmcli device modify t -ipv4.addresses 192.168.77.11/24
ip route show table all dev t | grep --color '^\|192.168.77.11'
ip route show table all dev t | grep -q 192.168.77.11 && echo "the local route 192.168.77.11 is still there, because NM adds a local route with wrong pref-src"
It will also be leaked because in the example above ipv4.route-table is
unset, so we are not in full route sync mode and the local table is not
synced.
This was introduced by commit 3e5fc04df3 ('core: add dependent local
routes configured by kernel'), but it's unclear to me why we really need
this. Drop it again and effectively revert commit 3e5fc04df3 ('core:
add dependent local routes configured by kernel').
I think this "solution" is still bad. We need to improve our route sync
approach with L3Cfg rework. For now, it's probably good enough.
https://bugzilla.redhat.com/show_bug.cgi?id=1907661
(cherry picked from commit 557644f5e0)
This effectively reverts commit cd89026c5f ('core: add dependent
multicast route configured by kernel for IPv6').
It's not clear to me why this was done or why it would be correct.
True, kernel automatically adds multicast route like
multicast ff00::/8 dev $IFACE table local proto kernel metric 256 pref medium
But NetworkManager ignores all multicast routes for now. So the dependent
routes cannot contain multicast routes as they are not handled. Also,
the code added a unicast route, so I don't understand why the comment
is talking about multicast.
This seems just wrong. Drop it.
(cherry picked from commit c29d995000)
When we deactivate a device, we flush all IP addresses and
routes. Thus, have yet another sync mode for that. It will sync more
than "ALL".
(cherry picked from commit e226b5eb82)
When using IWD-side autoconnect mode (current default), in .deactivate()
and .deactivate_async() refrain from commanding IWD to actually
disconnect until the device is managed. Likely the device is already
disconnected but in any case it's up to IWD to decide in this mode.
Calling IWD device's .Disconnect() D-Bus method has the side effect of
disabling autoconnect and doing this while NM is still in platform-init
was unexpectedly leaving the device without autoconnect after
platform-init was done, according to user reports.
Fixes: dc0e31fb70 ('iwd: Add the wifi.iwd.autoconnect setting')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/786
(cherry picked from commit 1708e9a3cc)
Ignore a rd.znet argument without subchannels. When using net.ifnames
(the default), subchannels are used to build the interface name, which
is required to match the right connection.
With net.ifnames=0 the interface name is build using a prefix and a
global counter and therefore in theory it is possible to omit
subchannels. However, without subchannels there won't be a udev rule
that renames the interface and so it can't work.
https://bugzilla.redhat.com/show_bug.cgi?id=1931284https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/783
(cherry picked from commit 0f8fe3c76b)
The idea of NM_G_MUTEX_LOCKED() macro is not only to register a mutex
for unlocking (via nm_auto_unlock_g_mutex) but also to lock it at
the same time.
That is a useful helper macro. If you have to lock the mutex yourself,
it makes usage less convenient. At which point you don't need the macro
anymore and you should instead take full control and lock/unlock yourself.
Fix the macro and change behavior. The macro was not used so far, so
it's not a problem.
Fixes: dd33b3a14e ('shared: add nm_auto_unlock_g_mutex and NM_G_MUTEX_LOCKED() helper macros')
(cherry picked from commit 098ac7dbc0)
802-1x.optional=yes means that NM should tolerate a failure or a
timeout of the 802.1X authentication and should keep the connection
up. Even if the authentication doesn't succeed, NM keeps the
supplicant running so that it can continue trying.
If the supplicant disappears because it crashed or was killed
externally, NM should fail the connection so that it can be retried.
The current code is wrong also because after releasing the supplicant
interface, it calls wired_auth_cond_fail() which tries to connect a
signal to priv->supplicant.iface (which is NULL).
https://bugzilla.redhat.com/show_bug.cgi?id=1934291https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/776
(cherry picked from commit 840e54a96c)
If an existing connection has an interface name set and the generator
finds a BOOTIF argument, it creates a new connection for BOOTIF.
Instead, the generator should set the MAC in the existing connection;
this sounds more correct and it is what the network-legacy module
does.
https://bugzilla.redhat.com/show_bug.cgi?id=1915493
(cherry picked from commit 389575a6b1)
Currently we unconditionally reset the MAC to the previous value after
releasing ports. This has some disadvantages:
- by default, after the last port is removed the bond will have one
of the previous port's address, which could conflict with the port;
- in some cases, changing the bond MAC is not possible. For example
when the bond is active-backup and has fail_over_mac=1|2. In such
case the netlink call succeeds, but the address doesn't
change; then NM would keep waiting for some time.
Don't try to restore the MAC unless the bond connection has a cloned
MAC set.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/775
(cherry picked from commit 190fd9aa9f)
With systemd-resolved, NetworkManager considers `/etc/resolv.conf`
unmanaged. This breaks hostname lookups in a subtle way: when a new
connection comes online, NM will initiate the hostname lookup *before*
propagating DNS updates to systemd-resolved, which of course will cause
the request to fail. And because NM doesn't update `/etc/resolv.conf`,
it doesn't emit a `CONFIG_CHANGED` signal which would've restarted the
lookup.
Fix this by emitting a signal also when using a caching DNS plugin.
https://bugzilla.redhat.com/show_bug.cgi?id=1933863https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/770
(cherry picked from commit 1c0932a6e6)
The bond option ad_actor_system only matters (and is available) with
mode=802.3ad.
When you create a new bond, the sysctl value will be set to "00:00:00:00:00:00".
So this seems to be a valid value, and in fact the default value for
this option. However, kernel will fail with EINVAL to set the sysctl to
"00:00:00:00:00:00". Kernel fails both if the value is already
"00:00:00:00:00:00" (i.e. setting the same value results in an error) and
it also fails otherwise (i.e. we cannot ever reset the value to
"00:00:00:00:00:00", at least not via sysfs).
Avoid the warning in the common case, where the value is already as
expected.
Otherwise, we still get the warning and won't be able to set the right
value. But this is really a limitation of the kernel API where we cannot
do anything about it (in NetworkManager).
https://bugzilla.redhat.com/show_bug.cgi?id=1923999
(cherry picked from commit 9e7af31454)
A connection with key-mgmt=wpa-psk should be able to connect to WPA,
WPA2 and WPA3 APs, choosing the best candidate automatically.
Also pass SAE (WPA3) key-mgmt to wpa_supplicant when it is supported.
For example, I now get this when connecting to a WPA2 network:
<info> [1613749711.2915] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK SAE FT-SAE'
(cherry picked from commit f5d78c2d28)
fixes segfault with iwd backend after upgrade to NetworkManager 1.30.0
Signed-off-by: Jan Palus <jpalus@fastmail.com>
Fixes: 43fd93d8f4 ('iwd: Order objects from g_dbus_object_manager_get_objects')
(cherry picked from commit 2e0752b1bf)
"--with test" does two things:
(1) it enables "-Werror" compiler option. We always enable all
compiler warnings we care about, but this option makes all
warnings fatal.
Compiler warnings depend on compiler version and build options.
It's hard to build without any compiler warnings, in particular
for *future* compiler versions which we don't know yet. It
is desirable that a SRPM from yesterday can also be build
tomorrow.
(2) it fails build if any unit tests fail. We always run all
unit tests, but "--with test" makes it fatal. Again, we
have many unit tests that interact with the system (that is,
make system calls, like creating IP addresses or write files).
It is surprisingly hard to get them pass 100% on all the systems
we care. For example, on copr a test setup randomly fails during
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
nm_utils_ifname_cpy(ifr.ifr_name, TEST_IFNAME);
r = ioctl(fd, TUNSETIFF, &ifr);
It's not clear why, nor is it at all clear that there is a bug
in NetworkManager. Making tests fatal basically means that a build
on copr infrastructure fails with a probability from a few percent.
Enough to be seriously annoying.
Note that on copr we actually build "--with test", because we want to catch these
issues. Likewise for our CI builds we explicitly specify "--with test".
In general, we build with various build configurations (compiler warnings)
and run unit tests on a source package many times. Starting on the
developer machine (`make check`), gitlab-ci, copr builds,
NetworkManager-ci. If you build an SRPM with such sources, a failure
of the unit tests is much more likely a glitch than an actual issue.
This is about changing the default if you build a Fedora/RHEL package.
That is with the Fedora/RHEL packages that are build in koji/brew.
Well, at least usually. In practice, we don't build frequently on non
x64_86 archs, so what I said there is less true. But the package build
is not there to replace CI/testing. The package build is there to get
a (mostly) working binary.
Note that RHEL packages anyway go through rpmdiff too, and rpmdiff
parses the build log and complain if `make check` fails.
This reverts commit e68e5c0a4c.
(cherry picked from commit e23bafe5d5)
/route/ip6: NMPlatformSignalAssert: ../src/core/platform/tests/test-route.c:449, test_ip6_route(): failure to accept signal one time: 'ip6-route-changed-added' ifindex 0 (2 times received)
(cherry picked from commit 39c3eacb7d)
