NML3Cfg is supposed to manage an interface (by ifindex).
As such, it later will itself implement DHCP and similar addressing
methods.
However, in various cases we get additional IP configuration from
external (e.g. from a VPN connection). To support that, let NML3Cfg
track any number of NML3ConfigData instances.
This parameter really affects whether a candidate in @addresses_prune will be
considered or not. Since we already construct the prune list separately, this
parameter is at the wrong place.
This requires us to re-implement nm_platform_lookup_clone(). While the
function has a predicate callback that we could use for this purpose,
I will later add a separate predicate argument to
nm_platform_ip_address_get_prune_list(). When that happens, it would
be cumbersome to chain the two function pointers. Instead, reimplement
nm_platform_lookup_clone().
Follow the pattern of nm_platform_ip_route_sync(), which also accepts
the list of addresses that are potential candidates for removal.
This allows the caller to carefully construct the list of addresses
which are possibly removed, so that sync (possibly) only adds new
addresses.
It is beneficial to have both address families side by side.
A lot of operations are exactly the same, so it's preferable to see
that. Especially in the cases where they differ, it's preferable to see
how they differ (and why).
In this case, the functions are only called once. Having a helper
function that has no clear, unique purpose does not necessarily make the
code simpler.
Also, NMIP[46]Config is going to change completely. It will thereby move
this code (and change it). Doing that is simpler, if we see all the
relevant parts in one place.
Make the error handling similar to the other provider implementations.
- only actually return once all callbacks completed.
- cache the first error and report it.
- drop AzureData.success field. It is redundant to have AzureData.error set.
Also it was actually unused.
- ensure that we keep the first error passed during
_get_config_maybe_task_return(). Once we set an error, that error gets
returned. There is a twist here, that we prefer cancellation errors
over other error reasons.
- drop GCPData.success field. It is redundant to have GCPData.error set.
Also, it's meaningless to indicate failure, if we don't have an error
at hand.
- ensure that we keep the first error passed during
_get_config_maybe_task_return(). Once we set an error, that error gets
returned. There is a twist here, that we prefer cancellation errors
over other error reasons.
- in _get_config_fip_cb(), ensure to call _get_config_maybe_task_return()
even if we are not yet ready. That is useful to record a potential
error.
The systemd DHCPv6 client requires a hardware address only to
determine the IAID; NM always overrides the IAID with its own and
therefore the hwaddr is not used.
Removing such requirement allows DHCPv6 to run over PPP, which is
useful with DHCPv6-PD to get a prefix from the ISP.
To test this, I set up a server with pppoe-server, radvd and the Wide
DHCPv6 server providing an address and a prefix. On the client, NM was
able to obtain a prefix using both dhcp=dhclient and dhcp=systemd.
Note that if there is no hardware address and you specify
ipv6.dhcp-duid=ll or ipv6.dhcp-iaid=mac, a warning will be emitted and
NM will use a random DUID/IAID.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/478
NML3ConfigData is supposed to be used as immutable, ref-counted type.
You create it once, initialize it, seal it, and pass (immutable) references
around.
In such a scheme, having ref/unref functions not operate on const pointers
is a major inconvenience.
NML3ConfigData tracks IP addresses and routes. In their current form, these
types (NMPObject) always have an ifindex and there is no sensible way to have
an NMPObject (for routes or addresses) that have a wildcard ifindex.
Honor that by also tying NML3ConfigData to an ifindex. In most cases, the
user knows the ifindex before and can create it. On the unlikely case where
the user doesn't know the ifindex, we should add a new nm_l3_config_data_clone()
function, which allows migrating the setting from one ifindex to another.
This code is not specific to "nm-ip4-config.h"/"nm-ip6-config.h".
It applies to everybody who wants to iterate over a dedup-multi-index of
certain NMPObjects. Move it.
They ensure to consistently return -1, 0, 1. Also, I think they are
easier to understand.
What is in general hard to understand, whether a comparison sorts
ascending or descending. The macros maybe make that easier too, but it's
still confusing. That's why we have a test.
First of all, the entire nm_device_generate_connection() and
nm_ip._config_create_setting() approach is fundamentally flawed. You
cannot generate sensible configuration by reading IP addresses from
an interface. Anyway, that's what we still sometimes do, and we possibly
should do it less and less.
It's ugly that nm_ip6_config_capture() would read the "disable_ipv6"
sysctl value and cache it in NMIP6Config. Only so that it can be use
much later during nm_ip6_config_create_setting().
Instead, read the sysctl value shortly before it's needed.
