This doesn't make any difference in practice, but it seems more correct.
It would cause issues if we decided to remove an interface from the
signal handler.
(cherry picked from commit e948ce7deb)
When an interface (other OVS device types can not fail) encounters an error
it indicates it by changing the error column. Watch for those changes so
that we can eventually communicate them to the OVS factory to deal with
them.
(cherry picked from commit f2c066e104)
Don't crash in situations, where the bridge or a port has a child with
UUID we don't know. This could happen if we mess up the parsing of
messages from OVSDB, but could also theoretically happen in OVSDB sends
us bad data.
(cherry picked from commit 99c7adc1e1)
How odd that such a macro does not exist yet. It seems like
the majorities of calls to g_slice_free() could be replaced
by this.
(cherry picked from commit dcdbe98406)
nm_connection_get_setting() returns a pointer of type NMSetting.
That is very inconvenient, because most callers will need the
the result pointer as a setting subtype (like NMSettingConnection).
That would be like g_object_new() returning a "GObject *" pointer,
which is technically correct but annoying.
In the past that problem was avoided by having countless accessors
like nm_connection_get_setting_ip4_config(), etc. But that just blows
up the API and also is not generic. Meaning: the type is not a function
argument but the function itself. That makes composing the code harder
as the setting type cannot be treated generically (as a function argument).
Anyway. Add an internal wrapper that returns a void pointer.
(cherry picked from commit c4788e611e)
Fixes: 2a4fb75d3b ('ifcfg: add support for "802-1x.system-ca-certs" setting')
(cherry picked from commit b4537f2c03)
(cherry picked from commit 5d8a0837b3)
(cherry picked from commit e11232de96)
(cherry picked from commit e00e764167)
Fixes: a83ab252ee ('ifcfg-rh: add support for 802-1x.password-raw property')
(cherry picked from commit 9fde21504e)
(cherry picked from commit 36ddd266a5)
(cherry picked from commit 52bb253f6b)
(cherry picked from commit 3afbaeb597)
For ip-tunnel modes that encapsulate layer2 packets (gretap and
ip6gretap) we allow the presence of an ethernet setting in the
connection and honor the cloned-mac-address specified in it.
For all other modes, the ethernet setting is removed during
normalization, but a value different from 'preserve' could be set via
global default.
The kernel doesn't allow setting a MAC for layer3 devices, don't do
it.
(cherry picked from commit 0494a84878)
(cherry picked from commit 78ed14166c)
(cherry picked from commit d69d92c658)
(cherry picked from commit 60b4bdafcf)
Otherwise the function is not usable via generated bindings.
Fixes: 9b9dce9486 ('all: add 'match' setting')
(cherry picked from commit 180cda7632)
(cherry picked from commit 805adec9ca)
(cherry picked from commit b5a66b88b3)
(cherry picked from commit 2630758cb4)
Sometimes these function may set errno to unexpected values like EAGAIN.
This causes confusion. Avoid that by using our own wrappers that retry
in that case. For example, in rhbz#1797915 we have failures like:
errno = 0;
v = g_ascii_strtoll ("10", 0, &end);
if (errno != 0)
g_assert_not_reached ();
as g_ascii_strtoll() would return 10, but also set errno to EAGAIN.
Work around that by using wrapper functions that retry. This certainly
should be fixed in glib (or glibc), but the issues are severe enough to
warrant a workaround.
Note that our workarounds are very defensive. We only retry 2 times, if
we get an unexpected errno value. This is in the hope to recover from
a spurious EAGAIN. It won't recover from other errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1797915
(cherry picked from commit 7e49f4a199)
(cherry picked from commit eec2740d71)
(cherry picked from commit 500f0b96ae)
Avoid g_ascii_strtoull() calling directly. It has subtle issues, which is why
we have a wrapper for it.
(cherry picked from commit 659ac9cc12)
(cherry picked from commit 62469c1401)
(cherry picked from commit 386ea3ff26)
Commit b2a0738765 ('man: improve manual page for nm-online') removed
the explanation of how may-fail can be used to wait for a specific
address family during boot. I found that part useful.
Note: this branch doesn't have commit 1e5206414a ('device: don't
delay startup complete for pending-actions "autoconf", "dhcp4" and
"dhcp6"') and so the text is different from branch nm-1-22 and later.
https://bugzilla.redhat.com/show_bug.cgi?id=1825666
(cherry picked from commit 25583de20b)
(cherry picked from commit 02a31e71af)
(cherry picked from commit 74c4494b3b)
(cherry picked from commit 0417a5b4d1)
Fail the enslavement of the ovs port if the bridge device is not
found, instead of generating assertions and potentially crash later.
https://bugzilla.redhat.com/show_bug.cgi?id=1797696
Fixes: 101e65d2bb ('ovs: allow changing mac address of bridges and interfaces')
(cherry picked from commit c5c49995b1)
(cherry picked from commit 7494a2e37a)
(cherry picked from commit bb7f729eca)
The previous code tried to get the bridge active connection and it
used the port active connection instead in case of failure. This
doesn't seem right, as in nm-ovsdb.c the bridge AC is used to get the
bridge settings (including the uuid, interface name, and cloned mac).
In case of failure getting the bridge AC we should just fail.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
(cherry picked from commit c8b5a3f91a)
(cherry picked from commit d8fb95d22b)
(cherry picked from commit 323a557f74)
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)
(cherry picked from commit 96f50cf9d8)
(cherry picked from commit 9430c693fe)
Since commit c1907a218a ('libnm-core: remove gateway when
never-default=yes in NMSettingIPConfig'), the gateway gets normalized
away when the profile has never-default set.
That means,
$ nmcli connection modify "$PROFILE" ipv4.never-default yes ipv4.gateway 192.168.77.1
does not set the gateway. Likewise, if your profile has already never-default
enabled,
$ nmcli connection modify "$PROFILE" ipv4.gateway 192.168.77.1
will have no effect. That is confusing and undesirable.
Note that we don't adjust the GObject property setter for "gateway" to clear
never-default. I feel, setting one property in libnm should preferably
not unset another (there are exceptions to the rule, like for team
properties). However, for nmcli it's clear in which order properties
are set, so this change is right for the client tool.
https://bugzilla.redhat.com/show_bug.cgi?id=1785039https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/475
(cherry picked from commit 411255d51f)
(cherry picked from commit fae37528d9)
(cherry picked from commit d2606cc49e)
(cherry picked from commit 7ef4185714)
error: bare words are no longer supported, please use "...": no != yes
error: ^
error: /builds/NetworkManager/NetworkManager/contrib/fedora/rpm/NetworkManager.20200420-192728.bRtN05/SPECS/NetworkManager.spec:614: bad %if condition: no != yes
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)
(cherry picked from commit c8f372b3a6)
(cherry picked from commit cf5a18812a)
On newer versions, the test binaries where renamed so that meson and
autotools build the same executables. Hence, the workaround for
valgrind warnings works on newer versions, but not on this branch.
Instead of backporting the renaming of the build artefacts, adjust
the test runner to work with meson builds.
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)
(cherry picked from commit 6f189da7b6)
(cherry picked from commit 6da20c24cd)
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)
(cherry picked from commit a9372112b9)
(cherry picked from commit 4fb9f98bc6)
