When the link goes down, DHCP client_receive_message*() functions return an
error and the related I/O source is removed from the main loop. With the
current implementation of systemd-networkd this doesn't matter because the DHCP
client is always stopped on carrier down and restarted on carrier up. However
it seems wrong to have the DHCP client crippled (because no packet can be
received anymore) once the link goes temporarily down.
Change the receive functions to ignore a ENETDOWN event so that the client will
be able to receive packets again after the link comes back.
There are various functions to set the DUID of a DHCPv6 client.
However, none of them allows to set arbitrary data. The closest is
sd_dhcp6_client_set_duid(), which would still do validation of the
DUID's content via dhcp_validate_duid_len().
Relax the validation and only log a debug message if the DUID
does not validate.
Note that dhcp_validate_duid_len() already is not very strict. For example
with DUID_TYPE_LLT it only ensures that the length is suitable to contain
hwtype and time. It does not further check that the length of hwaddr is non-zero
or suitable for hwtype. Also, non-well-known DUID types are accepted for
extensibility. Why reject certain DUIDs but allowing clearly wrong formats
otherwise?
The validation and failure should happen earlier, when accepting the
unsuitable DUID. At that point, there is more context of what is wrong,
and a better failure reason (or warning) can be reported to the user. Rejecting
the DUID when setting up the DHCPv6 client seems not optimal, in particular
because the DHCPv6 client does not care about actual content of the
DUID and treats it as opaque blob.
Also, NetworkManager (which uses this code) allows to configure the entire
binary DUID in binary. It intentionally does not validate the binary
content any further. Hence, it needs to be able to set _invalid_ DUIDs,
provided that some basic constraints are satisfied (like the maximum length).
sd_dhcp6_client_set_duid() has two callers: both set the DUID obtained
from link_get_duid(), which comes from configuration.
`man networkd.conf` says: "The configured DHCP DUID should conform to
the specification in RFC 3315, RFC 6355.". It does not not state that
it MUST conform.
Note that dhcp_validate_duid_len() has another caller: DHCPv4's
dhcp_client_set_iaid_duid_internal(). In this case, continue with
strict validation, as the callers are more controlled. Also, there is
already sd_dhcp_client_set_client_id() which can be used to bypass
this check and set arbitrary client identifiers.
An earlier commit 0e408b82b (dhcp6-client: handle IAID with value zero)
introduced a flag to sd_dhcp6_client to distinguish between an unset
IAID and a value set to zero.
However, that was not sufficient and broke leaving the setting
uninitialized in networkd configuration. The configuration parsing
also must distinguish between the default, unset value and an
explict zero configuration.
Fixes: 0e408b82b8
config_parse_iaid(), dhcp_identifier_set_iaid() and sd_dhcp6_client_set_iaid() all
allow for the IAID to be zero. Also, RFC 3315 makes no mention that zero
would be invalid.
However, client_ensure_iaid() would take an IAID of zero as a sign that
the values was unset. Fix that by keeping track whether IAID is
initialized.
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/73Fixes#10749.
The previous code did htole64() followed by unaligned_write_be32() (the
XOR and shift in between is endianness agnostic). That means, on every
architeture there is always exactly one byte swap and the iaid is
dependent on endianness.
Since dhcp_identifier_set_iaid() is part of the DUID generation
algorithm, this cannot be fixed without changing the client-id.
In particular, as the client-id already depends on the machine-id (and
is thus inherrently host-specific), it is better to stick to the current
behavior.
However, add a parameter to switch between old and new behaviour.
Since the new behavior is unused, the only real purpose of this
change is to self-document the oddity of the function.
Fixes: 933f9caeeb
Arguably, libsystemd-network is (still) entirely internal API.
However there is the aim of maybe exposing it as public API.
For that reason, it cannot include internal headers from
"src/basic/".
Note how files "src/systemd/sd-*.h" don't include any systemd
headers which don't themself have an "sd-" prefix.
Fixes: d89a400ed6
Since we now have the possibility to request prefixes to be delegated
without corresponding IPv6 addresses, it does not make sense to store
lease T1 and T2 timeouts in the otherwise unused IA_NA structure.
Therefore lease timeouts T1 and T2 are moved to the DHCPv6 client
structure, as there will be only one set of stateful timeouts required
by RFC 7550, Section 4.3.
Select T1 and T2 timeouts based on whether addresses or prefixes were
requested and what the server offered. The address and prefix timeouts
values have been computed earlier when the relevant DHCPv6 options were
parsed.
Add function to fetch the IAID for the delegated IA_PD prefix. In
order to keep things simple in the implemntation, the same IAID
is used with IA_NA addresses and IA_PD prefixes. But the DHCPv6
server can choose to return only IA_PD prefixes, and the client
can nowadays omit requesting of IA_NA addresses. Since the function
fetching said IAID from the lease looks only for IA_NA ones, it
will return an empty IAID, which of course does not match the one
set for prefixes.
Fix this by adding a function returning the IAID for the prefix.
Add function to enable/disable IA_NA address requests. Internally
handle the request as a bit mask and add IA_PD prefix delegation
to the same bit mask instead of having a separate boolean. Thus
the calling code can set requests for prefix and address delegation
separately. This is handy when supporting RFC 7084.
Add a check in the code that at least something is requested from
the server in Managed mode. By default request IA_NA addresses from
the DHCPv6 server. Although a value has been defined for IA_TA,
temporay IA_TA addresses are not yet requested.
Add helper function for fetching enabled/disabled state of Prefix
Delegation for a DHCPv6 client. Update function setting prefix
delegation to use an int instead of a boolean.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
