nanocoap_sock: implement DTLS socket #18724

benpicco · 2022-10-11T14:21:55Z

Contribution description

This implements DTLS support for NanoCoAP.

When the nanocoap_dtls module is used, the nanocoap_sock_t struct is extended with session information.

All NanoCoAP API functions will automatically handle the new transport type, nanocoap_sock_url_connect() will automatically select the DTLS socket when a coaps:// URL is used.

I'm a bit confused by credman. I now define a CONFIG_NANOCOAP_SOCK_DTLS_TAG by which NanoCoAP can get the credential tag to select the right credential for the connection without having to add new parameter to the API. This is convenient, but it only allows a single credential to be used with NanoCoAP (which is probably fine for the use case, there is only ever a single endpoint).

Testing procedure

The tests/nanocoap_cli application works without modification. I used examples/gcoap_dtls for the server:

log of a nanocoap_cli session

# CoAP request
> ncget coap://[fe80::58b0:8ff:fe67:ad82]/vfs/
/vfs/core
/vfs/fw/
/vfs/main.c

# CoAPS request
> ncget coaps://[fe80::58b0:8ff:fe67:ad82]/vfs/
/vfs/core
/vfs/fw/
/vfs/main.c

# block-wise CoAPS request
> ncget coaps://[fe80::58b0:8ff:fe67:ad82]/vfs/main.c -
/*
 * Copyright (C) 2022 ML!PA Consulting GmbH
 *
 * This file is subject to the terms and conditions of the GNU Lesser
 * General Public License v2.1. See the file LICENSE in the top level
 * directory for more details.
 */

/**
 * @ingroup     examples
 * @{
 *
 * @file
 * @brief       Example application for demonstrating the GCoAP file server
 *
 * @author      Benjamin Valentin <benjamin.valentin@ml-pa.com>
 * @}
 */

#include "kernel_defines.h"
#include "net/gcoap.h"
#include "net/gcoap/fileserver.h"
#include "shell.h"
#include "vfs_default.h"

#define MAIN_QUEUE_SIZE (4)
static msg_t _main_msg_queue[MAIN_QUEUE_SIZE];

/* CoAP resources. Must be sorted by path (ASCII order). */
static const coap_resource_t _resources[] = {
    { "/vfs",
      COAP_GET |
#if IS_USED(MODULE_GCOAP_FILESERVER_PUT)
      COAP_PUT |
#endif
#if IS_USED(MODULE_GCOAP_FILESERVER_DELETE)
      COAP_DELETE |
#endif
      COAP_MATCH_SUBTREE,
      gcoap_fileserver_handler, VFS_DEFAULT_DATA },
};

static gcoap_listener_t _listener = {
    .resources = _resources,
    .resources_len = ARRAY_SIZE(_resources),
};

int main(void)
{
    msg_init_queue(_main_msg_queue, MAIN_QUEUE_SIZE);
    gcoap_register_listener(&_listener);

    char line_buf[SHELL_DEFAULT_BUFSIZE];
    shell_run(NULL, line_buf, SHELL_DEFAULT_BUFSIZE);

    return 0;
}

add fileserver to gcoap_dtls

diff --git a/examples/gcoap/server.c b/examples/gcoap/server.c
index bf2315cd01..ff00d67d53 100644
--- a/examples/gcoap/server.c
+++ b/examples/gcoap/server.c
@@ -29,6 +29,9 @@
 #include "net/utils.h"
 #include "od.h"
 
+#include "net/gcoap/fileserver.h"
+#include "vfs_default.h"
+
 #include "gcoap_example.h"
 
 #define ENABLE_DEBUG 0
@@ -65,6 +68,16 @@ static ssize_t _riot_board_handler(coap_pkt_t* pdu, uint8_t *buf, size_t len, co
 static const coap_resource_t _resources[] = {
     { "/cli/stats", COAP_GET | COAP_PUT, _stats_handler, NULL },
     { "/riot/board", COAP_GET, _riot_board_handler, NULL },
+    { "/vfs",
+      COAP_GET |
+#if IS_USED(MODULE_GCOAP_FILESERVER_PUT)
+      COAP_PUT |
+#endif
+#if IS_USED(MODULE_GCOAP_FILESERVER_DELETE)
+      COAP_DELETE |
+#endif
+      COAP_MATCH_SUBTREE,
+      gcoap_fileserver_handler, VFS_DEFAULT_DATA },
 };
 
 static const char *_link_params[] = {
diff --git a/examples/gcoap_dtls/Makefile b/examples/gcoap_dtls/Makefile
index 078c224838..9241c0f268 100644
--- a/examples/gcoap_dtls/Makefile
+++ b/examples/gcoap_dtls/Makefile
@@ -16,6 +16,9 @@ USEMODULE += netdev_default
 # use GNRC by default
 LWIP ?= 0
 
+USEMODULE += gcoap_fileserver
+USEMODULE += vfs_default
+
 ifeq (0,$(LWIP))
   USEMODULE += auto_init_gnrc_netif
   # Specify the mandatory networking modules

Issues/PRs references

miri64 · 2022-10-11T17:38:47Z

Does it really make sense to add the complexity of DTLS into nanocoap? IMHO, for firmware updates, using OSCORE makes much more sense.

benpicco · 2022-10-11T17:50:13Z

300 lines is hardly that much complexity.
The largest part, nanocoap_sock_dtls_connect() was mostly copy & paste from sock_dodtls' _connect_server() and should be moved to a common place as a follow-up.

NanoCoAP can be used for much more than firmware updates and if you don't enable nanocoap_dtls, there is no added cost.

Also AFAIK we do not have an OSCORE implementation yet.

riot-ci · 2022-10-11T18:46:36Z

Murdock results

✔️ PASSED

4f57628 sys/suit: accept coaps:// URLs

Success	Failures	Total	Runtime
6768	0	6768	14m:02s

Artifacts

Documentation preview

miri64 · 2022-10-11T19:35:58Z

300 lines is hardly that much complexity.

Last time I checked, TinyDTLS had much more than 300 lines of code...

Also AFAIK we do not have an OSCORE implementation yet.

Here you go: https://gitlab.com/oscore/liboscore/-/tree/master/tests/riot-tests :-)

maribu · 2022-10-11T19:45:04Z

I agree with @benpicco. After all, we need to maintain the TinyDTLS package anyway. So we can just as well make use of it where sensible.

The added complexity to nanocoap is quite manageable.

benpicco · 2023-01-13T00:58:00Z

Thank you for the review!

bors merge

bors · 2023-01-13T00:58:03Z