Add a new key management option to support WPA3 Enteprise wifi
connection.
Only supported with wpa_supplicant for the time being.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
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.
