NetworkManager merge requestshttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests2022-10-14T08:57:35Zhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1427dns: sort the ip-data list when a new element is added2022-10-14T08:57:35ZBeniamino Galvanidns: sort the ip-data list when a new element is addedIn `nm_dns_manager_set_ip_config()` we try to avoid calling `update_dns()`
unless something changes, because updating DNS is expensive and can
trigger other actions such as a new hostname resolution.
When we add a new ip_data, even if t...In `nm_dns_manager_set_ip_config()` we try to avoid calling `update_dns()`
unless something changes, because updating DNS is expensive and can
trigger other actions such as a new hostname resolution.
When we add a new ip_data, even if the new element is equivalent to
the old one that was removed, we need to sort the list again.
Fixes: ce0a36d20fa6 ('dns: better track l3cd changes')
https://bugzilla.redhat.com/show_bug.cgi?id=2098574https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1426[th/lldp] add libnm-lldp and replace systemd's sd_lldp_rx2022-10-25T09:01:52ZThomas Haller[th/lldp] add libnm-lldp and replace systemd's sd_lldp_rxWe currently use the systemd LLDP client, which we consume by forking
systemd code. That is a maintenance burden, because it's not a
self-contained, stable library that we use. Hence there is a need for an
individual library or properly ...We currently use the systemd LLDP client, which we consume by forking
systemd code. That is a maintenance burden, because it's not a
self-contained, stable library that we use. Hence there is a need for an
individual library or properly integrating the fork in our tree.
Optimally, we would create a new nettools project with an LLDP library.
That was not done because:
- nettools may want to be dual licensed with LGPL-2.1+ and Apache.
Systemd code is LGPL-2.1+ so it is fine for NetworkManager but
possibly not for nettools.
- nettools provides independent librares, as such they don't have an
event loop, instead they expose an epoll file descriptor and the user
needs to integrate it. Systemd and NetworkManager on the other hand
have their established event loop (sd_event and GMainContext,
respectively). It's simpler to implement the library on those terms,
in particular porting the systemd library from sd_event to
GMainContext.
- NetworkManager uses glib and has various helper utils. While it's
possible to do without them, it's more work.
The main reason to not write a new NetworkManager-agnostic library from
scratch, is that it's much simpler to fork the systemd library and make
it part of NetworkManager, than making it a nettools library.
---
The real question is of course what to do about our LLDP library.
1) should we continue to use our systemd fork and re-importing the code indefinitely? That is cumbersome.
2) should we continue to use our systemd fork and no longer import it? That seems to result in stale, unmaintained code, that does not integrate well with our NM code (*).
3) should we create/wait-for a proper external library (nettools). That is much effort, and nobody steps up to do the work.
4) create our own libnm-lldp libray.
(*) for example, our `LldpNeighbor` has a lot of overlap with `sd_lldp_neighbor`, and because we treat `sd_lldp_neighbor` as external, we cannot reconsile it. With our own `NMLldpNeighbor` type we are in full control and we could simplify `LldpNeighbor` (or even replace it entirely by `NMLldpNeighbor).
The branch does 4). This gives our own LLDP code and most flexibility. The downside is we stop benefiting from improvements from systemd.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1425po: update Hungarian (hu) translation2022-10-14T17:02:00ZBalázs Úrpo: update Hungarian (hu) translationHungarian translation for all messages except the ones for the docs in src/libnmc-setting/settings-docs.hHungarian translation for all messages except the ones for the docs in src/libnmc-setting/settings-docs.hhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1424nmcli: fix typo 'exiting' -> 'existing'2022-10-12T13:43:16Zgaoxingwanggxw94linux@163.comnmcli: fix typo 'exiting' -> 'existing'#1115
fix typo in nmcli error message#1115
fix typo in nmcli error messagehttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1423team: log port config when it's set2022-10-17T08:24:09ZLubomir Rintelteam: log port config when it's setLog the port config at trace level. Helps making debugging less
miserable.Log the port config at trace level. Helps making debugging less
miserable.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1422team: don't log failures to connect to teamd on error level2022-10-14T20:42:25ZLubomir Rintelteam: don't log failures to connect to teamd on error levelensure_teamd_connection() is called from multiple spots. Sometimes
we call opportunistically without having started teamd (e.g. when on
update_connection() when generating a connection for teaming device that
was created) and handle the ...ensure_teamd_connection() is called from multiple spots. Sometimes
we call opportunistically without having started teamd (e.g. when on
update_connection() when generating a connection for teaming device that
was created) and handle the failure to connect gracefully.
Let's not pollute the logs with things on ERROR level that are not
actually serious. Demote the logging statement to DEBUG and log an ERROR
only when we expect ensure_teamd_connection() to actually succeed.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1421team: set port configuration even if it's empty2022-11-28T07:52:19ZLubomir Rintelteam: set port configuration even if it's emptyCall 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) whe...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/1420[th/cli-fork-safety] avoid setenv() after fork2022-10-24T16:52:18ZThomas Haller[th/cli-fork-safety] avoid setenv() after forkafter fork (before exec) only functions from `man signal-safety` can be used. Avoid using `setenv()` to setup the pager.
`setenv()` actually cannot be used safely anywhere, because glib applications are frequently multithreaded (e.g. if...after fork (before exec) only functions from `man signal-safety` can be used. Avoid using `setenv()` to setup the pager.
`setenv()` actually cannot be used safely anywhere, because glib applications are frequently multithreaded (e.g. if they use GDBus, which can happen already before `main()` starts). In any case, it's *also* unsafe after fork.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1419man/nmcli: document variables affecting fancy output2022-10-11T14:35:28ZLubomir Rintelman/nmcli: document variables affecting fancy outputNotably, PAGER, TERM and NO_COLORS.Notably, PAGER, TERM and NO_COLORS.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1418Remove inheritance of unmanaged condition from the parent device, on all devices2022-10-19T14:29:58ZAna CabralRemove inheritance of unmanaged condition from the parent device, on all devicesIt is not possible to configure a VLAN interface on unmanaged NIC.
This forces users who only want to create a VLAN interface to take
ownership over possibly shared underlying NIC.
In OpenShift, the SR-IOV operator is currently not usin...It is not possible to configure a VLAN interface on unmanaged NIC.
This forces users who only want to create a VLAN interface to take
ownership over possibly shared underlying NIC.
In OpenShift, the SR-IOV operator is currently not using
NetworkManager to configure VFs. When it starts working with a NIC,
it explicitly makes it unmanaged. Then, users cannot create a VLAN
interface on PFs managed by the operator.
One of the commits here eliminates this issue by allowing configuring
VLAN on an interface without requesting it to be managed by NetworkManager.
The behavior of inheriting unmanaged condition from the parent was
removed from all devices with this Merge Request.
https://bugzilla.redhat.com/show_bug.cgi?id=2110307https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1417[th/uuid-generate-strv-null] fix nm_uuid_generate_from_strings() to support N...2022-10-11T07:06:55ZThomas Haller[th/uuid-generate-strv-null] fix nm_uuid_generate_from_strings() to support NULL stringsWhen you call
```
nm_uuid_generate_from_strings_strv(uuid_type, type_arg, v1, v2);
```
you'd probably expect that both values are honored in some way.
However, if `v1` happened to be NULL, then `v2` would have been ignored.
Extend `nm...When you call
```
nm_uuid_generate_from_strings_strv(uuid_type, type_arg, v1, v2);
```
you'd probably expect that both values are honored in some way.
However, if `v1` happened to be NULL, then `v2` would have been ignored.
Extend `nm_uuid_generate_from_strings()` to accept also NULL values and
pass on the length.
Also extend `nm_uuid_generate_from_strings_strv()` to take a length
argument. It still accepts "-1" to take the input strv as a NULL
terminated array.
The existing users of the previous behavior got renamed to
`nm_uuid_generate_from_strings_old()`.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1416[th/gslice] replace GSlice (by NMSlice?)2022-10-17T20:11:54ZThomas Haller[th/gslice] replace GSlice (by NMSlice?)glib has for a long time the GSlice API. The *only* reason to have and
use it, is the hope that it might perform better. After all, it's API
is more limited, as it doesn't support realloc() and requires the caller
to provide the memory s...glib has for a long time the GSlice API. The *only* reason to have and
use it, is the hope that it might perform better. After all, it's API
is more limited, as it doesn't support realloc() and requires the caller
to provide the memory size during free.
It's hard to accurately benchmark whether an allocator clearly performs better,
as it depends on usage and the system allocator that we compare against.
But there are some doubts whether it's faster ([1]), and it might be even
slower which totally defeats the purpose of having this.
Also, there is an long open bug to deprecate the GSlice API ([2]).
Move forward an redirect GSlice to the system allocator.
Don't completely the call patter however. For one, that would require
manual changes (or a good script). But more importantly, we already use
the GSlice API, and at the places where we do, we acknowledge to use a
more limited behavior (no realloc()) and we know the deallocation size.
Replacing all GSlice uses right away with malloc()/free() uses that
information and there is no easy way back. But the more limited API
*might* have performance benefits in the future. For example, C++
has sized allocation for this reason ([3]).
So don't drop a slice API entirely. Instead, add our own nm_slice*()
for now, which redirects to g_malloc()/g_free().
[1] https://wiki.gnome.org/Projects/GLib/GSlicePeformanceTests
[2] https://gitlab.gnome.org/GNOME/glib/-/issues/ ## 1079
[3] https://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3778.html
---
The alternative is to drop GSlice and use malloc/free directly.
We can do a (mostly) automated conversion from GSlice to malloc/free, but not the other way around. That is, the current places that use GSlice have a more special use-case, and converting to malloc/free entirely seems to loose that information.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1415core: don't restrict DNS interface when performing connectivity check2022-10-20T16:17:07ZMichael Catanzarocore: don't restrict DNS interface when performing connectivity checkCurrently, 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 n...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.
Fixes #1107https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1414[th/nmclient-wait-shutdown] libnm: add nm_client_wait_shutdown() function for...2022-10-14T15:53:56ZThomas Haller[th/nmclient-wait-shutdown] libnm: add nm_client_wait_shutdown() function for cleaning up NMClientIt's not entirely trivial to let the user handle this. Also, because
glib provides no convenient API to integrate a GMainContext in another
GMainContext (like `nm_utils_g_main_context_create_integrate_source()`).
Add a fire-and-forget f...It's not entirely trivial to let the user handle this. Also, because
glib provides no convenient API to integrate a GMainContext in another
GMainContext (like `nm_utils_g_main_context_create_integrate_source()`).
Add a fire-and-forget function to make that simpler.
The following test script will run out of file descriptors,
when wait_shutdown() is not used:
```
#!/bin/python
import gi
gi.require_version("NM", "1.0")
from gi.repository import NM, GLib
for i in range(1200):
print(f">>>{i}")
ctx = GLib.MainContext()
ctx.push_thread_default()
nmc = NM.Client.new()
ctx.pop_thread_default()
def cb(unused, result, i):
try:
NM.Client.wait_shutdown_finish(result)
except Exception:
# cannot happen
assert False
else:
print(f">>>>> {i} complete")
nmc.wait_shutdown(True, None, cb, i)
while GLib.MainContext.default().iteration(False):
pass
```https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1413platform: set custom netlink buffer size when adding SR-IOV VFs2022-10-17T08:34:27ZBeniamino Galvaniplatform: set custom netlink buffer size when adding SR-IOV VFsWhen 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.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.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1412Update Ukrainian translation2022-10-05T07:25:09ZYuri ChornoivanUpdate Ukrainian translationTested for validity. Many thanks in advance for merging.Tested for validity. Many thanks in advance for merging.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1411[th/systemd] systemd: update code from upstream (2022-10-04)2022-10-05T07:23:22ZThomas Haller[th/systemd] systemd: update code from upstream (2022-10-04)reimportreimporthttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1410[th/generate-docs] rework "generate-docs-nm-property-infos.py" and do stricte...2022-10-06T11:42:53ZThomas Haller[th/generate-docs] rework "generate-docs-nm-property-infos.py" and do stricter parsingrework "generate-docs-nm-property-infos.py".
- whitespace and newlines are not preserved better.
- the parsing got stricter, and would fail for unexpected input. When there is a failure, we would log the offending file:line.
- various c...rework "generate-docs-nm-property-infos.py".
- whitespace and newlines are not preserved better.
- the parsing got stricter, and would fail for unexpected input. When there is a failure, we would log the offending file:line.
- various cleanups.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1409nmcli: fix return code on "nmcli device connect" error2022-10-04T08:50:35ZBeniamino Galvaninmcli: fix return code on "nmcli device connect" errorBefore:
```
$ nmcli device connect veth0; echo $?
Error: Connection activation failed: (5) IP configuration could not be reserved (no available address, timeout, etc.).
0
```
```
After
$ nmcli device connect veth0; echo $?
Err...Before:
```
$ nmcli device connect veth0; echo $?
Error: Connection activation failed: (5) IP configuration could not be reserved (no available address, timeout, etc.).
0
```
```
After
$ nmcli device connect veth0; echo $?
Error: Connection activation failed: IP configuration could not be reserved (no available address, timeout, etc.).
4
```
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/902https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1408bond,bridge,team: use uuid for con.master when generating connection2022-10-06T13:33:38ZLubomir Rintelbond,bridge,team: use uuid for con.master when generating connectionAttempt at fixing @libnm_snapshot_reattach_unmanaged_ports_to_bridge,
https://bugzilla.redhat.com/show_bug.cgi?id=2125615
Let's see how tests go first.Attempt at fixing @libnm_snapshot_reattach_unmanaged_ports_to_bridge,
https://bugzilla.redhat.com/show_bug.cgi?id=2125615
Let's see how tests go first.