As far as I can tell, no DHCPv6 RFC specifies this option. The handling
for the zero option was added in #17736 by @benpicco to fix issues
encountered while trying to retrieve a DHCHPv6 lease. However, I
strongly suspect that the zero option was encountered in this case due
to an out-of-bounds read performed in RIOT's DHCPv6 client
implementation (i.e. the option parsing loop read beyond the packet
bounds). This issue was fixed in #18307 and I strongly suspect that it
should also fix the issue @benpicco originally encountered in #17736. As
such, I propose that we remove the if statement which treats the zero
option as an end-of-payload marker.
Fixes#18309
- most were trivial
- missing group close or open
- extra space
- no doxygen comment
- name commad might open an implicit group
this hould also be implicit cosed but does not happen somtimes
- crazy: internal declared groups have to be closed internal
The _parse_reply function iterates over the DHCPv6 message options
twice but only performs sanity checks on the option length in the
first iteration. As such, both loop iterations need to be identical.
Unfortunately, there aren't without this commit as (1) they use
different maximum length values and (2) the first iteration stops
parsing as soon as it encounters a zero option while the second
doesn't. As such, it is possible for out-of-bounds read to be
performed by the second loop iteration. This commit fixes this.
The REPLY of a TP-Link router (WR400 v4.20) ends with a 0 option
that has a bogus length.
When subtracting the length from the remaining length, we get an
underflow (remaining `len` is 3, option len is 4).
To get a working DHCP response, consider 0 (Reserved) an end marker.
If we did not enable downstream interfaces yet but have IA_PD enabled
or if we did not configure an interface for IA_NA but have the module
enabled, don't discard the DHCP reply.
If a server does not support an option it will respond with an error
code.
Prefix delegation used to be the only supported feature of our DHCPv6
client, but by now it also supports MUD, DNS recursive name servers and
IA_NA is on the horizon. So it makes sense to make IA_PD an optional
module like all those other features are as well.
There is no real reason for that pseudo-module to use the `gnrc_`
prefix. Neither does it need GNRC-components (except, but optionally, as
a network stack of course), nor is it implemented with in the GNRC
network stack.
This changes the prefixes of the symbols generated from USEMODULE and
USEPKG variables. The changes are as follow:
KCONFIG_MODULE_ => KCONFIG_USEMODULE_
KCONFIG_PKG_ => KCONFIG_USEPKG_
MODULE_ => USEMODULE_
PKG_ => USEPKG_
The DHCPv6 server might send reponses multiple times.
The DHCPv6 client will only handle the first response, if additional
responses are comming in they are left in the RX queue.
That results in the client always reading the response of a previous
transaction on any subsequent transactions.
In this case the client will try again, creating a new transaction - that
will again only read the previous response.
To fix this, discard previous responses by flushing the RX queue before
sending a new message to the DHCPv6 server.
fixes#13834
There were two subtle bugs that prevented the DHCPv6 client to request
multiple prefixes for different interfaces.
- `dhcpv6_client_req_ia_pd()` would fill up *all* leases with the same interface
- `_parse_reply()` would return after parsing the first answer
With this patch, `gnrc_border_router` gets a prefix on both interfaces of the at86rf215.
This implements a client for DHCPv6 IA_PD (Identity Association for
Prefix Delegation). Goal was to have a IETF-compliant alternative to
UHCP. The implementation was based on RFC 8415.
