Surisingly, the compiler may detect the remaining obj_type in
the default switch. Then, inlining nmp_class_from_type() it may detect
that this is only possible to hit with an out or range access to
_nmp_classes array.
Rework the code to avoid that compiler warning. It's either way not
supposed to happen.
Also, drop the default switch case and explicitly list the enum values.
Otherwise it is error prone to forget a switch case.
(cherry picked from commit 9848589fbf)
Clang 10 doesn't like NM_IN_SET() with strings and is right about that:
../libnm-core/tests/test-general.c:7763:9: error: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Werror,-Wstring-compare]
(void) NM_IN_SET ("a", "1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11", "12", "13", "14", "15", "16");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
However, NM_IN_STRSET() should work.
(cherry picked from commit c437d6c60a)
Otherwise, we get test failures with valgrind on fedora:rawhide
(valgrind-3.15.0-18.fc33.x86_64.rpm, gcc-10.0.1-0.8.fc33.x86_64,
glib2-devel-2.63.5-3.fc33.x86_64):
>>>> PRINT VALGRIND LOGS (valgrind test) (start)
+ find -name '*.valgrind-log' -print0
+ xargs -0 grep -H '^'
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- WARNING: unhandled amd64-linux syscall: 315
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- You may be able to write your own handler.
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- Nevertheless we consider this a bug. Please report
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- it at http://valgrind.org/support/bug_reports.html.
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- WARNING: unhandled amd64-linux syscall: 315
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- You may be able to write your own handler.
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- Nevertheless we consider this a bug. Please report
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- it at http://valgrind.org/support/bug_reports.html.
./libnm/tests/test-secret-agent.valgrind-log:--95280-- WARNING: unhandled amd64-linux syscall: 315
./libnm/tests/test-secret-agent.valgrind-log:--95280-- You may be able to write your own handler.
./libnm/tests/test-secret-agent.valgrind-log:--95280-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./libnm/tests/test-secret-agent.valgrind-log:--95280-- Nevertheless we consider this a bug. Please report
./libnm/tests/test-secret-agent.valgrind-log:--95280-- it at http://valgrind.org/support/bug_reports.html.
./libnm/tests/test-nm-client.valgrind-log:--95208-- WARNING: unhandled amd64-linux syscall: 315
./libnm/tests/test-nm-client.valgrind-log:--95208-- You may be able to write your own handler.
./libnm/tests/test-nm-client.valgrind-log:--95208-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./libnm/tests/test-nm-client.valgrind-log:--95208-- Nevertheless we consider this a bug. Please report
./libnm/tests/test-nm-client.valgrind-log:--95208-- it at http://valgrind.org/support/bug_reports.html.
+ echo '>>>> PRINT VALGRIND LOGS (valgrind test) (done)'
>>>> PRINT VALGRIND LOGS (valgrind test) (done)
(cherry picked from commit 3e616c306d)
With `./configure --enable-more-asserts`, we add extra -W flags to
AM_CFLAGS. This variable is only used, if the per-library override
libnm_core_libnm_core_la_CFLAGS is unspecified ([1]).
Usually we avoid this problem be never specifying library_CFLAGS, but
placing all our per-library flags to library_CPPFLAGS. While that is a
bit of a hack and misuse of CPPFLAGS, it works well (enough).
This was broken recently. The effect was, that libnm-core was not
build with AM_CFLAGS flags. Fix it.
[1] https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html
Fixes: d2d6a68697 ('build: use -fcommon when building libnm-core')
(cherry picked from commit 16df1c179d)
When AddConnection() or Update() terminate, the (unrealized) virtual
device should be already be available, otherwise an activation attempt
of that connection can fail.
https://bugzilla.redhat.com/show_bug.cgi?id=1804350
This reverts commit c163207b07.
(cherry picked from commit efc04b1285)
We need to reset the OVS_PORT and OVS_PORT_UUID variables.
Otherwise, clearing the slave type doesn't work.
On master this is solved differently, by automatically clearing all
variables that are not explicitly set.
Reproducer:
nmcli con del t-eth1
nmcli con add type ethernet autoconnect no ifname eth1 master port0 con-name t-eth1 slave-type ovs-port
echo "
remove ovs-interface
remove connection.master
remove connection.slave-type
print
save
quit
" | nmcli c edit t-eth1
nmcli con show t-eth1 | grep 'ovs\|slave-type'
Fixes: 1440fe6a88 ('ifcfg: don't forget master of ovs interfaces')
https://bugzilla.redhat.com/show_bug.cgi?id=1804167
The interface name might come from the command line or from a filename
(like during nm_vpn_wireguard_import()). It's not clear that this
is valid UTF-8. Asserting against that requires the caller to ensure
that the encoding is valid. That is cumbersome, especially since we anyway
check. Just report a regular error.
(cherry picked from commit 82fb8b00b4)
quoting 'man ovs-vswitchd.conf.db':
"The name must be alphanumeric and must not contain forward or backward
slashes."
OVS actually accepts a wider range of chars (all printable UTF-8 chars),
NetworkManager restricts this to ASCII char as it's a safer option for
now since OVS is not well documented on this matter.
https://bugzilla.redhat.com/show_bug.cgi?id=1788432
Fixes: e7d72a14f6 ('libnm-core: use different ifname validation function for OVS bridges, ports and interfaces')
(cherry picked from commit ed5a647ad1)
When the ovs interface gets deactivated, it is released from the
master port and we call nm_device_update_from_platform_link (dev,
NULL) to ignore any later event for the interface. This is important
especially because it sets a zero ifindex on the interface and so,
later when the link disappears, we don't unmanage the device but
directly remove it.
However, since ovs commands are queued, the link could appear during
the deactivation and we need to ignore such events. Add a new device
method can_update_from_platform_link() for such purpose.
(cherry picked from commit e9fc1dea43)
Tracking the deletion of link by ifindex is difficult because the
ifindex of the device is updated through delayed (idle) calls in
NMDevice and so there is the possibility that at a certain time the
device ifindex is not in sync with platform state. It seems simpler to
watch instead the interface name. The ugly thing is that the interface
name can be changed externally, but if users do that on an activating
device they are looking for trouble.
Also change the deactivate code to deal with the scenario where we
already created the interface in the ovsdb but the link didn't show up
yet. To ensure a proper cleanup we must wait that the link appears and
then goes away; however the link may never appear if vswitchd sees
only the last state in ovsdb, and so we must use a ugly timeout to
avoid waiting forever.
https://bugzilla.redhat.com/show_bug.cgi?id=1787989
(cherry picked from commit 9c49f8a879)
The only affected caller is nm_modem_manager_get_modems(), which
is used by NMDeviceBt for DUN connections. This is rather bad.
Fixes: 4154d9618c ('bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data')
Fixes: e688e70b37 ('shared: add nm_utils_hash_values_to_array() helper')
(cherry picked from commit 037507f790)
OVS bridges and ports do not have the length limitation of 15 bytes, the
only requirements are that all chars must be alphanumeric and not be
forward or backward slashes.
For OVS interfaces only 'patch' types do not have the length limit, all
the other types do (according to whether they have a corresponding
kernel link or not).
Add related unit test.
https://bugzilla.redhat.com/show_bug.cgi?id=1788432
(cherry picked from commit e7d72a14f6)
'self' is guaranteed of being not-NULL since we have the
assertion 'g_return_val_if_fail (NM_IS_SETTING_OVS_INTERFACE (self),FALSE);'
at the beginning of the function.
(cherry picked from commit 15e87b80f3)
nm_utils_is_valid_iface_name() is a public API of libnm-core, let's use
our internal API.
$ sed -i 's/\<nm_utils_is_valid_iface_name\>/nm_utils_ifname_valid_kernel/g' $(git grep -l nm_utils_is_valid_iface_name)
(cherry picked from commit 6e9a36ab9f)
Move the body of nm_utils_is_valid_iface_name() to
nm_utils_ifname_valid_kernel() so that it's shared between NM and
clients.
(cherry picked from commit 550f538564)
nmcli should not perform checks on the interface name length,
this kind of operations should only be performed by the NetworkManager
daemon and not be duplicated inside cli applications.
(cherry picked from commit 15a8595575)
so that it gets compiled out in production builds, this check is
carried out anyway when the connection is created.
(cherry picked from commit 9e27252c27)
We will add a property NM_NDISC_RA_TIMEOUT for which this name is better
suited. The problem is really that our convention for object properties
and signals defines have no prefix to indicate whether it's a property
or a signal.
Rename.
(cherry picked from commit 10f0253f2e)
It is undefined behavior and can lead to crashes or memory corruption.
In practice, this only had an issue on Big Endian systems.
Fixes: fdbf4ae5e6 ('ifcfg-rh: add IPV4_DHCP_TIMEOUT key for ipv4.dhcp-timeout property')
(cherry picked from commit 9b82d29f5f)
If a function is only called once, it may not help to simplify the code
but make it more complicated. It would only simplify the code, if it
had a clear, distinct purpose. That isn't the case here. Also, the
IPv4 writer doesn't have such a function either. Drop and inline it.
(cherry picked from commit d06092acbd)
It feels wrong to schedule a timeout with G_MAXUINT32, if we actually
disabled the timeout. Of course, in practice there should be little
difference.
(cherry picked from commit 4c101f36ec)
This is C, we have almost no IDE support. And ctags/cscope is much more
helpful if we use unique names.
Don't use the get_dhcp_timeout() name, because that is already used in
"src/devices/nm-device.c" already. Rename.
(cherry picked from commit be4129bb2d)
