error: bare words are no longer supported, please use "...": no != "yes"
error: ^
error: /builds/NetworkManager/NetworkManager/contrib/fedora/rpm/NetworkManager.20200418-170120.dp5cp5/SPECS/NetworkManager.spec:596: bad %if condition: no != "yes"
(cherry picked from commit ed94ab6e23)
(cherry picked from commit 1667be7cf5)
(cherry picked from commit 719d492f4a)
(cherry picked from commit 71d4e261f6)
error: bare words are no longer supported, please use "...": no != yes
error: /builds/NetworkManager/NetworkManager/contrib/fedora/rpm/NetworkManager.20200418-163008.VM582H/SPECS/NetworkManager.spec:596: bad %if condition: no != yes
(cherry picked from commit be78a12012)
(cherry picked from commit c869d792a2)
(cherry picked from commit 5735e267cd)
(cherry picked from commit 3fcc337770)
warning: extra tokens at the end of %endif directive in line 717: %endif # end autotools
warning: extra tokens at the end of %endif directive in line 775: %endif # end autotools
(cherry picked from commit 0521e06ff1)
(cherry picked from commit 43aa1f7ff1)
Why "if (length > G_MAXUINT)"? This is never going to hit. Also,
we probably should actual missing keys handle differently from
empty lists. If @error is set, return without setting the property.
(cherry picked from commit 2cf31bfef0)
(cherry picked from commit f00d306ae7)
(cherry picked from commit cd33ea1fc0)
(cherry picked from commit e1acac6311)
g_key_file_get_integer_list() can return %NULL without setting an error.
That is the case if the key is set to an empty value.
For X sake, this API. Read the documentation and figure out whether
the function can return %NULL without reporting an error.
Anyway, avoid the assertion failure.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/412
(cherry picked from commit 8f46425b11)
(cherry picked from commit 97139f5e3d)
(cherry picked from commit 59d488cb46)
(cherry picked from commit b82a8e4e01)
If a device is being autoactivated and requires a parent that is
blocked due to user request, the autoactivation attempt should fail
because NM shouldn't overrule the user decision.
https://bugzilla.redhat.com/show_bug.cgi?id=1765566
(cherry picked from commit f2dbf8fbc0)
(cherry picked from commit 61d431a9e8)
(cherry picked from commit 74649429df)
g_ascii_strtoull() returns a guint64, which is very wrong to directly pass
to the variadic argument list of g_object_set(). We expect a guint there
and need to cast.
While at it, use _nm_utils_ascii_str_to_int64() to parse and validate the input.
(cherry picked from commit d506823d4f)
(cherry picked from commit 24177569c1)
(cherry picked from commit 0a10468d79)
error: bare words are no longer supported, please use "...": "x" != x
error: ^
error: /root/nm-build/NetworkManager/contrib/fedora/rpm/NetworkManager.20200402-030113.Hk7EGs/SPECS/NetworkManager.spec:32: bad %if condition: "x" != x
ERROR: rpmbuild FAILED
(cherry picked from commit 68b38a09d1)
(cherry picked from commit 045194760e)
(cherry picked from commit 477c6c3e70)
We try to set only one time the MTU from the connection to not
interfere with manual user changes.
If at some point the parent interface changes temporarily MTU to a
lower value (for example, because the connection was reactivated), the
kernel will also lower the MTU on child interface and we will not
update it ever again.
Add a workaround to this. If we detect that the MTU we want to set
from connection is higher that the allowed one, go into a state where
we follow the parent MTU until it is possible to set again the desired
MTU. This is a bit ugly, but I can't think of any nicer way to do it.
https://bugzilla.redhat.com/show_bug.cgi?id=1751079
(cherry picked from commit ec28f5b343)
(cherry picked from commit 49857ed279)
A MACsec connection doesn't have an ordering dependency with its
parent connection and so it's possible that the parent gets activated
later and sets a greater MTU than the original one.
It is reasonable and useful to keep the MACsec MTU configured by
default as the maximum allowed by the parent interface, that is the
parent MTU minus the encapsulation overhead (32). The user can of
course override this by setting an explicit value in the
connection. We already do something similar for VLANs.
https://bugzilla.redhat.com/show_bug.cgi?id=1723690
(cherry picked from commit 438a0a9ad5)
(cherry picked from commit c58ce8945d)
Introduce a generic function to set a MTU based on parent's one. Also
define a device-specific @mtu_parent_delta value that specifies the
difference from parent MTU that should be set by default. For VLAN it
is zero but other interface types (for example MACsec) require a
positive value due to encapsulation overhead.
(cherry picked from commit 5cf57f4522)
(cherry picked from commit 73597864bb)
svUnsetValue (ifcfg, KEY);
if (condition)
svSetValue* (ifcfg, KEY, ...);
is not good. It requires first clearing the value, before setting
it again.
Various cleanup to fix such uses.
(cherry picked from commit 5028206ec4)
(cherry picked from commit b67983c387)
The signal is unused (and should be removed).
Still, the parameter passed to g_signal_emit() is a C string, not a
GVariant. I think as there are no subscribers, glib wouldn't actually
do anything with the arguments. Though, I am not sure whether glib still
tries to initialize a GValue with a GVariant type, leading to a crash.
Fixes: f05b7a78c9 ('supplicant: Track P2P Group information, creation and destruction')
(cherry picked from commit c106008091)
(cherry picked from commit 26d6ac5385)
(cherry picked from commit dc9322c0a9)
Oddly enough, valgrind was not complaining about this leak...
Fixes: 87b2d783b6 ('core: accept 'ssids':aay option in RequestScan() dictionary parameter')
(cherry picked from commit 5ed1edc02a)
(cherry picked from commit 568c19f07d)
(cherry picked from commit fff235e3a5)
The autoconnection for virtual devices currently works in two
phases. First we detect that there is suitable profile that can
autoconnect and we realize the device. Then, when the device becomes
'disconnected', autoconnect kicks in and starts the activation.
However, if autoconnect is blocked for a device, currently we do step
1 without step 2, leaving a stale interface around. Fix this by also
checking that autoconnect is not blocked during step 1.
https://bugzilla.redhat.com/show_bug.cgi?id=1765047https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/360
(cherry picked from commit 6c716912eb)
(cherry picked from commit 944ff9f9dc)
(cherry picked from commit cbb1ad1ba7)
Otherwise, this function cannot really be used via generated bindings.
Also, it's the only way to actually retrieve the set vlan-ids, without
it, you wouldn't know which ones are set.
Fixes: a9b4532fa7 ('libnm-core: add SR-IOV setting')
(cherry picked from commit c4a728217d)
(cherry picked from commit 49376697c6)
(cherry picked from commit 2f62e30b7c)
If the activation of an assumed device fails, we first set the device
state to FAILED and then to ACTIVATED. In the FAILED state, the active
connection transitions to DEACTIVATED and clears its device pointer;
hence we end up with an inconsistent state which causes assertion
failures in other parts of the code (for example, get_best_ip_config()
assumes that the device of the best active connection is not NULL).
Don't first transition to FAILED and then to ACTIVATED, just set the
latter.
https://bugzilla.redhat.com/show_bug.cgi?id=1737774https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/351
(cherry picked from commit 93e9010b75)
(cherry picked from commit 366b90db87)
(cherry picked from commit 8274cc1353)
After we set link parameters (auto-negotiation, speed, duplex) in
stage1, the carrier can go down for several seconds because the
Ethernet PHY needs to renegotiate the link. Wait that carrier goes up
before starting the supplicant or the EAPoL start packet can be lost
causing an authentication failure.
https://bugzilla.redhat.com/show_bug.cgi?id=1759797
(cherry picked from commit 838e5b87c2)
(cherry picked from commit 8e2ad6f0c3)
In nm_acd_manager_announce_addresses() we should not only start the
probes but also add the acd file descriptor to the main loop.
Otherwise, a timer is armed to send the announcements but it never
fires and no announcements are sent.
Fixes: d9a4b59c18 ('acd: adapt NM code and build options')
https://bugzilla.redhat.com/show_bug.cgi?id=1767681
(cherry picked from commit 14992ab9cd)
(cherry picked from commit c36da8b990)
Since commit 159ff23268 ('dhcp/dhclient-utils: skip over
dhclient.conf blocks') we skip blocks enclosed in lines containing '{'
and '}' because NM should ignore 'lease', 'alias' and other
declarations. However, conditional statements seem useful and should
not be skipped.
https://bugzilla.redhat.com/show_bug.cgi?id=1758550
(cherry picked from commit b58e4d311d)
(cherry picked from commit 58ffded2d0)
Backport various kinds of build and test fixes. Now our gitlab-ci setup
on nm-1-18 is very similar to what we also do on nm-1-20 branch and
runs the same kind of tests.
This test keeps randomly failing. Rework is, so that we see the actual
exit status in the output of the failed test.
(cherry picked from commit 49c6fa2ba7)
These are deprecated. Also, they are nowadays implemented as macros
that expand to
#define g_main_run(loop) g_main_loop_run(loop) GLIB_DEPRECATED_MACRO_IN_2_26_FOR(g_main_loop_run)
This can cause compilation failure (in some environments).
(cherry picked from commit de6f0bc6db)
(cherry picked from commit 9e209138dc)
Building the sources requires libnm newer than glib 2.32, but
g_thread_supported() and g_thread_init() are deprecated since
2.32.
This causes a build failure due to the deprecated warning.
When opening a merge request from a fork of NetworkManager, then the
pipeline runs with the a checkout of the fork. That means, checkpatch
would compare the branch against "master" (or "nm-x-y" stable branches)
of the fork, instead of upstream.
That doesn't seem too useful. Instead, also add upstream NetworkManager
as git remote, fetch the branches, and use the branches from there as
base for checkpatch.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/255
(cherry picked from commit 3019648b4b)
(cherry picked from commit 9a37702311)
"ubuntu:devel" ships iproute2 version "5.2.0-1ubuntu1". This has a well known
bug that prevents it from creating IP tunnels during the unit tests.
We already workaround that on Debian. Add the same workaround to match the
Ubuntu package.
(cherry picked from commit 44193d3def)
(cherry picked from commit 27c23b0748)
