When building without "more-asserts" and LTO enabled, we can get
a warning about uninitalized "obj" variable:
src/platform/nm-linux-platform.c: In function 'ip_route_add':
src/platform/nm-platform.c:4761:24: warning: 'MEM[(struct NMPlatformIPRoute *)&obj + 24B].rt_source' may be used uninitialized in this function [-Wmaybe-uninitialized]
4761 | route->rt_source = nmp_utils_ip_config_source_round_trip_rtprot(route->rt_source);
| ^
src/platform/nm-platform.h:2139:25: warning: 'BIT_FIELD_REF <MEM[(const struct NMPlatformIPRoute *)&obj + 24B], 8, 72>' may be used uninitialized in this function [-Wmaybe-uninitialized]
2139 | return r->table_any ? 254u /* RT_TABLE_MAIN */
|
That is due to the "default" switch case which was unhandled
when building without more-asserts". Avoid that by reworking the
code.
When building without more-assertions and LTO, the compiler might think
that "wait" is uninitialized. Avoid the warning.
Initializing a variable is not a great solution either, because
potentially it could hide an actual bug. But it still seems to be
best.
src/nm-policy.c: In function update_system_hostname:
src/nm-policy.c:909: warning: wait may be used uninitialized in this function [-Wmaybe-uninitialized]
909 | if (wait) {
|
src/nm-policy.c:901: note: wait was declared here
901 | gboolean wait;
|
On copr builds, the unit tests sometimes fail to create a veth
interface. In those cases, kernel rejects the netlink request
with EPERM. copr uses mock on Fedora 33 hosts.
I think this is a kernel bug. Add a workaround by retrying a few times.
Linux headers and some libc headers have overlapping defines
for network types and functions.
In the past years, glibc and linux headers were improved to cooperate
so you could include either one, in any order.
With musl and possibly some older glibc versions that doesn't work so
well.
Reorder and change includes to make it work better. Yes, this looks
pretty random and unmotivated. The includes are changed in order to
successfully build on various libc/kernel versions, with the goal
of not using #if.
Due to mixing includes of userspace network headers (net/*) and
kernelspace onces (linux/if*) symbol redefinitions happen on musl.
[thaller@redhat.com: modified original patch]
We were asserting against error messages from strerror(), and on libmusl
these are different. Relax the checks.
We still assert against parts of the text, where possible. So a similar
problem could happen in the future or with another libc library.
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>
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.
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>
<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.
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')
During shutdown, NM always tries to remove from ovsdb all bridges,
ports, interfaces that it previously added. Currently NM doesn't run
the main loop during shutdown and so it's not possible to perform
asynchronous operations. In particular, the NMOvsdb singleton is
disposed in a destructor where it's not possible to send out all the
queued deletions.
The result is that NM deletes only one OVS interface, keeping the
others. This needs to be fixed, but requires a rework of the shutdown
procedure that involves many parts of NM.
Even when a better shutdown procedure will be implemented, we should
support an unclean shutdown caused by e.g. a kernel panic or a NM
crash. In these cases, the interfaces added by NM would still linger
in the ovsdb.
Delete all those interface at NM startup. If there are connections
profiles for them, NM will create them again.
https://bugzilla.redhat.com/show_bug.cgi?id=1861296https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/700
By now, each NMDevice does the reverse lookup and caches the result
via nm_device_get_hostname_from_dns_lookup().
The code is no longer used in NMPolicy.
Fixes: 09c8387114 ('policy: use the hostname setting')
When a connection is reactivated, there could be two active
connections tracked by the manager: the deactivating one and the new
one. Ensure that we first return the most recent one so that slaves
will pick the right master.
Fixes-test: @iptunnel_gretap_doc_procedure
Fixes: dc6ec6ce7b ('core: reverse the order of active connections in the manager')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/697
We now always use SetLinkDefaultRoute(), but that API was only added in
systemd v240 ([1]).
We could just always call the non-existing method, and ignore the
error. However, that feels ugly. Would systemd-resolved log warnings
about that? Should we suppress all messages about that failure (not
good for debugging).
Instead, make an effort to detect support of the function, and avoid
calling it. That is significantly more complicated than just always
calling the method and not care.
Note that even if systemd-resolved does not support SetLinkDefaultRoute(),
we cannot do anything smart about that. We would simply rely on
systemd-resolved (hopefully) doing the right thing automatically.
That's better and simpler than explicitly adding a "~." domain in
the fallback case.
Also, detecting support is straight forward in the common case, where
there is either success or a clear "org.freedesktop.DBus.Error.UnknownMethod"
error. In cases where there is any other failure, we don't really know.
In that case, we keep trying to use the API under the assumption that
it should work.
[1] https://github.com/systemd/systemd/commit/7 ## 7673795dcf5797491e7f785cbf5077d29a15db4
When the DNS settings change, we update the request_queue_lst_head list,
with all the requests we want to send.
Then, send_updates() will try to send it. It might not do it right away,
if resolved is not on the bus or the D-Bus connection is not fully inialized
(meaning, we don't know the name owner yet). In those cases, we would
keep the list of requests, and send them later.
However, when sending them, we would also forget about the configuration.
That means, if you restart systemd-resolved, then the daemon drops off
the bus and reappears. I think that systemd-resolved in fact persists
the configuration during restart. So, usually the settings are still the
same after restart. However, we should do better here: if the service
appears, we should send the settings again.
This means to not forget the requests after we send them once -- at
least, until a new update replaces them.
We will need these changes next:
- add "self" and "ifindex" fields to RequestItem struct. We will
pass on these structs are user-data for the callbacks, so that
we afterwards know which request completed.
- add DBUS_OP_SET_LINK_DEFAULT_ROUTE global variable. We don't
clone the "operation" string but use string literals. However,
string literals are not guaranteed to be deduplicated, so we
should only compare them with strcmp(). The static variable
avoids this: we can use pointer equality to compare it.
This will be used next.
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>
If the same MAC address is set on both the bridge connection and the
interface connection, and the interface is local, NM currently sets
the hwaddr record in both Bridge and Interface ovsdb tables. As a
result, ovs complains with error:
bridge|ERR|interface br0: ignoring mac in Interface record (use Bridge record to set local port's mac)
Avoid this error: if the bridge and interface MACs are the same, just
set the address in the Bridge table; if they are different, give a
more detailed warning and ignore the interface MAC.
https://bugzilla.redhat.com/show_bug.cgi?id=1899745
The parser checks if the first token of an ip= argument is an IP
address to determine which of the two possible syntaxes is used:
ip=<interface>:{dhcp|on|any|dhcp6|auto6}[:[<mtu>][:<macaddr>]]
ip=<client-IP>:[<peer>]:<gateway-IP>:<netmask>:<client_hostname>:<interface>:{none|off|dhcp|on|any|dhcp6|auto6|ibft}[:[<mtu>][:<macaddr>]]
This works as long as the first token is not empty, which - according
to the dracut.cmdline man page - seems to be guaranteed.
However, the network-legacy dracut plugin accepts an empty interface
or client IP. Also, if a user needs DHCP and wants to specify a
hostname, the only possible syntax is:
ip=::::<hostname>::dhcp
Change the parser to check the second token instead, similarly to what
the network-legacy module does [1].
[1] https://github.com/dracutdevs/dracut/blob/050/modules.d/40network/net-lib.sh#L490https://bugzilla.redhat.com/show_bug.cgi?id=1900260https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/693
If the interface is the DNS default route but has no domain, its name
servers were not sent to systemd-resolved. Fix this.
Fixes: ee9fab0361 ('dns: fix handling default routing domains with systemd-resolved')
Let's try to rework and improve the implementation.
The code is already rather complicated from the start. Let's first try
to use consistent names for things. Naming is very important, so that
they follow a pattern that tells you what something does.
We will rework preparing the DNS data, so that we do things that
currently "nm-dns-systemd-resolved.c" does (see InterfaceConfig).
We thus will need to access the NMDnsConfigData, which is per-ifindex.
As such, it is useful to have NMDnsConfigData in a stable order, sorted
by ifindex. As we track NMDnsConfigData in a hash table, we need to
do the sorting outside of that.
There are many ways to achive that. The solution here is to let
NMDnsConfigData also be tracked by a CList. We only need to resort
the list, when we add a new ifindex -- which should happen only seldom.
The advantage is that the sorting happens in-place and can expose
it to other uses (by providing them access to the CList head).
"NM_IP_CONFIG_GET_CLASS(config)->is_ipv4" only follows a pointer (except
additional assertions in debug builds). It's thus more efficient than
NM_IS_IP4_CONFIG(), which needs to compare GType and call
nm_ip4_config_get_type().
