In public libnm headers we include some libc/linux headers, although
libnm doesn't strictly need them.
The <linux/*.h> headers conflict with some network headers provided by
libc and they need to be included in the right order. As
<NetworkManager.h> drags in some linux headers, this makes it
unnecessarily complicated.
It also feels ugly to include headers we don't need, only for the
sake of convenience. Allow to opt out.
Also, for internal build, don't do this. When building NetworkManager
we need control about the headers and their order of inclusion.
"in_addr_t" and "struct in6_addr" require headers from libc (or linux).
In particular, some libc headers conflict with the linux headers
(or they have to be included in a specific order). To avoid that
we want that our libnm headers include a minimum of other headers
(and only drag in glib headers, which we anyway need).
- instead of "in_addr_t", use guint32. For all practical purposes,
"in_addr_t" is a plain 32 bit integers and we can do this replacement
in our public headers.
- forward declare "struct in6_addr".
Currently libnm headers include <linux/if_{ether,infiniband,vlan}.h>.
These are public headers, that means we drag in the linux header to all
users of <NetworkManager.h>.
Often the linux headers work badly together with certain headers from libc.
Depending on the libc version, you have to order linux headers in the right
order with respect to libc headers.
We should do better about libnm headers. As a first step, assume that
the linux headers don't get included by libnm, and explicitly include
them where they are needed.
These typedefs are defined by some libc headers, and we drag
them in by including some other standard headers.
It's not clear which headers we exactly need for them, and that
all libcs provide them the same.
Instead, just avoid them.
In C, includes with <> are for system headers, while "" prefers the
current working directory (implementation defined).
For libnm headers that include other libnm headers, we tend to use
"" instead of <>. That makes sense to me. Be consistent about that.
When activating a connection using nmtui, veth connections where not
being listed. This patches fixes this and they are now being listed.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
If the DNS configuration changes, the hostname previously determined
via reverse DNS lookup could be stale. Clear the resolver data of every
interface and try again.
Fixes: 09c8387114 ('policy: use the hostname setting')
Veth interfaces should be shown as Ethernet from
nm_device_get_type_description in order to provide backward
compatibility.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
As NMDeviceVeth has a NMDeviceEthernet as parent, it should use PRIO_20
in order to report NMDeviceVeth when configured and do not report
NMDeviceEthernet.
An unit test case has been added.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
On alpine/musl we get a compiler warning:
CC shared/systemd/src/basic/libnm_systemd_shared_la-env-file.lo
In file included from ../shared/systemd/src/basic/fileio.h:9,
from ../shared/systemd/src/basic/env-file.c:10:
/usr/include/sys/fcntl.h:1:2: error: #warning redirecting incorrect #include <sys/fcntl.h> to <fcntl.h> [-Werror=cpp]
1 | #warning redirecting incorrect #include <sys/fcntl.h> to <fcntl.h>
| ^~~~~~~
Including <netinet/ether.h> with musl leads to a conflict with <linux/if_ether.h>,
due to redefining ethhdr struct. As we include <linux/if_ether.h> in "nm-utils.h",
that is a problem.
Avoid that, by including other headers.
<netinet/ether.h> with musl defines ethhdr struct, which conflicts
with <linux/if_ether.h>. The latter is included by "nm-utils.h",
so this is a problem.
Drop includes of "netinet/ether.h" that are not necessary.
Alpine is especially interesting because it uses musl as libc.
The build does not yet succeed. There are several issues that
need to be fixed.
However, it will be simpler to fix things, if we have tests
in place -- even if at the moment they are known to be broken.
See-also: https://git.alpinelinux.org/aports/tree/community/networkmanager?h=master
If we call g_cancellable_connect() on a GCancellable that is already
cancelled, then the callback is invoked synchronously. We need to
handle that.
However, we can slightly simplify the code. There is no change in
behavior, but we can always let the cancelled callback return the
result.
"iface_data->cancellable" is an internal cancellable for the parallel
HTTP requests. Once we encounter a failure, those requests are all
obsolete and must be cancelled.
There are two GCancellable at work: one is provided by the user
during nmcs_provider_get_config(), and one is used internally for the
individual HTTP GET requests.
In _get_config_fetch_done_cb(), if the error reason is "cancelled",
then it means that our internal iface_data->cancellable was cancelled.
Probably because an error happend (like a timeout or the user cancelled
the external GCancellable).
In that case, we must not report that the task completed with a
cancellation, because we need to preserve the error that was the
original cause.
The previous implementation would print
./tools/check-gitlab-ci.sh: line 22: ci-fairy: command not found
also, it's not nice to execute the program, just to find out whether
we have it.
This will be used on our gitlab-ci tests. We do have a separate,
dedicated test on gitlab-ci for checking that "gitlab-ci.yml" is
correct.
We may intentionally want to violate that condition, but then our
`make check` should not fail.
Add a way to skip that test.
gcc-11.0.0-0.7.fc34 warns here:
CC libnm-core/libnm_core_la-nm-setting-team.lo
libnm-core/nm-setting-team.c: In function ‘nm_team_link_watcher_new_ethtool’:
libnm-core/nm-setting-team.c:127:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
127 | watcher->ref_count = 1;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:128:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
128 | watcher->type = LINK_WATCHER_ETHTOOL;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:129:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
129 | watcher->ethtool.delay_up = delay_up;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:130:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
130 | watcher->ethtool.delay_down = delay_down;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Maybe we should not use this trick and just malloc() a struct of the
intended size, however:
- the code below does a similar thing, doing it differently for ethtool
watcher is confusing.
- the NMTeamLinkWatcher is a union which cannot alter its type. In no
case is it correct to access the fields of the wrong union type. By
allocating a smaller chunk, valgrind might catch such bugs.
Also, NMTeamLinkWatcher's definition is private to the C source file,
in no case must anybody assume that the rest of the buffer actually
exists.
Hence, workaround the warning by suppressing it.
We allow normalizing the slave-type, but sometimes, we may want to
validate a profile according to the set slave-type.
For example, a "ovs-external-ids" setting should only be allowed for
"connection.slave-type=ovs-interface". But during verify, the slave-type
may be missing and not yet normalized. We need to be able to obtain
the actually used slave-type.
musl added support for reallocarray, but the function prototype is
declared in stdlib.h instead of malloc.h.
Update the check for reallocarray to check both in malloc.h and
stdlib.h.
https://man7.org/linux/man-pages/man3/reallocarray.3.html
wpa_supplicant has a property "scanning" and a "state=scanning".
Previously, NetworkManager considered both parts to indicate whether
supplicant is currently scanning (if either the property or the state
indicated scanning, it took that as indication for scanning).
If NetworkManager thinks that supplicant is scanning, it suppresses
explicit "Scan" requests. That alone is not severe, because the "Scan"
request is only to trigger a scan in supplicant (which supplicant
possibly is already doing in state "scanning").
However, what is severe is that NetworkManager will also block autoconnect
while supplicant is scanning. That is because NetworkManager wants to get
a complete scan result before deciding which network to connect to.
It seems that wpa_supplicant can get into "state=scanning" and stay
there indefinitely. This prevents NetworkManager from autoactivating
a profile.
Fix that, to only honor the "scanning" property.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/597
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
In commit 201c153e25 ('libnm: fix GObject Introspection annotations
for functions returning a GPtrArray') these annotations were changed
to fix Vala bindings. However, bindings may treat the transfer
annotation for GPtrArray differently, so depending on the binding
we either get a leak or a double free.
It's unclear how to fix that. For now, just add a warning to the
documentation to avoid it.
The following reproducer leads to a crash:
#!/bin/python
import gi
gi.require_version("NM", "1.0")
from gi.repository import NM
def _pr(msg):
NM.utils_print(0, msg + "\n")
def process(nmc):
for device in nmc.get_devices():
cons = device.filter_connections(nmc.get_connections())
_pr(
"device %s (%s) has %s compatible connections"
% (device.get_iface(), NM.Object.get_path(device), len(cons))
)
process(NM.Client.new())
See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/305
