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)
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)
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)
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)
Many device types take the MTU value from the wired setting; usually
they don't implement the can_reapply_change() method and so the MTU
can't be changed with the Reapply() API.
Instead of implementing the method for all such devices to support the
same property (adding a lot of duplicated code), add a check in
NMDevice to allow the reapply of MTU when we recognize that the device
uses the MTU from the wired setting.
Device types can still decide to implement can_reapply_change() and
support whatever properties they want, even from the wired setting.
(cherry picked from commit 9339d3310e)
(cherry picked from commit 1191eba15a)
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)
In practice, nowadays g_free() is the same as free(), so there is no
difference. However, we still should not mix the two and use free()
for data that was allocated with malloc() -- in this case, the memory
was allocated by libc's realpath().
(cherry picked from commit 3ade6dacfc)
While at it, use NM_STR_HAS_SUFFIX() with the string literal.
Fixes: 35a428f168 ('dispatcher: look for the scripts in /usr/lib as well')
(cherry picked from commit 1c2889faee)
For the moment, we use docker images from dockerhub, which require
a lot of extra overhead to prepare and install the test environment.
This should be improved, by using more suitable container images.
Anyway, for now to alleviate the pressure on the freedesktop gitlab
infrastructure, disable most test to only run manually.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/241#note_282521
(cherry picked from commit b733d477e8)
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)
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)
libnm has a dependency on 'libnmdbus_dep', which contains 'link_with:
libnmdbus'. This however only enforces that libnm is linked after the
libnmdbus static library is built; it doesn't give any guarantees
about the compilation phase.
We need to make libnm compilation depend on the generated header
files. The output of 'gnome.gdbus_codegen' is an array with the header
file in the second position; use it to add a proper
dependency. Unfortunately this works only with meson >= 0.46.
In the future libnm will no longer use gdbus generated code and this
dependency will not be needed anymore.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/286
(cherry picked from commit a59a8aa033)
This essentially aligns the implementation with the documentation.
It is also rather useful, since it allows us to use the value returned
by nm_setting_wired_get_mac_address() directly, and that one can indeed
be NULL.
(cherry picked from commit 62919bab43)
No change in behavior. Will be useful when we'll want to unconditionally
add new connection without the matching behavior.
(cherry picked from commit e1a068e93c)
It is really not clear what the user could have meant by specifying a
bootdev= argument, and we deal with it just by ensuring a device with
that name whould come up.
We therefore pick a default connection if there's one (that is a
conneciton that we create if the device name is unspecified, as in
"ip=auto"), otherwise we create a new one.
(cherry picked from commit 30f8154319)
This is so that we end up with a next-server option analogous to what
dhclient helper sends us. Dracut uses this for networked boots.
(cherry picked from commit c1104a5cc2)
