Currently, is retrieved by default only from the device with the
default route. This is done so that in presence of multiple
connections the choice is deterministic.
However, this limitation seems confusing for users, that expect to get
an hostname even for non-default devices. Change the default and allow
any device to obtain the hostname.
Note that when there is a default route, NM still prefers that device
and so the behavior doesn't change.
The only change in behavior is that when there is no default route and
the machine doesn't have a static hostname, NM will try to get
hostname from DHCP or reverse DNS.
https://bugzilla.redhat.com/show_bug.cgi?id=1766944
NMTernary is part of libnm's public API. It thus cannot be used by code
without libnm/libnm-core dependency.
Add another enum with the same purpose.
The name "NMTernary" is already taken, and we should not use some macro
trickery to use (effectively) different types under the same name.
Another possible name would be "NMTern", but for no strong reasons
we choose NMOptionBool. The naming reminds of rust's std::option::Option.
We want to use this by "shared/nm-platform", which should have
no dependency on "libnm-core".
Move "libnm-core/nm-ethtool-utils.h" to "libnm/nm-ethtool-utils.h" so
that it is only used by libnm. This file contains the defines for
the option names.
Also, symlink "libnm/nm-ethtool-utils.h" as "shared/nm-base/nm-ethtool-utils-base.h".
We want to use the same defines also internally. Since they are both
public API (must be in libnm) and should be in "shared/nm-base", this
is the way.
We want to use these defines for option names also in "shared/nm-base"
(and in turn in "shared/nm-platform), which cannot include "libnm-core".
However, they are also public API of libnm.
To get this done, in a first step, move these defines to a new header
"libnm-core/nm-ethtool-utils.h".
Since now the name "nm-ethtool-utils.h" is taken, also rename
nm-libnm-core-intern files.
Currently src/platform depends on libnm-core. libnm-core is large
optimally we have a better separation between our code. That means
libnm-core does not depend on platform and vice versa.
However, nm-platform re-uses some enums from libnm-core for internal code.
To avoid that dependency, add _NMSettingWiredWakeOnLan as a duplicate to
nm-base/nm-base.h. nm-base can both be used by libnm-core, nm-platform
and src/platform.
The only problem is that NMSettingWiredWakeOnLan is also part of public
API of libnm. It means, we must duplicate the enum. But with several
static assertions in unit tests I think that is not a problem to do.
Our dependencies are complicated.
Currently "src/platform" uses parts of libnm-core and is relatively
strongly entangled with core. It would be nice to have that part
clearly independent from "src" and from "libnm-core".
Also, "src/platform/nm-platform-utils.h" uses NMEthtoolID enum, which
previously was defined in "libnm-core/nm-libnm-core-intern/nm-ethtool-utils.h".
Move that to a new place "shared/nm-base/nm-base.h".
Note that we have "libnm-core/nm-libnm-core-intern", which is
libnm/core related code which uses and is used by libnm-core.
There is a need for a library which is used by libnm-core, but
does not depend on libnm-core itself. Here comes "shared/nm-base".
Yes, many libraries. But the goal is to entangle the dependencies
and have a clear hierarchy of includes. And to have "shared/nm-platform"
independent of libnm-core.
"src/nm-logging.c" should be independent of libnm-core. It almost
is, except the error domain and code.
Move NM_MANAGER_ERROR to "nm-glib-aux/nm-shared-utils.h" so that
"nm-logging.c" is independent of libnm-core.
This is the same as libnm's nm_utils_hwaddr_aton(), which however
is public API.
We want to use this function also without libnm(-core). Hence add
the helper to "shared/nm-glib-aux".
Enums can also be negative (contrary to Flags). Fix the parsing.
$ nmcli connection modify "$PROFILE" connection.llmnr -1
Error: failed to modify connection.llmnr: invalid option '-1', use one of [default,no,resolve,yes].
With LTO build on s390x (Fedora 33) we get a compiler warning:
libnm-core/nm-setting-ethtool.c: In function 'nm_setting_ethtool_get_optnames':
libnm-core/nm-setting-ethtool.c:263:60: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
263 | return len > 0 ? nm_memdup(names, sizeof(names[0]) * (((gsize) len) + 1u)) : NULL;
| ^
libnm-core/nm-setting-ethtool.c:257:24: note: 'len' was declared here
257 | guint len;
| ^
libnm-core/nm-setting-ethtool.c: In function 'nm_setting_ethtool_get_optnames':
libnm-core/nm-setting-ethtool.c:263:60: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
263 | return len > 0 ? nm_memdup(names, sizeof(names[0]) * (((gsize) len) + 1u)) : NULL;
| ^
libnm-core/nm-setting-ethtool.c:257:24: note: 'len' was declared here
257 | guint len;
| ^
RFC4361 intends to set the same IAID/DUID for both DHCPv4 and DHCPv6.
Previously, we didn't have a mode for that.
Of course, you could always set "ipv4.dhcp-client-id" and
"ipv6.dhcp-duid" to (the same) hex string, but there was no
automatic mode. Instead we had:
- "ipv4.dhcp-client-id=duid" which sets the client ID to a stable,
generated DUID. However, there was no option so that the same
DUID/IAID would be automatically used for DHCPv6.
- there are various special values for "ipv6.dhcp-duid" which generate
a stable DUIDs. However, those values did not work for
"ipv4.dhcp-client-id".
Solve that by adding "ipv4.dhcp-client-id=ipv6-duid" which indicates to use
the DUID from DHCPv6's "ipv6.dhcp-duid" setting. As IAID it will prefer "ipv4.dhcp-iaid"
(if set), but fallback to "ipv6.dhcp-iaid".
https://tools.ietf.org/html/rfc4361https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/618https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/718
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.
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.
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.
NetworkManager is now able to configure veth interfaces throught the
NMSettingVeth. Veth interfaces only have "peer" property.
In order to support Veth interfaces in NetworkManager the design need
to pass the following requirements:
* Veth setting only has "peer" attribute.
* Ethernet profiles must be applicable to Veth interfaces.
* When creating a veth interface, the peer will be managed by
NetworkManager but will not have a profile.
* Veth connection can reapply only if the peer has not been modified.
* In order to modify the veth peer, NetworkManager must deactivate the
connection and create a new one with peer modified.
In general, it should support the basis of veth interfaces but without
breaking any existing feature or use case. The users that are using veth
interfaces as ethernet should not notice anything changed unless they
specified the veth peer setting.
Creating a Veth interface in NetworkManager is useful even without the
support for namespaces for some use cases, e.g "connecting one side of
the veth to an OVS bridge and the other side to a Linux bridge" this is
done when using OVN kubernetes [1][2]. In addition, it would provide
persistent configuration and rollback support for Veth interfaces.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Revert this change. One problem is that none of the current GUIs
(nm-connection-editor, gnome-control-center, plasma-nm) expose the
dns-priority option. So, users tend to have their profile value set to
0. Changing the default means for them not only a change in behavior,
but its hard to fix via the GUI.
Also, what other call DNS leaks, is Split DNS to some. Both uses make
sense, but have conflicting goals. The default cannot accommodate both
at the same time.
Also, with split DNS enabled (dnsmasq, systemd-resolved), the concern
for DNS leaks is smaller. Imagine:
Wi-Fi profile with ipv4.dns-priority (effectively) 100, domain "example.com".
VPN profile with ipv4.dns-priority (effectively) 50 and a default route.
That is a common setup that one gets by default (and what probably many
users have today). In such a case with split DNS enabled, the Wi-Fi's DNS
server only sees requests for "*.example.com". So, it does not leak
everything.
Hence, revert this change before 1.28.0 release to the earlier behavior.
This reverts commit af13081bec.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/688
C casts unconditionally force the type, and as such they don't
necessarily improve type safety, but rather overcome restrictions
from the compiler when necessary.
Casting a void pointer is unnecessary (in C), it does not make the
code more readable nor more safe. In particular for g_object_new(),
which is known to return a void pointer of the right type.
Drop such casts.
sed 's/([A-Za-z_0-9]\+ *\* *) *g_object_new/g_object_new/g' $(git grep -l g_object_new) -i
./contrib/scripts/nm-code-format-container.sh
We have:
- nm_utils_hashtable_cmp(): this does a full cmp of two hash
tables, with the intent to provide a stable sort order.
It thus takes a GCompareDataFunc() argument.
- nm_utils_hashtable_cmp_equal(): this is like nm_utils_hashtable_cmp(),
except that the caller won't get a compare value, only a boolean
value that indicates equality.
This was previously called nm_utils_hashtable_equal().
- nm_utils_hashtable_equal(): this takes a GEqualFunc function
for comparing the values for equality. It takes thus
a different kind of predicate, but otherwise is similar to
nm_utils_hashtable_cmp_equal().
This was previously called nm_utils_hash_table_equal().
Unify the naming of these functions.
Historically, keyfile read/write code was part of core, and thus
GPL-2.0+ licensed. Keyfile is the native file format for NetworkManager
connection profiles, and code to handle that should be part of libnm.
This would unlock many interesting features, like tools being able
to import/export connection profiles in the native file format.
However, libnm is LGPL-2.1+ licensed, so this is a problem.
The alternative would be to add a separate, GPL licensed library
(libnm-keyfile.so or libnm-gpl.so). However that also requires a larger
rework, because the current keyfile implementation uses internal API
from libnm-core and it would need to be reworked to only use public
API of libnm.
Relicense the code instead. According to research and "keyfile-history.sh"
script, the following individuals and companies possibly hold copyright
on the code:
<bgalvani(at)redhat.com>
<blueowl(at)centrum.cz>
<daniel(at)gnoutcheff.name>
<danw(at)redhat.com>
<dcantrell(at)redhat.com>
<dcbw(at)redhat.com>
<evan(at)ebroder.net>
<fgiudici(at)redhat.com>
<floe(at)butterbrot.org>
<j(at)bootlab.org>
<kmaraas(at)gnome.org>
<lkundrak(at)v3.sk>
<luzpaz(at)users.noreply.github.com>
<martinpitt(at)gnome.org>
<michael.i.doherty(at)intel.com>
<pavlix(at)pavlix.net>
<pmarti(at)warp.es>
<rafaelff(at)gnome.org>
<rstrode(at)redhat.com>
<tambet(at)gmail.com>
<tgraf(at)redhat.com>
<thaller(at)redhat.com>
<walters(at)verbum.org>
<yurchor(at)ukr.net>
Intel Corporation
Novell, Inc.
Red Hat, Inc.
Ximian, Inc.
Most contributors on this list agreed to relicensing according to RELICENSE.md.
The following copyright holders did not answer the request for agreeing
to relicensing:
- <j(at)bootlab.org>: no contributions were made that are related to
keyfile implementation. The script just gives a false positive.
- <pmarti(at)warp.es>: the contribution is a fix of a spelling error
(commit 6029288ffb).
- <tgraf(at)redhat.com>: the contribution to keyfile code are small
(I only identified commit 5b7503e95e).
Also, Thomas worked for Red Hat at the time.
After research, I think it's fair to conclude that everybody who holds
non-trivial copyright on the keyfile code agreed to the relicensing.
