CoAP with DTLS example?

Help
#1

Hi everyone,

I was wondering, is there any working example for DTLS + CoAP? I saw some WIP by janosbrodbeck - here and here, but nothing in the main branch.

Is it possible to somehow integrate gcoap or just nanocoap on top of the dtls-socks example?

Any help would be greatly appreciated.

Best, Emil

PS. I’m new to embedded stuff, sorry if my questions are silly.

1 Like
#2

Ping @janosbrodbeck :wink:

#3

Hi sssemil,

there is currently no example for CoAP with DTLS in upstream RIOT. As far as I know, my dev branch you posted is currently the only working gcoap-DTLS branch.

In my branch the gcoap example is already adapted, so you only have to set GCOAP_ENABLE_DTLS to 1. It should work fine so far (if not please inform me about issues), but it is not 100% ready yet. I hope to update the related pull request very soon. Primarily I am still missing the access to the DTLS epoch to complete it. Nevertheless: coap messaging and observable resources should work.

If you just want to use nanocoap: There is an example for using the nanocoap_server . But it seems that it is just a very basic coap server. You would need to integrate dtls here. Should be fairly easy if session management is not taken into account.

If you have any problems or questions just ask, I will do my best to help you :wink:

1 Like
#4

Hi Janos,

thanks! Everything works :slight_smile: Coap messaging is all I need.

Best, Emil

#5

Just one warning: On boards it currently crashes. The gcoap and main stack are too small. Have not yet adjusted the example/gcoap makefile regarding that.

main stack can be adjusted with CFLAGS += -DTHREAD_STACKSIZE_MAIN=xx
gcoap stack with: CFLAGS += -DGCOAP_STACK_SIZE=xx

For the main stack 3*THREAD_STACKSIZE_DEFAULT should be sufficient.

EDIT: stack size changes are now pushed.

#6

Thanks for the heads up! I’m using it on native only for now. My end-goal is to compare the overhead of CoAP+DTLS vs. CoAP+OSCORE for my thesis, and I will use this to create a benchmark.

1 Like
#7

Hi again @janosbrodbeck,

I’ve been trying to make a simple client example myself to work, and I’ve been facing an issue. Do you know by chance what the problem could be? It looks like the client is just closing the connection, but I’m not sure if that’s the case. Also, what’s different to your run is that Client Hello is just a generic DTLS without version, while in your case it’s DTLSv1.2 packet right away.

Here’s my (messy) code (pretty much what gcoap_cli.c has, and _resp_handler function is the exact copy) - https://gist.github.com/sssemil/1bb232acfbf40286aded21de7ca248f3

Wireshark packets:

No Time Src Dest Protocol Len Info
6 214.120254750 :: fe80::200:ff:fe00:ab DTLS 129 Client Hello
8 216.724920517 fe80::200:ff:fe00:bc fe80::200:ff:fe00:ab DTLSv1.2 77 Alert (Level: Fatal, Description: Close Notify)
9 216.725158117 fe80::200:ff:fe00:bc fe80::200:ff:fe00:ab DTLSv1.2 129 Client Hello
12 216.726022804 fe80::200:ff:fe00:ab fe80::200:ff:fe00:bc DTLSv1.2 106 Hello Verify Request
14 218.120220402 fe80::200:ff:fe00:bc fe80::200:ff:fe00:ab DTLSv1.2 77 Alert (Level: Fatal, Description: Close Notify)

Thanks, Emil

#8

Also, the code I provided worked just fine on DTLS-less gcoap branch, hence my confusion :slight_smile:

#9

Hi sssemil,

I cannot reproduce it. Even the wireshark protocol info was correct for me.

gcoap_output
gcoap_output761×373 38 KB

Did you run the original gcoap example as server? I’ve only changed the server address in the code. I’ve created the tap interfaces with the tapsetup tool in RIOT/dist/tools/tapsetup.

The only difference which comes in my mind is that you used my branch from one week ago, but there was no change in gcoap itself just an parameter addition to the dtls session management module.

Can you run it again and compile server and client with CONFIG_DTLS_DEBUG=1? This activates the debug logs in tinydtls. Cancelling after the hello verify request always sounds like PEER NOT FOUND in tinydtls.

#10

Now I understand it. The first packet, with protocol “DTLS”, was your client sending a packet to itself. That is currently not possible. You need a dedicated other node. But I don’t know why it only shows “DTLS”.

#11

Yes, I used your gcoap example as the server. I uploaded verything on gh, here’s my start-up script - https://github.com/sssemil/riot_app/blob/master/start_coap_dtls_client.sh. I also used RIOT/dist/tools/tapsetup to setup the network. Here are the logs with DTLS debug on gcoap example:https://gist.github.com/sssemil/f2f2a9ff0cdd5ea60bf7fb9f6f43a79c

UPD: I found the issue. I didn’t have this in my make file:

# increase main stack
CFLAGS += -DTHREAD_STACKSIZE_MAIN=2*THREAD_STACKSIZE_DEFAULT

Thanks for helping :slight_smile:

#12

What are you trying to connect to? Another RIOT-OS, or ??? I ask because Openssl DTLS is a bit tricky to use correctly.

#13

Thanks for the heads up! I’m using it on native only for now. My end-goal is to compare the overhead of CoAP+DTLS vs. CoAP+OSCORE for my thesis, and I will use this to create a benchmark.

If you allow me a shameless plug hidden in a suggestion: In https://arxiv.org/abs/2001.08023, one outlook point was that DTLS 1.3 could be key to DTLS standing any chance.

#14

I’m connecting two RIOT-OS native instances.

#15

Great paper, thanks! Do you know if there’s any usable implementation of DTLSv1.3 (maybe based on the latest draft)?

#16

I’m unaware of any. (Honestly, until November 2020 it was hard to get a hold of a usable DTLS 1.2 implementation in Python, so my hopes are not too high). You may want to look at what WolfSSL have, though, they’re usually good.

1 Like