Implemented a check in coap_parse() to verify if TKL value is within valid range as specified by RFC7252. The token length must be within 0-8 range, any other value should be considered as invalid and the packet should produce message format error.
A test case was added to tests-nanocoap.c to verify correct behavior in case of TKL in range and out of range.
Update sys/net/application_layer/nanocoap/nanocoap.c
Prefixed debug message with module name and abbreviations expanded.
Co-authored-by: Martine Lenders <mail@martine-lenders.eu>
Update sys/net/application_layer/nanocoap/nanocoap.c
Prefixed debug message with module name and abbreviations expanded.
Co-authored-by: Martine Lenders <mail@martine-lenders.eu>
This does two things:
The documentation of `luid_get()` is wrong, or at least confusing.
It talks about
> an 8-bit incrementing counter value into the most significant byte
while the implementation does
((uint8_t *)buf)[0] ^= lastused++; // 0 is LSB!
Now it could be argued that the intention was that the ID is supposed
to be used in Big Endian contexts and that was an omission, however
to keep everyone's sanity, let's keep it simple and just state that this
actually changes the LSB.
Also add a `luid_get_lb()` function that does the same, but modifies the
most significant byte - or the last byte if looking at the index.
This can then be used directly by e.g. #13743
ztimer_clock are meant to be chained. At the end of the chaine
there is always a timer device object (periph_rtt/rtc/timer).
Since ZTIMER_MSEC and ZTIMER_USEC can be the scaled/shifted with
respect to the base periph_rtt/rtc/timer it makes sense to chain
other ZTIMER_XXX on top of the base rtc/timer/rtt in order to avoid
chained convertions.
Instead of making a NETTYPE definition dependent on an implementation
module, this change makes it dependent on a pseudo-module for each
specific NETTYPE and makes the respective implementation modules
dependent on it.
This has two advantages:
- one does not need include the whole implementation module to
subscribe to a NETTYPE for testing or to provide an alternative
implementation
- A lot of circular dependencies related to GNRC could be untangled.
E.g. the only reason `gnrc_icmpv6` needs the `gnrc_ipv6` is because it
uses `GNRC_NETTYPE_IPV6` to search for the IPv6 header in an ICMPv6
when demultiplexing an ICMPv6 header.
This change does not resolve these dependencies or include usages where
needed. The only dependency change is the addition of the
pseudo-modules to the implementation modules.
This adds two functions `coap_payload_add()` and `coap_payload_advance()`.
- `coap_payload_add()` will add n bytes to the payload buffer and advance
payload pointer accordingly.
const char hello[] = "Hello CoAP!";
coap_payload_add(pkt, hello, sizeof(hello));
- `coap_payload_advance()` will advance the payload buffer after data
has been added to it.
int len = snprintf(pkt->payload, pkt->payload_len, "%s %s!", "Hello", "CoAP");
coap_payload_advance(pkt, len);
I considered adding an additional parameter to keep track of the total request size
(returned size from coap_opt_finish() incremented by each added payload fragment),
but decided against it to keep consistency with the existing API.
The macros US_PER_MS and friends are assumed to be 32 bit unsigned integers
by users. However, e.g. on AVR a `1000U` is only 16 bit long. Thus, e.g.
`xtimer_usleep(100 * US_PER_MS)` will wrap around and only sleep for ~34ms.
This commit declares them as unsigned long, which is on all currently supported
platforms 32 bit wide.
Enabled by the gnrc_netif_events pseudo module. Using an internal event
loop within the gnrc_netif thread eliminates the risk of lost interrupts
and lets ISR events always be handled before any send/receive requests
from other threads are processed.
The events in the event loop is also a potential hook for MAC layers and
other link layer modules which may need to inject and process events
before any external IPC messages are handled.
Co-Authored-By: Koen Zandberg <koen@bergzand.net>
