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>
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>
This fixes:
/home/marian.buschsieweke@ml-pa.loc/Repos/software/RIOT/master/tests/sys/shell/tests/01-run.py:86: SyntaxWarning: invalid escape sequence '\e'
Python still assumes `\\<char>` if `\<char>` is not valid, but started
to warn. Chances are good that this will be elevated to an error in
future python releases.
This is no longer a warning but an error.
Also: This is already covered by the static tests via
`dist/tools/feature_resolution/check.sh`, which uses a lot less CPU
time in the CI.
The GPIO IRQ tests had a side-effect that IRQs remained configured after
the test case was complete. This caused stray IRQs to trigger on
SAM0 MCUs and they consequently (and incorrectly) failed the test.
Calling `timer_init()` with unsupported frequencies on some MCUs just
selects the closest possible frequency. But e.g. on SAM0, using an
unsupported frequency will cause `timer_init()` to fail; which probably
is the better option.
However, a failing calling to `timer_init()` results in a test failure.
This is now worked around by using timer_query_freq() to select a
suitable timer frequency that is supported.
