gcoap: multi-transport support

[miri64]

Contribution description

#15549 introduced DTLS support for CoAP, but did not make it possible to select the transport on request. Since switching between CoAP and CoAPS (CoAP-over-DTLS) as client is a valid use case (one might want to e.g. talk to one server over CoAP and to another over CoAPS), this change makes that possible.

This is only a draft for now.

TODOs:

• Testing.
• Also make listeners configurable at run-time.

Testing procedure

Untested for now.

Issues/PRs references

Follow-up on #15549

[miri64]

That was supposed to be a draft PR... Oh well... clicked to quickly.

[miri64]

Sending messages using both the gcoap and gcoap_dtls example seems to work now. I can also observe the respective /cli/stats resource using aiocoap-client.

[miri64]

I added support for listeners now, but I am not 100% happy yet, as /.well-known/core still advertises all resources, regardless if they are available with the used transport or not as the transport type is currently unknown when the resource collection function is called here (there is however now a transport type aware version of that function):

RIOT/sys/net/application_layer/gcoap/gcoap.c

Lines 801 to 802 in 604348a

	plen += gcoap_get_resource_list(pdu->payload, (size_t)pdu->payload_len,
	COAP_FORMAT_LINK);

To fix this, the only thing I can think of at the moment would require to expose the transport type to the request handler (currently the knowledge of those stops in _handle_req which calls the request handlers). I would prefer not to do that, as this would increase the number of parameters (meaning ARM and co would start using the stack instead of the general purpose registers for them) and currently this is the only use-case I can think of where this information could be useful (as usually one knows which resource they registered for which transport).

[miri64]

I know there is draft-amsuess-core-transport-indication, so maybe with that, this becomes a non-issue. But maybe @chrysn can give some insight here.

[miri64]

Heavily edited #16688 (comment) to provide some better context.

[miri64]

Input on the proposed design is welcome.

[chrysn]

Sorry, I'll get to it at earliest in 10 days :-(

[benpicco]

First test with a gcoap_dtls server and both a gcoap_dtls and gcoap client is successful.
Both can access resources on the server via UDP and DTLS.

With this small change

--- a/examples/gcoap/gcoap_cli.c
+++ b/examples/gcoap/gcoap_cli.c
@@ -67,6 +67,9 @@ static ssize_t _riot_board_handler(coap_pkt_t* pdu, uint8_t *buf, size_t len, vo
 /* CoAP resources. Must be sorted by path (ASCII order). */
 static const coap_resource_t _resources[] = {
     { "/cli/stats", COAP_GET | COAP_PUT, _stats_handler, NULL },
+};
+
+static const coap_resource_t _resources_secure[] = {
     { "/riot/board", COAP_GET, _riot_board_handler, NULL },
 };
 
@@ -78,7 +81,16 @@ static const char *_link_params[] = {
 static gcoap_listener_t _listener = {
     &_resources[0],
     ARRAY_SIZE(_resources),
-    GCOAP_SOCKET_TYPE_UNSPEC,
+    GCOAP_SOCKET_TYPE_UNDEF,
+    _encode_link,
+    NULL,
+    NULL
+};
+
+static gcoap_listener_t _listener_secure = {
+    &_resources_secure[0],
+    ARRAY_SIZE(_resources_secure),
+    GCOAP_SOCKET_TYPE_DTLS,
     _encode_link,
     NULL,
     NULL
@@ -491,4 +503,5 @@ void gcoap_cli_init(void)
 #endif
 
     gcoap_register_listener(&_listener);
+    gcoap_register_listener(&_listener_secure);
 }

The /riot/board resource is only available using DTLS while /cli/stats remains accessible using both UDP and DTLS.

It's unfortunately not possible for the gcoap_dtls example to make unencrypted requests, but that's a limitation of the CLI command. Would probably be better if the coap command accepted an URI instead of <addr>[%iface] <port> <path> but this is for another PR.

[miri64]

Sorry, I'll get to it at earliest in 10 days :-(

@chrysn ping?

[miri64]

Ok, I now added the transport filter for .well-known/core, but I think it is a bit hacky: For the _well_known_core_handler a dynamic context object is now added (the gcoap_socket_t of the current connection), while the context behavior for all other resources stays static and is taken from the coap_resource_t struct's context pointer, so as it was before.

[benpicco]

I now added the transport filter for .well-known/core

Why does that need special handling?

[miri64]

I now added the transport filter for .well-known/core

Why does that need special handling?

See #16688 (comment)

[benpicco]

I wouldn't find it too bad if all handlers could know whether they've been accessed via DTLS or plain UDP.
That way a handler could return different results based on the transport.

[benpicco]

Another option would be to just duplicate the endpoint

/* Internal variables */
const coap_resource_t _default_resources[] = {
    { "/.well-known/core", COAP_GET, _well_known_core_handler, GCOAP_SOCKET_TYPE_UDP },
};

const coap_resource_t _default_secure_resources[] = {
    { "/.well-known/core", COAP_GET, _well_known_core_handler, GCOAP_SOCKET_TYPE_DTLS },
};

static gcoap_listener_t _default_listener = {
    &_default_resources[0],
    ARRAY_SIZE(_default_resources),
    GCOAP_SOCKET_TYPE_UDP,
    NULL,
    NULL,
    _request_matcher_default
};

static gcoap_listener_t _default_secure_listener = {
    &_default_resources[0],
    ARRAY_SIZE(_default_secure_resources),
    GCOAP_SOCKET_TYPE_DTLS,
    NULL,
    NULL,
    _request_matcher_default
};

[miri64]

Another option would be to just duplicate the endpoint

👎 While it looks simple now, just imagine additional transports coming in the future (TCP, TCP+TLS, SLIPMUX, BLE, QUIC ...). This simply does not scale.

[miri64]

I wouldn't find it too bad if all handlers could know whether they've been accessed via DTLS or plain UDP.
That way a handler could return different results based on the transport.

Mh with regards to e.g. block-wise and TCP transports, this could indeed make sense...

[miri64]

Do you think we can get this into the 2021.10 release?

No time to get it out of WIP ATM + I to me it make sense to wait at least until #16855 got somewhat started so I can put the new struct member of coap_pkt_t directly into gcoap_pkt_t, so we don't have to endure a deprecation round for that as well. So I would tend to say bump (even though it is still some time for hard feature freeze).

[benpicco]

is there anything that can be done to help with this PR?

[miri64]

is there anything that can be done to help with this PR?

As stated in #16688 (comment), we should work on #16855. I started some of that work in #17168.

[miri64]

is there anything that can be done to help with this PR?

Other than that, some testing application would be great!

[benpicco]

Want to give this a rebase? Feel free to squash while you're at it.

[miri64]

Squashed first to make rebase less of a pain.

[miri64]

Rebased and it at least still compiles. However, with the recent rework in #17471, the gcoap_dtls now does not seem to work in current master (the client sends out unencrypted CoAP messages), and as such I was unable to test if my rebase worked. I was very careful, so I don't think I broke anything. IMHO, once we can test it (i.e. the error in allegedly introduced in #17471 is fixed), this is ready to merge: Sure we can wait until we reworked and split nanocoap and gcoap, but lets not be perfect the enemy of good enough ;-).

[miri64]

Ok, I think I was just tired yesterday. I tested it again today, and now it works

RIOT native interrupts/signals initialized.
RIOT native board initialized.
RIOT native hardware initialization complete.

NETOPT_RX_END_IRQ not implemented by driver
main(): This is RIOT! (Version: 2022.04-devel-577-g287bfd-gcoap/enh/multitransport)
gcoap example app
All up, running the shell now
> ifconfig
ifconfig
Iface  7  HWaddr: DA:27:1D:A8:64:24 
          L2-PDU:1500  MTU:1500  HL:64  Source address length: 6
          Link type: wired
          inet6 addr: fe80::d827:1dff:fea8:6424  scope: link  VAL
          inet6 group: ff02::1
          inet6 group: ff02::1:ffa8:6424
          
> coap info
coap info
CoAP server is listening on port 5684
Connection secured with DTLS
Free DTLS session slots: 1/1
 CLI requests sent: 0
CoAP open requests: 0
Configured Proxy: None

RIOT native interrupts/signals initialized.
RIOT native board initialized.
RIOT native hardware initialization complete.

NETOPT_RX_END_IRQ not implemented by driver
main(): This is RIOT! (Version: 2022.04-devel-577-g287bfd-gcoap/enh/multitransport)
gcoap example app
All up, running the shell now
> coap get fe80::d827:1dff:fea8:6424 5684 /.well-known/core
coap get fe80::d827:1dff:fea8:6424 5684 /.well-known/core
gcoap_cli: sending msg ID 61972, 23 bytes
> gcoap: response Success, code 2.05, 46 bytes
</cli/stats>;ct=0;rt="count";obs,</riot/board>

[miri64]

🎉