sys: Add stdio_coap

[chrysn]

Contribution description

This adds a new stdio through CoAP, roughly following the proposed interface.

It consists of largely independent channels for data out (effectively implemented in the scroll-ring crate), and one for data in (backed by the same kind of ring buffer, but different in its overwrite and blocking behaviors).

The behavior of stdout is that writes never block and happily overwrite the ring buffer -- if data is not obtained fast enough¹, it is lost. Still, a byte counter is kept (overflowing at 32bit), so that not only the presence but also the size of holes in the readout can be determined. Right now, the CoAP handler can only be polled. Future versions will hopefully support observe, in which case the hole indication becomes even more important: The fetch can then report the latest slice, and if the client is interested it can still fetch the missed data if it's around by then.

The behavior of stdin is much easier: Data is POSTed there, stored in a buffer, and POSTs are rejected if there's not enough space in the buffer. (It could be way easier if users of stdin asked for data in chunks and not byte-wise, for then we could save the buffer and deliver data right from the request in there -- but even the shell that has a line-sized buffer pulls data bytewise).

Testing procedure

So far, this only works on applications that do not start gcoap on their own, for (at least the simple version of) the discovery procedure relies on .well-known/core being handled by this module. [edit: More precisely, the stdio_coap module currently makes all other gcoap resources indiscoverable.]

• USEMODULE+=stdio_coap make -C examples/saul all term -- this won't print anything on its own.

• In a separate terminal,

  $ git clone https://gitlab.com/chrysn/scroll-ring
  $ cd coap-scroll-ring-server/tools
  $ python3 -m venv ./venv
  $ source ./venv/bin/activate
  $ pip install -r requirements.txt
  $ ./coap-console 'coap://[ff02::1%tapbr0]'
  

  This uses multicast CoAP to discover the precise address of the device; if there are multiple ones around, it picks the one that responds fastest (so in that case, please give the unicast address).

  The autodiscovery process also finds the precise paths; applications that set up gcoap manually may need that.

Open issues

• How strongly should this pull in gcoap and the network stack? Am I depending on the right modules?

• Right now this registers all own resources in a single Rust CoAP handler that's registered as a Gcoap listener. This is not transparent to the resource enumeration process.

• There is no sensible make term helper -- do we need one? (That'd require passing information at least about the network interface around, like PORT=[fe80::...%tapbr0], which we don't have so far)

• I don't want this merged without a usable security model. I haven't tried going through DTLS -- can our DTLS by now use different keys to gain different levels of authorization?

  My goal here is to make things work with OSCORE. That won't be too tricky as long as we're in a all-resources-from-Rust ecosystem, but there's no clear roadmap for integration with on-Rust CoAP resources.

  A minimal viable solution could be that OSCORE is available only for these resources, discovery is compatible with other resources, and for the time being, this module negotiates the key between build system and device.

Footnotes

1. precisely: if more data is written in one go than fits in the ring buffer, or if data is not fetched frequently enough, or the task reading the ring buffer is doing that too slowly, or there are writers that are so low in their priority that that the rest of the ring buffer gets filled before the low priority task completes ↩

[riot-ci]

Murdock results

❌ FAILED

8596269 Merge branch 'tinydtls-defaults' into stdio-coap

Success	Failures	Total	Runtime
67	0	5731	14m:57s

Artifacts

[chrysn]

With the latest updates, this collaborates well with other gcoap resources, so it can also be used together with the gcoap example. (It doesn't work with the rust-gcoap example: That still usurps the full CoAP tree).

It suffers a bit from the lack of the built-in .well-known/core's block-wise transfer or filtering, but that's a topic of its own. (More concretely, with the default buffer sizes and the gcoap example, only one of two resources is listed, making stdout work but stdin not).

[chrysn]

Now updated to also work over DTLS.

There's no checking of which credentials are used -- stdio is even accepted over unprotected CoAP -- but how we'd establish actual DTLS credentials that are not just "secretPSK" is something that'll need a bit of thought anyway. (Possibly together with considering RFC9202 and a corresponding update to credman). So

$ USEMODULE+='stdio_coap' make -C examples/gcoap_dtls all term CARGO_CHANNEL=nightly