Call teamdctl_port_config_update_raw() when we're attaching a port even
if all of team-slave setting properties are default.
This is done to ensure teamd "knows" about the port (that is,
"teamdctl ... port present" returns success) when we're done activating
the slave connection. It will pick it up anyway from netlink, but that
can happen after the activation is done, resulting in a possible race.
Fixes-test: @remove_active_team_profile
https://bugzilla.redhat.com/show_bug.cgi?id=2102375https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1421
(cherry picked from commit 6897f6e6df)
If teamd crashes, we restore it. That's very nice, but if it really
crashed then it left ports attached and the slave connections are not
going to fail and the port configuration (e.g. priority or link watcher) in
teamd's memory will be gone.
This will restore the port configuration when the teamd connection is
re-established. This probably also fixes a race where a slave connection
would be enslaved (only possible externally and manually?) while we
didn't establish a connection to teamd yet. We'll just send the port
configuration in once're connected.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1361
(cherry picked from commit f3327835c1)
We must consume the reference, like we would in the other case.
Interestingly, I am unable to reproduce a case where valgrind would
complain about the leak. But it is there nonetheless.
Fixes: 0a22f4e490 ('libnm: refactor tracking of NMSetting in NMConnection')
(cherry picked from commit 3e3b629586)
When creating NMPlatformRoutingRule from NMIPRouteRule object, the
protocol is being set to RTPROT_UNSPEC. According to linux kernel
documentation FRA_PROTOCOL indicates the originator of the rule.
In this case the route rule is coming from a connection and therefore
the originator of the rule is the user. The correct value is
RTPROT_STATIC which means the rule is installed by the administrator.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1457
Fixes: 3f9347745b ('core: add handling of IP routing rules to NMDevice')
(cherry picked from commit 82009e21d2)
This verifies that what's in our public headers has version nodes, and
that they match Since: tags.
Not pretty (because python) but discovered a *lot* of issues.
(cherry picked from commit 133540763c)
Turns out automake doesn't like either that we add dependencies to a
target conditionally. Not sure why, but it's a tasteless thing to do
nevertheless:
gtk-doc.make:174: warning: $(DOC_MAIN_SGML_FILE) was already defined in condition BUILD_DOCS, which is included in condition TRUE ...
docs/api/Makefile.am:112: 'gtk-doc.make' included from here
docs/api/Makefile.am:14: ... '$(DOC_MAIN_SGML_FILE)' previously defined here
In any case, the dependency is wrong in the first place -- the source
document doesn't depend on other source. The target (which is a stamp
file, since the xslt processor produces multiple files) does! Moreover,
there's a dependency of the stamp file on $(content_files) already, so
including GENERATED_FILES (like we already do) in content_files should
be sufficient.
While at that, deal with other not-so-nice things; don't extend "all"
target needlessly and don't define a target conditionally.
(cherry picked from commit 4c49d67cc8)
Add them to @libnm_1_40_4 as opposed to @libnm_1_42_0 because we now know
this is going to be backported to 1.40.4 first.
(cherry picked from commit 45d9f1c01c)
Compared to version in main branch, the Since tags and
NM_AVAILABLE_IN_* macros indicate the branched version.
These are present in a public header yet are not properly commented,
versioned or exported.
Export them now. Another option would be to move them to a private
header; but I suspect someone has intended them to be exported at some
point.
Add them to @libnm_1_40_4 as opposed to @libnm_1_42_0 because we now know
this is going to be backported to 1.40.4 first.
(cherry picked from commit d78000d921)
Compared to version in main branch, the Since tags and
NM_AVAILABLE_IN_* macros indicate the branched version.
Some comments are malformed, some are missing altogether.
(cherry picked from commit 117a440cd9)
Compared to version in main branch, the Since tags document the
branched version as well.
The backport omits changes to nm_client_wait_shutdown(), since that one
is not yet present in 1.40.
Remove the functions from a public header. They were missing from
libnm.ver and thus never actually exported.
There's no point in salvaging them now as the whole NMVpnPluginOld has
been replaced NMVpnServicePlugin and new uses are discouraged.
(cherry picked from commit 1c6b0edb30)
Remove the function from a public header. It was missing from libnm.ver
and thus never actually exported.
There's no point in salvaging it now as it nm_device_get_hw_address()
exists as a better option.
(cherry picked from commit ecb9a48040)
Remove the function from a public header. It was missing from libnm.ver
and thus never actually exported.
There's no point in salvaging it now as it nm_device_get_hw_address()
exists as a better option.
(cherry picked from commit bd3239cf6c)
The export was left out when the symbol was added; apparently by
accident.
Let's also bump the documented version of when is the symbol supposed to
be available, because it actually wasn't.
Fixes: 56a1a5426a ('all: add ipvX.dhcp-iaid properties')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1447
(cherry picked from commit 941e8b70f8)
Compared to version in main branch, the Since tags and
NM_AVAILABLE_IN_* macros indicate the branched version.
Backport also includes commit c7f6a506ef ('libnm: move
nm_setting_ip_config_get_dhcp_iaid() to @libnm_1_40_4 version node'),
it wouldn't be possible to backport both separately.
- the static assertions were wrong, there was a "," instead of "==".
- the numeric values were wrong, as shown by the static assertions.
- move the code comment to the implementation. This does not seem
relevant for the library user and should not be in the public header.
Fixes: 08e845f651 ('nm-setting: mangle public constant to make g-ir-scanner happy')
(cherry picked from commit c884d4d347)
NMSettingWired does not reject invalid flags. Filter them out in wake_on_lan_enable().
In practice, it makes no difference, the unknown flags were ignored anyway.
(cherry picked from commit c593834842)
If there were any pause options and any non-pause options,
the created setting was invalid.
I don't think it's reasonably possible to parse the broken settings.
So there is no workaround trying to read the existing broken settings
from disk. Luckily, the broken setting was just silently ignored by
the parser, so you simply could not persist certain settings.
https://bugzilla.redhat.com/show_bug.cgi?id=2134569
Fixes: 652ddca04c ('ethtool: Introducing PAUSE support')
(cherry picked from commit 21661c6f71)
[thaller@redhat.com: modified original patch.]
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
(cherry picked from commit 61e99ed715)
The if-else-if was wrong. It meant that if an object did not implement
cmd_plobj_id_copy(), nothign was copied (for id-only).
I think this code path was not actually hit, because we never clone
an object only by ID.
Fixes: c91a4617a1 ('nmp-object: allow missing implementations for certain virtual functions')
(cherry picked from commit ee34eeafb9)
Fix up the doc comment so that the gir data gets that right.
Fixes: 90d0ae0faf ('libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly')
(cherry picked from commit a0373a72db)
On rhel-8.7, we use a different gettext version, so the Makefile
looks different. Adjust patch the source.
Fixes: 7ee0da3eaf ('build: don't "update-po" during make dist')
(cherry picked from commit b2d1d14772)
Currently, when performing DNS resolution with systemd-resolved,
NetworkManager tells systemd-resolved to consider only DNS configuration
for the network interface that the connectivity check request will be
routed through. But this is not correct because DNS and routing are
configured entirely separately. For example, say we have a VPN that
receives all DNS but only a subset of routing. NetworkManager will
configure systemd-resolved with no DNS servers on any interface except
for the VPN interface, but will still route traffic through other
interfaces. This is entirely legitimate and works fine in practice,
except for the connectivity check.
To fix this, we just drop the restriction and allow systemd-resolved to
consider its full configuration, which is what gets used normally
anyway. This allows our connectivity check to match the real
configuration instead of failing spuriously.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1107https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1415
(cherry picked from commit e6dac4f0b6)
Fix the following crash:
$ nmcli device monitor a
Error: Device 'a' not found.
Segmentation fault (core dumped)
Found by coverity:
1. NetworkManager-1.41.3/src/nmcli/devices.c:0: scope_hint: In function 'do_devices_monitor'
2. NetworkManager-1.41.3/src/nmcli/devices.c:2932:28: warning[-Wanalyzer-null-dereference]: dereference of NULL 'devices'
2930| }
2931|
2932|-> for (i = 0; i < devices->len; i++)
2933| device_watch(nmc, g_ptr_array_index(devices, i));
2934|
Fixes: 2074b28976 ('nmcli/devices: return GPtrArray instead of GSList from get_device_list()')
(cherry picked from commit 40897db056)
For connections with multi-connect property set to "multiple", the
autoconnect-retries should be tracked per device and not per connection.
That means, if autoconnect-retries is set to 2, each device using that
connection should retry to autoconnect 2 times.
The device autoconnect retries is -2 by default. This is a special
value, in NMPolicy context, if the connection used is multi-connect the
device value will be set to match the connection retries. Each time the
device picks a different connection, it will reset the device
autoconnect retries to -2 and if needed, sync. with the connection
retries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1387https://bugzilla.redhat.com/show_bug.cgi?id=2039734
(cherry picked from commit 1656d82045)
... and profiles from firmware with autoconnect-priority -200.
In general, after switch root we remember the still activated profile in
/run, and NetworkManager would take over the device with the same
profile as before. In that case, autoconnect and autoconnect-priority
doesn't matter.
Autoconnect only matters when having a device in disconnected state and
not being blocked from autoconnect. For example, if you unplug and
replug the cable. In that case, it does make sense to me that
user-provided profiles from real-root are preferred.
To me the reasons for this change is not very strong (but neither are
the reasons against it). Read the discussion on rhbz #2089707.
https://bugzilla.redhat.com/show_bug.cgi?id=2089707
Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1376
(cherry picked from commit 98575bd513)
When there are many VFs the default buffer size of 1 memory page is
not enough. Each VF can take up to ~120 bytes and so when the page
size is 4KiB at most ~34 VFs can be added.
Specify the buffer size when allocating the message.
(cherry picked from commit f7ac887502)
