This changes the API of nanocoap with the goal to reduce the expose of
UDP specifics in the API. The plan is to eventually support transports
such as CoAP over TCP and CoAP over WebSocket directly in nanocoap
while sharing most of the code, as e.g. the CoAP Option processing
remains identical. Specifically, the plan is to unlock a transport with
modules and introduce overhead for dispatching to specific transport
only when multiple transports are actually in use.
Support for OSCORE directly in nanocoap is probably not sensible, as
the serialization is very much unlike the other transports. A unified
CoAP API for multiple transports including OSCORE is probably best
implemented on top. But when limited to the boring set of CoAP
transports, we probably can support them well with nanocoap with less
overhead.
Breaking API Changes:
=====================
- `coap_parse()` now returns `ssize_t` instead of `int`
- This function is not really user facing, so the impact should
be limited
- This is useful for stream transports where the buffer may
contain data of more than one packet. The return value contains
the number of bytes actually consumed, which will match the
buffer size for non-stream transports.
API Changes:
============
- `coap_pkt_t` now contains a `uint8_t *buf` pointer instead of a
`coap_hdr_t *hdr` pointer to the beginning of the buffer
- This will also work when the buffer is used by non-UDP
transports
- A deprecated `coap_udp_hdr_t *hdr` has been crammed into
an unnamed `union` with `uint8_t *buf`. For architectures
where pointers have the same memory layout regardless of type
(e.g. all of the supported ones), this will make `hdr` an
alias for `buf`.
- The alias will only be provided if no transport besides UDP is
used in nanocoap. So existing apps will continue to work, new
apps that want to support other transports need to move to
adapt.
- `coap_hdr_t` has been renamed to `coap_udp_hdr_t`
- A deprecated alias was created for deprecation
- `coap_hdr*()` functions have been deprecated
- Equivalent `coap_pkt*()` functions have been created that work
on `coap_pkt_t *` instead of `coap_hdr_t *`
- If non-UDP transports are used, the deprecated `coap_hdr*()`
will probably not be exposed to avoid footguns.
- `coap_build_hdr()` has been renamed to `coap_build_udp_hdr()` and
that works on an `uint8_t *` buffer with a given length, rather than
on a `coap_hdr_t *` with a *figers crossed* length
- a deprecated `coap_build_hdr()` function was added that calls
to `coap_build_udp_hdr()` and has the same signature, so that
users have time to update
- The responsibility for handling matching CoAP No-Response Options
has been split:
- `coap_build_reply()` only needs to report this and return
`-ECANCLED`
- `coap_handle_req()` does generate the empty ACK is needed.
==> As a result, writing CoAP request handlers correctly becomes a
lost easier. Correct error handling to be present is now
sufficient for correct handling of No-Response options.
==> This change is backward compatible with existing code.
- The API doc has been cleaned up and straightened
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
For in-band signalling that a content format is not valid / present,
the magic number `COAP_FORMAT_NONE` was introduced and the type
`uint16_t` was used. Some APIs however used different in-band signalling
values and types:
- coap_reply_simple(): No signal available, `unsigned int`
- coap_build_reply_header(): negative values, `int`
(Using `int` would prevent using larger content format numbers on
8-bit and 16-bit archs, where `int` and `int16_t` have the same
range.)
This changes the behavior to consistently use `COAP_FORMAT_NONE` as
"no content format" signal and `uint16_t` as type.
There is an `typdef void sock_udp_ep_t` hack in `nanocoap.h` that tries
allow using parts of nanocoap without a RIOT network stack.
There is a similar hack to allow it to be used without RIOT at all. This
has been used in the early days during development on Linux directly.
This however has not been tested and left bit rotting.
Both hacks are remove and nanocoap now just depends on sock/udp.h.
In a future cleanup, the CoAP packet parsing and building code of
nanocoap can be separated from the part that does the transmission and
reception of UDP packets. That way, using nanocoap's packet parsing and
building will again be available without using a network stack.
Until then, let's drop the hacks and just depend on a network stack.
This adds the new `nanocoap_server_observe` module that implements the
server side of the CoAP Observe option. It does require cooperation
from the resource handler to work, though.
Co-Authored-By: mguetschow <mikolai.guetschow@tu-dresden.de>
Co-authored-by: benpicco <benpicco@googlemail.com>
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>
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.
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()`.
19487: nanocoap: implement extended tokens (RFC 8974) r=benpicco a=benpicco
19808: boards: add ESP32-S3-USB-OTG support r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the [ESP32-S3-USB-OTG](https://docs.espressif.com/projects/espressif-esp-dev-kits/en/latest/esp32s3/esp32-s3-usb-otg/user_guide.html) board.
The SD card can only be used in SPI mode at the moment. As soon as PR #19786 is merged, the SD/MMC support can be enabled and the SD card can then be used in SD mode with 4-bit data bus width.
The display uses uses the ST7789 driver IC that is compatible with the ST7735. For that purpose the ST7735 driver is extended by a pseudomodule definition `st7789` for the ST7789 which is enabled by the board and enables automatically the `st7789` (e57c48a33ee2a869c15603788e5306ba066f91cf). Vise versa, board's `Makefile.dep` enables automatically the `st7789` pseudomodule if the `st7735` is used. The pseudomodule `st7789` is just used to increase the upper limit for supported lines. This change is also part of PR #19807.
~The PR includes a very small documentation fix for ESP32-S3-DevKit board that was noticed during the development of this board definition (1155b6ac1b8efa39d8a0bd7150e602095159fdc1).~
### Testing procedure
The board has been tested with all basic tests for supported hardware including `tests/driver/st3375`:
- [x] tests/drivers/st3375
- [x] tests/periph/gpio
- [x] tests/periph/pwm
- [x] tests/periph/spi
- [x] tests/periph/uart
- [x] tests/sys/usbus_cdc_ecm
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
