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.
In case no payload is added, `coap_build_reply_header()` would return
`sizeof(coap_hdr_t) + token_length` regardless of the actual header
length returned by `coap_build_hdr()`. These can be different if
RFC 8974 extended tokens are enabled (module `nanocoap_token_ext`
used): If an extended token length field is used, its size is not
considered.
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.
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>
If the timer at the head of a ztimer clock's timer list is re-scheduled
(ztimer_set() called on an already set timer) and the timer is no longer
at the head after being re-scheduled, clock-ops->set() is never called
from inside ztimer_set(), and the underlying timer is left with an ISR
scheduled to expire at the timer's old time. The intended behavior is
that the clock's lower level timer should always be set to expire at the
time of the clocks head timer.
This patch changes ztimer_set() to call _ztimer_update(), which sets the
lower level timer according to the current list of timers, rather than
setting the timer directly inside of ztimer_set().
Some calls to `coap_build_hdr()` were done with the target buffer for
the header and the source buffer for the token overlapping:
They reuse the buffer that held the request to assemble the response in.
We cannot use `memcpy()` in this case to copy the token into the target
buffer, as source and destination would (fully) overlap.
This commit makes reusing the request buffer for the response a special
case: `memcpy()` is only used to copy the token if source and
destination address of the token differ.
An alternative fix would have been to use `memmove()` unconditionally.
But `memmove()` does not make any assumption about the layout of target
and source buffer, while we know that the token either will already be
at the right position (when reusing the request buffer for the response)
or be in a non-overlapping buffer (when generating a fresh token). This
approach is more efficient than `memmove()`.
newlib (nano) does not support 64 bit types (neither in stdio nor with
corresponding `PRI*64` macros). With GCC 13.2.1 (as shipped in Ubuntu
24.04.1 LTS), this triggers the following compilation error (even with
`ENABLE_DEBUG == 0`):
sys/matstat/matstat.c:57:21: error: expected ')' before 'PRIu64'
57 | DEBUG("Var: (%" PRIu64 " / (%" PRId32 " - 1)) = %" PRIu64 "\n",
| ^~~~~~
This fixes the issue by falling back to printing 32 bit values when
the `PRIu64` macro is not defined. A `!trunc` is appended when the
64 bit exceeds the range of [0:UINT32_MAX].
The CoAP block option gets written twice:
First a 'dummy' value is written by `coap_opt_add_block2()`, later this gets
overwritten by the real option value by coap_block2_finish().
The problem arises when the size of the option changes.
If the option ends up smaller than the dummy, we have garbage bytes after the
real option value, corrupting the packet.
To mitigate this, always write at least one option byte (which will be a 0 byte)
to ensure the dummy data is overwritten.
fixes#20686
The PSA crypto specification states that when creating keys,
the usage flags PSA_KEY_USAGE_SIGN_HASH/PSA_KEY_USAGE_VERIFY_HASH
automatically set the usage flags
PSA_KEY_USAGE_SIGN_MESSAGE/PSA_KEY_USAGE_VERIFY_MESSAGE on the key.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
When psa_status_t is defined inside crypto_types.h, then all
users of psa_status_t are forced to pull the full range of PSA
Crypto API type definitions.
This however means that psa_status_t cannot be used when defining
those PSA Crypto API types, since doing so would create a cycle.
Fix this by moving the PSA status definitions into a separate header
file which additionally is compatible with the PSA Status code API.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
This pulls in several updates for which there is no urgent need, but
also no good reason *not* to do them (especially as they may contain bug
fixes, even critical ones).
