Next we are going to assert that the prefix length is valid.
The test needs to have valid prefix lengths too. Adjust.
(cherry picked from commit a850e438a7)
(cherry picked from commit fee1d627e9)
Of course, the prefix length cannot be larger than 32 or 128.
But as C does implicit conversions, a buggy prefix length can
lead to a (wrongly) valid prefix length.
Make the type uint32, to prevent that (at least for common cases,
unless you pass a huge 64 bit integer).
(cherry picked from commit 0cf9db42d4)
(cherry picked from commit fb6e912810)
Some were duplicated. Drop those.
Some function were in an order where they required forward declarations.
Reorder.
(cherry picked from commit d7990b359b)
(cherry picked from commit 04d982e278)
We have this util function, presumably because it's good to have it.
Use it.
(cherry picked from commit 3a545fd041)
(cherry picked from commit 09832c5639)
For convenience, most to-string methods call nm_utils_to_string_buffer_init().
This allows to omit the string buffer and use a global (thread-local)
buffer.
That "convenience" seems error prone. Start drop it.
Start by adding a g_return_if_reached() assertion to catch the cases
that use it.
(cherry picked from commit 27752bfd5b)
(cherry picked from commit 3b56f33aa2)
These string functions allow to omit the string buffer. This is for
convenience, to use a global (thread-local) buffer. I think that is
error prone and we should drop that "convenience" feature.
At various places, pass a stack allocated buffer.
(cherry picked from commit b87afac8e8)
(cherry picked from commit 14b920d3cf)
I want to get rid of "_nm_utils_to_string_buffer" (or at least, limit
and control its use). Currently it's used all over the place only
to get the size of it. Add a define instead.
(cherry picked from commit 36e709c021)
(cherry picked from commit e13c2426c8)
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)
