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
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_DEFAULTshould be sufficient.
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.
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.
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.
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”.
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.
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.