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>
When module `nanocoap_server_separate` is not used, the functions to
send separate responses are still provided, just in a broken version:
They will send the separate replies from a different endpoint than the
request was received at (even on machines with only one IP address, as
also the source port is randomized).
This changes the behavior to only provide the functions for separate
response when the do work, so that others will detect an invalid
configuration at compile time rather than at run time.
The documentation is duly updated.
When RFC 8974 support (module `nanocoap_token_ext`) is in use, the
request token may be longer than the buffer in the separate response
context is large. This adds a check to not overflow the buffer.
Sadly, this is an API change: Preparing the separate response context
can actually fail, so we need to report this with a return value.
The example application has been adapted to only proceed if the separate
reply context could have been prepared, and rather directly emit a
reset message if the token exceeds the static buffer.
Co-authored-by: benpicco <benpicco@googlemail.com>
Split key attributes definitions into separate file, together with
some basic support macros and helper functions.
This allows PSA crypto backends to use this definitions without
pulling in all the other type definitions.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Split key definitions into separate files, together with some basic
support macros.
This allows PSA crypto backends to use this definitions without
pulling in all the other type definitions.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
We do not need to add an array of pointers to the shell commands, just
an array of shell commands is sufficient. This reduced the overhead of
XFA by `sizeof(void *)` per command.
It's very unlikely that a pkt snip will have more than 255 users.
Use a uint8_t here to save 4 bytes per snip as this now fits into
the ununsed struct padding.
This command does the same as `help`, but provides a machine readable
JSON rather than a human readable table. It is only provided when the
(pseudo-)module `shell_builtin_cmd_help_json` is used.
This changes the API of xfa from
XFA(array_name, prio) type element_name = INITIALIZER;
to
XFA(type, array_name, prio) element_name = INITIALIZER;
this allows forcing natural alignment of the type, fixing failing tests
on `native64`.
Before, handlers writing blockwise transfer assumed that the response
header length will match the request header length. This is true for
UDP, but not for TCP: The CoAP over TCP header contains a Len field,
that gets extended for larger messages. Since the reply often is indeed
larger than the request, this is indeed often the case for CoAP over
TCP.
Note: Right now, no CoAP over TCP implementation is upstream. However,
getting rid of incorrect assumptions now will make life easier
later on.
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.
Split definition of psa_algorithm_t into a separate file, together
with some basic algorithm macros. Also move the definitions of the
hash/mac/cipher/AEAD/etc algorithm macros into separate files as
well.
This allows PSA crypto backends to use this definitions without
pulling in all the other type definitions.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
