An RST message has no token, so don't reply with a token when sending
RST.
This also adds unit tests to ensure this this exact bug does not sneak
back in.
This adds the client_token shell command that allows to specify the
CoAP Token. This is particularly useful to test extended length Tokens,
as enabled with module `nanocoap_token_ext`.
Co-authored-by: benpicco <benpicco@googlemail.com>
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>
In the related projects, one project name was formatted as bold, while
the others were not. This removes the bold formatting from "Ariel OS",
so that it matches the formatting of the other project names.
There is clearly no reason `cpu.h` should `#include <stdio.h>`.
Also add an export pragma to `cpu_conf.h`, as portable code is
expected to include `cpu.h` (which exists across MCU families in RIOT),
and not `cpu_conf.h` (which only exists for some MCU families).
We cannot use the D0/D1 UART if it is also used for STDIO. However,
the logic did not take into account whether `stdio_uart` was used at
all. This fixes the issue.
Calling `uart_poweroff()` when done with the UART test allows sharing
the underlying hardware e.g. to provide other peripheral interfaces.
One example of this would be the SERCOM3 on the Adafruit Metro M4
Express that is used to provide UART on D1/D0 and SPI on D11/D12/D13.
This changes the behavior of the test script for verifying the `help`
command: It no longer assumes a specific order for the list of commands.
Making the test robust is a bit tricky, as the module
`shell_cmds_default` that is used here may add commands specific to a
set of board. We use `help_json` to get the list of commands actually
provided, so that we know how many rows the command table printed
by `help` need to be parsed.
A minimum set of commands that *must* be present for all boards is
hard-coded in the test script and the actually provided commands are
tested against this. Otherwise e.g. an empty list of commands presented
by `help` and `help_json` would also pass.
Co-authored-by: benpicco <benpicco@googlemail.com>
