Calling `coap_get_token()` and `coap_get_token_length()` on an
(mostly) uninitialized `coap_pkt_t` did work so far due to
implementation details matching the expectations, but this is not
backed up by any API contract.
This fixes the API abuse by introducing and using a new API that does
read a token and token length from a CoAP over UDP packet out of a
buffer. This now provides the behavior expected by the caller and
commits to it via API contract.
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
Co-authored-by: benpicco <benpicco@googlemail.com>
gcoap contains a hack where a `coap_pkt_t` is pulled out of thin air,
parts of the members are left uninitialized and a function is called on
that mostly uninitialized data while crossing fingers hard that the
result will be correct. (With the current implementation of the used
function this hack does actually work.)
Estimated level of insanity: 😱😱😱😱😱
This adds to insane functions to get the length of a token and the
length of a header of a CoAP packet while crossing fingers hard that
the packet is valid and that the functions do not overread.
Estimated level of insanity: 😱😱😱
The newly introduced insane functions are used to replace the old
insane hack, resulting in an estimated reduction of insanity of 😱😱.
Side note: This actually does fix a bug, as the old code did not take
into account the length of the extended TKL field in case of
RFC 8974 being used. But that is a bug in the abused API,
and not in the caller abusing the API.
In order to properly handle an observe cancellation of a client, the server has to keep track of the notification MIDs (to be able to match an RST to a notification), see [RFC7641, 3.6 Cancellation](https://www.rfc-editor.org/rfc/rfc7641.html#section-3.6) for mor details. An alternative to this would be to make either the client send an explicit observe deregister request, or make the server send the next notification via CON (which hten allows matching of the RST due to the CON state).
This splits the _find_req_memo util function into multiple variants that match on different things. This is done in preparation of a feature that has to find a request based on a token value, without creating an artificial pdu for that. A nice side effect is that it also makes the calls to the find functions a bit more readable by not relying on an anonymous bool input.
