On Fedora rawhide we get the following build failure:
In file included from shared/systemd/src/basic/alloc-util.c:3:
./shared/systemd/sd-adapt-shared/nm-sd-adapt-shared.h:114:21: error: static declaration of 'gettid' follows non-static declaration
114 | static inline pid_t gettid(void) {
| ^~~~~~
In file included from /usr/include/unistd.h:1170,
from /usr/include/glib-2.0/gio/gcredentials.h:32,
from /usr/include/glib-2.0/gio/gio.h:46,
from ./shared/nm-utils/nm-macros-internal.h:31,
from ./shared/nm-default.h:293,
from ./shared/systemd/sd-adapt-shared/nm-sd-adapt-shared.h:22,
from shared/systemd/src/basic/alloc-util.c:3:
/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' was here
34 | extern __pid_t gettid (void) __THROW;
| ^~~~~~
glibc supports now gettid() call ([1]) which conflicts with our compat
implementation. Rename it.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=1d0fc213824eaa2a8f8c4385daaa698ee8fb7c92
(cherry picked from commit 10276322bd)
(cherry picked from commit cfb970b277)
(cherry picked from commit d160b7b990)
(cherry picked from commit b10a7e5786)
4 properties are not really relevant for an already activated connection
or it makes not sense to change them. These are connection.id, connection.uuid,
connection.autoconnect and connection.stable-id.
For convenience, we allow to reapply these. This way, one can take
a different setting (e.g. with a different connection.id or
connection.uuid) and reapply them, but such changes are silently
ignored.
However this was done wrongly. Instead of reverting the change to the new
applied connection, we would change the input connection.
This is bad, for example with
nmcli connection up uuid cb922f18-e99a-49c6-b200-1678b5070a82
nmcli connection modify cb922f18-e99a-49c6-b200-1678b5070a82 con-name "bogus"
nmcli device reapply eth0
the last re-apply would reset the settings-connection's connection ID to
what was before, while accepting the new name on the applied-connection
(while it should have been rejected).
Fixes: bf3b3d444c ('device: avoid changing immutable properties during reapply')
(cherry picked from commit adb51c2a7f)
(cherry picked from commit 09f37d5bd4)
(cherry picked from commit 9c72ca5ee9)
(cherry picked from commit b1209e37db)
(cherry picked from commit cacb80e567)
When NM has to rebuild the platform cache, it first generates ADD and
then REMOVE events for the links. So, if an interface is removed and
readded, platform will emit the ADDED event with a new ifindex while
the device with old ifindex still exists.
In such case the manager currently updates the device's ifindex but
this causes problems as the DNS manager tracks configurations by their
ifindex and so the configurations for the old device will become
stale.
Fix this by removing the device and adding it again when we detect a
change of ifindex on a device that already had valid one.
https://bugzilla.redhat.com/show_bug.cgi?id=1542366
(cherry picked from commit 281974b932)
(cherry picked from commit 17a89f7061)
If the device is later realized again, we assert that there aren't any
IP config changes queued. Therefore, they must be cleared on
unrealize().
(cherry picked from commit 9ed07fbb46)
(cherry picked from commit fb83d62395)
Since we determine the connectivity state of each device individually,
the global connectivity state is an aggregate of all these states.
I am not sure about considering here devices that don't have the (best)
default route for their respective address family. But anyway.
When we aggregate the best connectivity, we chose the numerical largest
value. That is wrong, because PORTAL is numerically smaller than
LIMITED.
That means, if you have two devices, one with connectivity LIMITED and
one with connectivity PORTAL, then LIMITED wrongly wins.
Fixes: 6b7e9f9b22https://bugzilla.redhat.com/show_bug.cgi?id=1619873
(cherry picked from commit ade753d06f)
(cherry picked from commit d1e98e334d)
(cherry picked from commit 18103b00d8)
Seems this assertion still can fail. Dunno, maybe the timeout was just too
short. Increase it.
(cherry picked from commit b7bdde6e0b)
(cherry picked from commit 4909ea71af)
Otherwise, we easily get a failure
test:ERROR:src/platform/tests/test-cleanup.c:78:test_cleanup_internal: assertion failed (addresses6->len == 2): (1 == 2)
Avoid that by waiting for kernel to add the link-local
address.
(cherry picked from commit fb63d8d706)
(cherry picked from commit b6ff26fb2f)
Inside the loop-handler, it can be interesting to know the current iteration,
and how much time is left.
(cherry picked from commit 86dc1f1394)
(cherry picked from commit 945f51d623)
Sometimes the test fail:
$ make -j 10 src/platform/tests/test-address-linux
$ while true; do
NMTST_DEBUG=d ./tools/run-nm-test.sh src/platform/tests/test-address-linux 2>&1 > log.txt || break;
done
fails with:
ERROR: src/platform/tests/test-address-linux - Bail out! test:ERROR:src/platform/tests/test-common.c:790:nmtstp_ip_address_assert_lifetime: assertion failed (adr <= lft): (1001 <= 1000)
That is, because of a wrong check. Fix it.
(cherry picked from commit e180464bcc)
(cherry picked from commit 66cbca1f21)
(cherry picked from commit 7820d71ef0)
After an update of the connection.mdns property, a reactivation is
needed to apply the new value.
Also, the ifcfg-rh variable name was wrong.
Fixes: 2e2ff6f27a
(cherry picked from commit 8e6ad2853c)
(cherry picked from commit b5468828f4)
In certain cases the timeouts may not have been unref'ed before they
need to be re-added. Add the appropriate unref calls to ensure we don't
register the timeout multiple times.
This fixes possible cases where timeouts are triggered multiple times
and even on destroyed DHCPv6 clients.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/73
(cherry picked from commit e179202e47)
(cherry picked from commit bbef6cf44a)
(cherry picked from commit d535f95b6b)
(cherry picked from commit cc3981b1272b9ce37e7d734a7b2f42e84acac535)
(cherry picked from commit 915c2f675a)
(cherry picked from commit cb77290a69)
(cherry picked from commit f211b140a5)
This improves performance of fuzzer.
C.f. oss-fuzz#11019.
(cherry picked from commit 3c72b6ed4252e7ff5f7704bfe44557ec197b47fa)
(cherry picked from commit 50403cccee)
(cherry picked from commit f11f5abb1a)
(cherry picked from commit c836279fca)
An assertion in dhcp_network_bind_raw_socket() is triggered when
starting an sd_dhcp_client without setting setting a MAC address
first.
- sd_dhcp_client_start()
- client_start()
- client_start_delayed()
- dhcp_network_bind_raw_socket()
In that case, the arp-type and MAC address is still unset. Note that
dhcp_network_bind_raw_socket() already checks for a valid arp-type
and MAC address below, so we should just gracefully return -EINVAL.
Maybe sd_dhcp_client_start() should fail earlier when starting without
MAC address. But the failure here will be correctly propagated and
the start aborted.
See-also: https://github.com/systemd/systemd/pull/10054
(cherry picked from commit 34af574d58)
(cherry picked from commit 0a797bdc2a)
(cherry picked from commit f37ed84ca4)
We must disconnect ActivateInfo before invoking callbacks.
Otherwise, it can happen that the callee cancels the cancellable,
which in turn enters activate_info_complete() again, and leads
to a crash.
https://bugzilla.redhat.com/show_bug.cgi?id=1642625
(cherry picked from commit ec37e18c64)
(cherry picked from commit 2c6fafad7a)
(cherry picked from commit 3d23e9d68f)
Commit 9d92848ada ("libnm: rename MDns flag UNKNOWN to DEFAULT")
changed the enum order without updating verify().
Fixes: 9d92848ada
(cherry picked from commit 0498c5487f)
Fixes the following error when building with gcc 4.8.5 and address
sanitizer:
src/dns/nm-dns-dnsmasq.c: In function 'update':
src/dns/nm-dns-dnsmasq.c:506:44: error: 'first_prio' may be used uninitialized in this function [-Werror=maybe-uninitialized]
} else if (first_prio < 0 && first_prio != prio)
^
(cherry picked from commit 10ef61408e)
Do some preprocessing on the DNS configuration sent to plugins:
- add the '~' default routing (lookup) domain to IP configurations
with the default route or, when there is none, to all non-VPN
IP configurations
- use the dns-priority to decide which connection to use in case
multiple connections have the same domain
- consider a negative dns-priority value as a way to 'shadow' all
subdomains from other connections
- compute reverse DNS domains
and add the resulting domain list to NMDnsIPConfigData so that
split-DNS plugins can use that directly instead of reimplementing the
same logic themselves.
(cherry picked from commit dd1e671fe5)
Similarly to what systemd-resolved does, introduce the concept of
"routing" domain, which is a domain in the search list that is used
only to decide the interface over which a query must be forwarded, but
is not used to complete unqualified host names. Routing domains are
those starting with a tilde ('~') before the actual domain name.
Domains without the initial tilde are used both for completing
unqualified names and for the routing decision.
(cherry picked from commit e91f1a7d2a)
The connection.mdns setting is a per-connection setting,
so one might expect that one activated device can only have
one MDNS setting at a time.
However, with certain VPN plugins (those that don't have their
own IP interface, like libreswan), the VPN configuration is merged
into the configuration of the device. So, in this case, there
might be multiple settings for one device that must be merged.
We already have a mechanism for that. It's NMIP4Config. Let NMIP4Config
track this piece of information. Although, stricitly speaking this
is not tied to IPv4, the alternative would be to introduce a new
object to track such data, which would be a tremendous effort
and more complicated then this.
Luckily, NMDnsManager and NMDnsPlugin are already equipped to
handle multiple NMIPConfig instances per device (IPv4 vs. IPv6,
and Device vs. VPN).
Also make "connection.mdns" configurable via global defaults in
NetworkManager.conf.
(cherry picked from commit c03a534963)
