We call sync many times. Often there is nothing to update. Check the
cache first, before (re) adding it.
Note that many addresses have a limited lifetime, that is, a lifetime
that keeps counting down with seconds granularity. For those (common)
cases we will only avoid the call to kernel if there are two syncs
within less than a second.
(cherry picked from commit 528a63d9cc)
(cherry picked from commit 429540a6b7)
There is only one caller of _addr_array_clean_expired(), and it always
provides the "idx" pointer.
(cherry picked from commit de9f174d51)
(cherry picked from commit 1f05866821)
It is rather unlikely, that we call this function with no existing
routes/addresses. Hence, usually this does not safe an allocation
of the GPtrArray.
However, it's slightly less code and makes more sense this way
(instead of checking afterwards, whether the array is empty and
destroy it).
(cherry picked from commit 6bc9b73c55)
(cherry picked from commit e9d3ba66df)
The code is disabled at compile time. It's only useful for printf
debugging to modify the source to get more logging.
(cherry picked from commit fcb4033a81)
(cherry picked from commit d361bfc945)
Revert this change again. We are going to backport all the relevant
fixes from nm-1-38 about the address order.
This reverts commit da721a3f320b1e7e4628f7661bf3f78b7f12ed24.
Before 1.34, DHCPv6 addresses were preferred over SLAAC addresses
and all was good. Well, actually, we didn't have any CI tests, so
whether it really worked is only an assumption. But it probably was.
With 1.36 this broke for two reasons:
1) 1.36 would now prefer SLAAC over DHCPv6 over manual addresses.
2) 1.36 would also not adjust the order of already existing addresses.
This means, we first would get the SLAAC address and the DHCPv6
address later. Adding the address later would mean that it becomes
more important. This would go against 1), but due to 2) effectively
DHCPv6 was still preferred over SLAAC.
Commit [1] would fix 2), but now the address order changed.
We will need to fix also 1), but in the meantime, disable parts of
commit [1] so that we still get the old behavior.
[1] cd4601802d ('platform: fix address order in nm_platform_ip_address_sync()')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ ## 1021
pppd also tries to configure addresses by itself through some
ioctls. If we remove between those calls an address that was added,
pppd fails and quits.
To avoid this race condition, don't remove addresses while IPCP and
IPV6CP are running. Once pppd sends an IP configuration, it has
finished configuring the interface and we can proceed normally.
https://bugzilla.redhat.com/show_bug.cgi?id=2085382
(cherry picked from commit b41b11d613)
(cherry picked from commit e95b44bacb)
Add a function prevent the removal of addresses and routes from the
interface for a given address family.
(cherry picked from commit e8275d7139)
(cherry picked from commit 59ef1b4c78)
Currently we call nm_device_update_dynamic_ip_setup() in
carrier_changed() every time the carrier goes up again and the device
is activating, to kick a restart of DHCP.
Since we process link events in a idle handler, it can happen that the
handler is called only once for different events; in particular
device_link_changed() might be called once for a link-down/link-up
sequence.
carrier_changed() is "level-triggered" - it cares only about the
current carrier state. nm_device_update_dynamic_ip_setup() should
instead be "edge-triggered" - invoked every time the link goes from
down to up. We have a mechanism for that in device_link_changed(), use
it.
Fixes-test: @ipv4_spurious_leftover_route
https://bugzilla.redhat.com/show_bug.cgi?id=2079406https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1250
(cherry picked from commit d6429d3ddb)
(cherry picked from commit 1c158a5f37)
impl_ppp_manager_set_ip4_config always has been setting interface mtu
based on ppp configuration: do the same for ip6 in case it matters.
(cherry picked from commit 4d7b494eb3)
(cherry picked from commit 423e5e5011)
ipv6 DNS received on ppp interface were being ignored because their
priority was not set.
Fix this by using default priority in impl_ppp_manager_set_ip6_config(),
as was done for ip4_config in b2e559fab2 ("core: initialize l3cd
dns-priority for ppp and wwan")
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1022
(cherry picked from commit 6991333bc0)
(cherry picked from commit d04eba0c40)
l3cd instances must be removed from the old l3cfg before calling
_cleanup_ip_pre(). Otherwise, _cleanup_ip_pre() unregisters them from
the device, and later _dev_l3_register_l3cds(self, l3cfg_old, FALSE,
FALSE) does nothing because the device doesn't have any l3cd.
Previously the l3cds would linger in the l3cfg, keeping a reference to
it and causing a memory leak; the leak was not detected by valgrind
because the l3cfg was still referenced by the NMNetns.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
Fixes-test: @stable_mem_consumption2
https://bugzilla.redhat.com/show_bug.cgi?id=2083453https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1252
(cherry picked from commit f69a1cc874)
(cherry picked from commit 83ee0f0779)
We want to assert that our alignment-guarantees do not exceed the
guarantees of the system-linker or system-allocator on the target
platform. Hence, we check against max_align_t. This is a lower bound,
but not the exact check we actually want. And as it turns out, on m64k
it is too low. Add a static check against 4-byte alignment for m64k as
a workaround.
Reported-by: Michael Biebl
Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com>
https://github.com/c-util/c-rbtree/issues/9eb778d3969
(cherry picked from commit 78831d127f)
(cherry picked from commit a83c884fb6)
Supplicant does not allow setting certain properties to empty values.
It also does not make sense.
Also, ifcfg-rh writer uses svSetValueStr() for these properties, so
the ifcfg plugin would always loose having hte values set to "".
Also, you couldn't enter these strings in nmcli.
It's fair to assume that it makes no sense to have these values set to
an empty value. Since we cannot just tighten up verification to reject
them, normalize them.
It also seems that some GUI now starts setting domain_suffix_match to an
empty string. Or maybe it was always doing it, and ifcfg plugin just hid
the problem? Anyway, we have users out there who set these properties to
"".
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/973
(cherry picked from commit 915e923928)
It seems, we should make decisions based on the latest state.
Make sure to process all pending netlink events.
(cherry picked from commit 9a69bc8d84)
(cherry picked from commit 1b9dfd3001)
IPv6 temporary addresses are configured by kernel, with the
"ipv6.ip6-privacy" setting ("use_tempaddr" sysctl) and the
IFA_F_MANAGETEMPADDR flag.
As such, the idea was that during reapply we would not remove them.
However, that is wrong.
The only case when we want to keep those addresses, is if during reapply
we are going to configure the same primary address (with mngtmpaddr
flag) again. Otherwise, theses addresses must always go away.
This is quite serious. This not only affects Reapply. Also during disconnect
we clear IP configuration via l3cfg.
Have an ethernet profile active with "ipv6.ip6-privacy". Unplug
the cable, the device disconnects but the temporary IPv6 address is not
cleared. As such, nm_device_generate_connection() will now generate
an external profile (with "ipv6.method=disabled" and no manual IP addresses).
The result is, that the device cannot properly autoconnect again,
once you replug the cable.
This is serious for disconnect. But I could not actually reproduce the
problem using reapply. That is, because during reapply we usually
toggle ipv6_disable sysctl, which drops all IPv6 addresses. I still
went through the effort of trying to preserve addresses that we still
want to have, because I am not sure whether there are cases where we
don't toggle ipv6_disable. Also, doing ipv6_disable during reapply is
bad anyway, and we might want to avoid that in the future.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
(cherry picked from commit 518f6124c6)
(cherry picked from commit 3bd210a8f1)
It's annoying to do
(arr ? arr->data : NULL)
Especially, because usually you'd need to cast the above
(which would have type (char *)).
(cherry picked from commit 5ff08fbbea)
(cherry picked from commit 281b3e6473)
A virtual infiniband profile (with p-key>=0) can also contain a
"connection.interface-name". But it is required to match the
f"{parent}.{p-key}" format.
However, such a profile can also set "mac_address" instead of "parent".
In that case, the validation code was crashing.
nmcli connection add type infiniband \
infiniband.p-key 6 \
infiniband.mac-address 52:54:00:86:f4:eb:aa:aa:aa:aa:52:54:00:86:f4:eb:aa:aa:aa:aa \
connection.interface-name aaaa
The crash was introduced by commit 99d898cf1f ('libnm: rework caching
of virtual-iface-name for infiniband setting'). Previously, it would not
have crashed, because we just called
g_strdup_printf("%s.%04x", priv->parent, priv->p_key)
with a NULL string. It would still not have validated the connection
and passing NULL as string to printf is wrong. But in practice, it
would have worked mostly fine for users.
Fixes: 99d898cf1f ('libnm: rework caching of virtual-iface-name for infiniband setting')
(cherry picked from commit fd5945b408)
(cherry picked from commit d476851ee7)
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
(cherry picked from commit 41df480fdd)
(cherry picked from commit 29e90e4722)
It seems clearer to explicitly set this always, and not rely on the
defaults.
(cherry picked from commit bacd3e1482)
(cherry picked from commit 6ad3694fc5)
audit_encode_nv_string() is documented that it might fail. Handle
the error.
Also, the returned string was allocated with malloc(). We must free
that with free()/nm_auto_free, not g_free()/gs_free.
Fixes: be49a59fb6 ('core: add audit support')
(cherry picked from commit 6ebc622303)
(cherry picked from commit 7f0d9a9091)
In glib_dep we specify
"-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40"
which is the dependency we use almost everywhere. With g-ir-scanner
this causes compiler warnings:
[xxx] Generating NM-1.0.gir with a custom command
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_object_type’:
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:252:13: warning: Not available before 2.70
252 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_fundamental_type’:
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:370:13: warning: Not available before 2.70
370 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
g-ir-scanner: link: gcc -o /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0 /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -L/src/NetworkManager/build/src/libnm-client-impl -Wl,-rpath,/src/NetworkManager/build/src/libnm-client-impl -lnm -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgmodule-2.0 -ludev -lgirepository-1.0 -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lglib-2.0
Work around that.
Meson's gnome.generate_gir() is not very flexibly in allowing to
pass extra `--cflags-begin {} --cflags-end` parameters.
Hack around by adding a pseudo dependency that resets
these defines.
See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/331
See-also: 1234e5583a ('build/autotools: avoid compiler warning generating "NM-1.0.gir"')
(cherry picked from commit e5d4194673)
(cherry picked from commit 508c677f0c)
We passed on the CFLAGS, but they also contain
"-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40"
which causes compiler warnings:
GISCAN src/libnm-client-impl/NM-1.0.gir
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c: In function ‘dump_object_type’:
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c:251:13: warning: Not available before 2.70
251 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c: In function ‘dump_fundamental_type’:
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c:369:13: warning: Not available before 2.70
369 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
Filter them out.
See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/331
(cherry picked from commit 1234e5583a)
(cherry picked from commit 2ed877049b)
If we have a lease and we get a NAK renewing/rebinding it, the lease
is lost.
Without this, probe->current_lease remains set and after the next
DISCOVER/OFFER round, any call to n_dhcp4_client_lease_select() will
fail at:
if (lease->probe->current_lease)
return -ENOTRECOVERABLE;
As in:
[5325.1313] dhcp4 (veth0): send REQUEST of 172.25.1.200 to 255.255.255.255
[5325.1434] dhcp4 (veth0): received NACK from 172.25.1.1
[5325.1435] dhcp4 (veth0): client event 3 (RETRACTED)
[5325.1436] dhcp4 (veth0): send DISCOVER to 255.255.255.255
[5325.1641] dhcp4 (veth0): received OFFER of 172.25.1.200 from 172.25.1.1
[5325.1641] dhcp4 (veth0): client event (OFFER)
[5325.1641] dhcp4 (veth0): selecting lease failed: -131 (ENOTRECOVERABLE)
Upstream: https://github.com/nettools/n-dhcp4/pull/33
Upstream: e4af93228ehttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/993
Fixes: e43b1791a3 ('Merge commit 'e23b3c9c3ac86b065eef002fa5c4321cc4a87df2' as 'shared/n-dhcp4'')
(cherry picked from commit e141cd45d6)
(cherry picked from commit e056a68d21)
@error was leaked when created inside the function.
While at it, remove the goto.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
(cherry picked from commit 6f6c044739)
(cherry picked from commit e8d6ad9d12)
ASSUME is causing more troubles than benefits it provides. This patch is
dropping NM_L3_CFG_COMMIT_TYPE_ASSUME and assume_config_once. NM3LCfg
will commit as if the sys-iface-state is MANAGED.
This patch is part of the effort to remove ASSUME from NetworkManager.
After ASSUME is dropped when starting NetworkManager it will take full
control of the interface, re-configuring it. The interface will be
managed from the start instead of assumed and then managed.
This will solve the situations where an interface is half-up and then a
restart happens. When NetworkManager is back it won't add the missing
addresses (which is what assume does) so the interface will fail during
the activation and will require a full activation.
https://bugzilla.redhat.com/show_bug.cgi?id=2050216https://bugzilla.redhat.com/show_bug.cgi?id=2077605https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1196
(cherry picked from commit bf5927b978)
(cherry picked from commit a494c00901)
We already have a comparison of NMPlatformIPXAddress with the modes
"full" and "id". The former is needed to fully compare two addresses,
the latter as identity for tracking addresses in the cache.
In NetworkManager we also use the NMPlatformIP[46]Address structure to
track the addresses we want to configure. When we add them in kernel,
we will later see them in the platform cache. However, some fields
will be slightly different. For example, "addr_source" address will
always be "kernel", because that one is not a field we configure in
kernel. Also, the "n_ifa_flags" probably differ (getting "permanent"
and "secondary" flags).
Add a compare function that can ignore such differences.
Also add nm_platform_vtable_address for accessing the IPv4 and IPv6
methods generically (based on an "IS_IPv4" variable).
(cherry picked from commit ef1b60c061)
(cherry picked from commit ea6625ce97)
nmp_utils_lifetime_get() calculates the lifetime of addresses,
and it bases the result on a "now" timestamp.
If you have two addresses and calculate their expiry, then we want to
base it on top of the same "now" timestamp, meaning, we should
only call nm_utils_get_monotonic_timestamp_sec() once. This is also a
performance optimization. But much more importantly, when we make a
comparison at a certain moment, we need that all sides have the same
understanding of the current timestamp.
But nmp_utils_lifetime_get() does not always require the now timestamp.
And the caller doesn't know, whether it will need it (short of knowing
how nmp_utils_lifetime_get() is implemented). So, make the now parameter
an in/out argument. If we pass in an already valid now timestamp, use
that. Otherwise, fetch the current time and also return it.
(cherry picked from commit deb37401e9)
(cherry picked from commit 9e40474c71)
