It seems it can happen that the service is not yet unregistered from the
D-Bus broker, even if we already reaped the PID.
/builds/NetworkManager/NetworkManager/tools/run-nm-test.sh --called-from-make /builds/NetworkManager/NetworkManager/build --launch-dbus=auto /builds/NetworkManager/NetworkManager/build/libnm/tests/test-nm-client
--- stdout ---
/libnm/device-added:
nmtst: initialize nmtst_get_rand() with NMTST_SEED_RAND=0
--- stderr ---
**
test:ERROR:../shared/nm-test-utils-impl.c:216:nmtstc_service_cleanup: assertion failed: (!name_exists(info->bus, "org.freedesktop.NetworkManager"))
Workaround by waiting a bit.
We now iterate the main GMainContext, unlike before. But that
should not cause any problems for the test.
(cherry picked from commit 1b8ccacc5d)
(cherry picked from commit d10d14d7ba)
(cherry picked from commit d34e6193da)
(cherry picked from commit b430298133)
(cherry picked from commit 2009025c46)
(cherry picked from commit 0958a291b0)
nmtst_main_context_iterate_until() is a macro, and we don't want to restrict the
valid integer type (or range) of the "timeout_msec" argument.
In particular, if the user calculates a timeout with "timestamp_msec -
now_msec", the resulting "timeout_msec" might be a negative gint64.
We should handle that gracefully, and not let it be cast to a huge
unsigned int.
(cherry picked from commit 6cb6888404)
(cherry picked from commit 4d572bea7e)
(cherry picked from commit 95b74a3bde)
(cherry picked from commit 500c63db3c)
(cherry picked from commit e8a5cee1a1)
(cherry picked from commit c909149c13)
Like nmtst_main_context_iterate_until_assert(), but allows to
run into timeout.
(cherry picked from commit f2baa10bb8)
(cherry picked from commit 3e41eb83f7)
(cherry picked from commit 6237d89cf1)
nmtst_main_context_iterate_until*() iterates until the condition is
satisfied. If that doesn't happen within timeout, it fails an assertion.
Rename the function to make that clearer.
(cherry picked from commit 90bb46c8ee)
(cherry picked from commit 68800febf1)
(cherry picked from commit 1d10ff8454)
On Fedora 33 when compiling NetworkManager it is failing with the
following error:
```
ERROR: files left in build directory after distclean:
./docs/libnm/libnm.actions
make[1]: *** [Makefile:18427: distcleancheck] Error 1
make[1]: Leaving directory '/builddir/nm-build/NetworkManager/NetworkManager-1.27.90/_build/sub'
make: *** [Makefile:18356: distcheck] Error 1
Error make distcheck
```
Adding the file to the DISTCLEANFILES will enforce the removal of this
file.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/659
(cherry picked from commit 9a935e516e)
(cherry picked from commit d28133ad0d)
(cherry picked from commit e1c1369eef)
(cherry picked from commit 51b73ae63a)
(cherry picked from commit 0ea81a3d24)
(cherry picked from commit c4cb3ecae7)
The gtk-doc text that the tool receives is not XML, it's a plain text.
When setting the plain text as XML attribute, we need to properly escape
it. The previous XML escape code was naive, and didn't cover for a
plain ampersand.
[thaller@redhat.com: adjusted patch during backport from nm-1-26 to nm-1-24]
(cherry picked from commit 1641cc1d03)
(cherry picked from commit 5b7d39f8e1)
(cherry picked from commit 5c50280bc6)
(cherry picked from commit aef7a0a65d)
(cherry picked from commit ec277f8aeb)
nm_setting_ip_config_next_valid_dns_option() API was added in libnm 1.2, but
it was never exported in the ABI of libnm. It thus was unusable, and any user
trying to link against it would have been unable to do so.
Hide the API now entirely. It doesn't seem a very nice API. If we want to
allow the user to validate option names, we should expose such a function
to validate an option (not to fetch the next valid option from a
profile).
Fixes: 019943bb5d ('libnm-core: add dns-options property to NMSettingIPConfig')
(cherry picked from commit e8e5c12480)
(cherry picked from commit 04946f71ea)
(cherry picked from commit 098e713ced)
(cherry picked from commit d32148fd66)
(cherry picked from commit e555314480)
Fixes: 5e71f01605 ('device: merge stage3 and stage4 ip-config function for IPv4 and IPv6')
(cherry picked from commit a017936223)
(cherry picked from commit 0adfcadc9d)
(cherry picked from commit 1438d5a9f0)
(cherry picked from commit 584f467e13)
(cherry picked from commit a6490db945)
The detection for Ubuntu 16.04 was broken. By now /etc/os-release
contains
VERSION="16.04.7 LTS (Xenial Xerus)"
(cherry picked from commit 12e8557476)
(cherry picked from commit 9f7736ea8e)
(cherry picked from commit 89e01a1936)
(cherry picked from commit deb53ff5a2)
(cherry picked from commit 7921d3fb4c)
On Ubuntu 20.10, we build against ModemManager 1.14.0 and get a compiler warning:
../src/devices/wwan/nm-modem-broadband.c: In function 'try_create_connect_properties':
../src/devices/wwan/nm-modem-broadband.c:492:2: error: 'MMModemCapabilityDeprecated' is deprecated [-Werror=deprecated-declarations]
492 | if (MODEM_CAPS_3GPP (ctx->caps)) {
| ^~
Suppress it.
An alternative would be to drop the flag entirely. It seems the flag
was never used (and never will be used). But if that's true, there is
little harm done checking it. If it's not true, we better keep checking
for older versions.
0cd76bf1c4
(cherry picked from commit 03dc759026)
(cherry picked from commit 12e4a4a5df)
(cherry picked from commit b672944603)
(cherry picked from commit fb93ca2851)
(cherry picked from commit e3e0a2624b)
The matchfilecon API is deprecated for a very long time. Since selinux 3.1
the functions are also marked as deprecated in the header, which causes
compiler warnings and build failures.
Update the code to use selabel API instead.
(cherry picked from commit 173533c3b2)
(cherry picked from commit f5aafb9da4)
(cherry picked from commit bde9f1023f)
(cherry picked from commit 67135e64c9)
(cherry picked from commit 2014626b1e)
On Fedora rawhide (34), valgrind gives a lot of warnings like:
./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- WARNING: unhandled amd64-linux syscall: 439
./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- You may be able to write your own handler.
./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- Nevertheless we consider this a bug. Please report
./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- it at http://valgrind.org/support/bug_reports.html.
Ignore them.
(cherry picked from commit 2cb40f6e36)
(cherry picked from commit 561bd7bba6)
(cherry picked from commit 09b5a72b0f)
(cherry picked from commit e815592919)
(cherry picked from commit 8fb90c00d0)
g_steal_pointer() is marked as GLIB_AVAILABLE_STATIC_INLINE_IN_2_44,
that means we get a deprecated warning. Avoid that. We anyway
re-implement the macro so that we can use it before 2.44 and so
that it always does the typeof() cast.
(cherry picked from commit edfe9fa9a2)
(cherry picked from commit 6936a0613c)
(cherry picked from commit e333a28b97)
(cherry picked from commit 2283cd98f9)
Syslog's "facility" is a well defined thing and must be
one of a few well-known numbers. Don't re-use it for our
own purposes.
Fixes: 1b808d3b25 ('logging: add native systemd-journald support to nm-logging')
https://bugzilla.redhat.com/show_bug.cgi?id=1709741
(cherry picked from commit cc2553e871)
This overflow could only happen when we would try to log a message
with "NM_DEVICE=", "NM_CONNECTION=", and more than 8 logging domains
(_NUM_MAX_FIELDS_SYSLOG_FACILITY - 2).
The latter is never the case. While we sometimes log messages with
more than one logging domain, there are no logging statements that
use most as 8 different logging domains. So, this overflow is not
actually reachable from current code (I think).
Fixes: ed552c732c ('logging: log device and connection along with the message'):
(cherry picked from commit 138c187376)
The previous code returned that the device was available when it had
only unmanaged-flags that can be overridden by user, without actually
considering the @flags argument.
Fixes: 920346a5b9 ('device: add and use overrule-unmanaged flag for nm_device_check_connection_available()')
(cherry picked from commit c7fd4aeecf)
Only happens with debug logging enabled. So, not a large problem.
Found by Coverity.
Fixes: d9a4b59c18 ('acd: adapt NM code and build options')
(cherry picked from commit 0300c1823a)
(cherry picked from commit faf12086c1)
The Bluetooth DUN device's NMModem would signal the reset of ifindex to zero
when it's disconnected and the NMDeviceBt would accordingly update the
bluetooth device's ip ifindex. This is not okay since commit ab4578302d
('device: refactor nm_device_set_ip_ifindex() and set_ip_iface()') which,
although claiming to be a refactoring, made such use of
nm_device_set_ip_ifindex() illegal. Resetting the ifindex is anyway not
necessary, since it's taken care of _cleanup_generic_post().
Let's leave the ifindex alone once the device is activated, in a manner
analogous to what NMDeviceModem.
Fixes: ab4578302d ('device: refactor nm_device_set_ip_ifindex() and set_ip_iface()')
Fixes: 78ca2a70c7 ('device: don't set invalid ip-iface'):
(cherry picked from commit a5ca504b5b)
(cherry picked from commit fb874e6cda)
PMF can be used with SAE, allow it. Actually, it is required according
to WPA3 specifications but there are implementations that don't
require it (hostapd can be configured in a such way); so let's not
make it mandatory for WPA3.
Fixes: 6640fb4b36 ('supplicant: add support for SAE key management')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/257
(cherry picked from commit e36c297fd8)
(cherry picked from commit 299fbc0888)
Autoconnect-slaves currently forces an activation of all slaves, even
if there is already an active connection for them. This is bad because
at boot slaves first try to autoconnect, then the autoconnect-slaves
of the master kicks in and disconnects/reactivates them.
The only reason why the forceful reactivation was added was to fix
[1]; in that scenario, a slave connection is already active as
non-slave; then it is updated to be a slave; later, the master with
autoconnect-slaves is manually activated. NetworkManager should detect
that the slave connection must now be activated by autoconnect-slaves.
Add a specific check for such situation, instead of always
reactivating all slaves.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1845018
Fixes: 4985ca5ada ('manager: allow autoconnect-slaves to reconnect the same connection')
(cherry picked from commit 024e983c8e)
(cherry picked from commit d07d515dd7)
(cherry picked from commit 4df63b205e)
(cherry picked from commit a2e3f70e83)
In the past, kernel (and NetworkManager) did not support the onlink
flags for IPv6 routes. That is no longer the case.
Fixes: f5e8bbc8e0 ('libnm,core: enable "onlink" flags also for IPv6 routes')
(cherry picked from commit e7816a2508)
(cherry picked from commit 98c4bdec39)
A function that accepts a floating variant must consume it.
Fixes: 7691fe5753 ('libnm: add new functions allowing passing options to RequestScan() D-Bus call')
(cherry picked from commit 40911fb99b)
(cherry picked from commit 27301fe268)
nm_client_add_and_activate_connection_async() must be completed by
nm_client_add_and_activate_connection_finish().
Fixes: be8060f42f ('libnm: add an object-creation-failed test')
(cherry picked from commit 256ba8c4cd)
(cherry picked from commit 23d9f55c10)
Backport: don't actually add the API. The patch does nothing, it merely
contains a reference to the cherry-picked commit to satisfy
find-backports scripts. I don't think we should belatedly add this API
in old stable releases.
Fixes: 5f30a2b525 ('libnm: add accessors for ovs port/bridge slaves')
(cherry picked from commit f1bd85634a)
(cherry picked from commit df6f73c274)
It's unnecessary and makes the function unnecessarily not thread safe.
Of course, also ndp_msg_opt_route_prefix() uses static variables, so
it's still not thread safe.
Fixes: c3a4656a68 ('rdisc: libndp implementation')
(cherry picked from commit fbb65de32e)
(cherry picked from commit a1a3cce6ef)
(cherry picked from commit 2f419e84c8)
Just looking at the hashtable entry of 'updelay' and 'downdelay' options
is wrong, we have to inspect their values to check if they're
actually enabled or not.
Otherwise bond connections with valid settings will fail
when created:
$ nmcli c add type bond ifname bond99 bond.options miimon=0,updelay=0,mode=0
Error: Failed to add 'bond-bond99' connection: bond.options: 'updelay' option requires 'miimon' option to be set
Also add unit tests.
https://bugzilla.redhat.com/show_bug.cgi?id=1805184
Fixes: d595f7843e ('libnm: add libnm/libnm-core (part 1)')
(cherry picked from commit 50da785be1)
(cherry picked from commit 2644b0c753)
(cherry picked from commit a8846619aa)
