Thread DTLS Success vs Failure

gistfile1.txt

// Demo difference

JoinFail_DTLS.pcapng

JoinSuccess_DTLS.pcapng

I had encountered that too. I am not sure if it applies because I do not see the 'noBufs' error... I did attempt to recompile openthread with those #define changes, but trying to get things to build properly was a real challenge. I believe I got it rebuilt, but the result was a hard fault in the mbedtls_internal_aes_encrypt() call.

The result was the same as this person. I have spent too many hours/days on this...

https://devzone.nordicsemi.com/f/nordic-q-a/68793/openthread-logging-enable/282556#282556

I have spent too many hours/days on this...

For me that's too frequently the experience with IoT ...

I have started looking at using the nRF Connect SDK which is built on Zephyr/Openthread. The documentation is all over the place.

Not sure if you have used this or not, but now there are 3 different CoAP implementations, a simple NON/GET only Nordic SDK version, a Zephyr OS implementation, and the embedded Openthread version. The Zephyr one is marked as 'Untable' and looking at it, I don't even think it supports retransmission. I wonder if it is at such an immature state that i am supposed to create my own CoAP layer on top of it? If so, what added value is being provided by any of these SDKs? For OTA firmware updates, I need something like CoAP block transfers, which I don't think openthread CoAP even supports (maybe a new feature added 2 weeks ago in PR 4247). Is it just me being unfamiliar or is this all just a mess?

Is it just me being unfamiliar or is this all just a mess?

In many cases, it is just a mess!

I work now for 6 years with CoAP and DTLS and it seems, that many send just a udp packet an believe, it's CoAP. There are stacks, which even don't process a RST message in the right way. Unfortunately, it's also very time intensive to fix the stacks. I spent now 4 years in Eclipse/Californium and it just right now starts to make really sense (CID-LoadBalancer- Graceful-Restart). But for the clients, it will still take some more time.

I'm not sure, why you want to implement FOTA over CoAP (blockwise). If you mainly want to use "open thread", I would focus on that/their stack. Even, if blockwise is "under develop", it's at least "under develop". And to mention, until that's getting usable, it's not too bad to use a "application aware" blockwise approach (maybe I'm too pragmatical :-) ). Just user request as "coaps://host/download?b=10&l=500" and handle it on your own. In my experience, for FOTA the main issues was, to decided, when to retry blocks and when to restart the complete download (outside the laboratory, of course ;-) ). And also to mention, the performance depends on your bandwidth and rtt. If you have enough bandwidth, using NSTART-2 (up to two pending requests) will speed up a lot, but for blockwise (RFC7959) you may require to check, if it works at all to have two blocks in flight.
Using "open thread" may require, that you extract to "apply the firmware update" part from the transmission in the example. But once separated, you may have more options. And I guess, the "apply update" is already encapsulated ...

Thank you for your insights.

I'm not sure, why you want to implement FOTA over CoAP (blockwise).

I am a little unclear on what you are saying on this insight. If not implementing FOTA over CoAP, what alternative is there? Did you mean as an alternative using 'regular CoAP' with application level block handling or did you mean some other protocol / technology? A lot of these 'other technologies' seem to use UDP. I am not sure UDP is the approach to use for an Openthread / 6LoWPAN network where you want small packets / small MTU.

A lot of these 'other technologies' seem to use UDP.

I guess, this should be TCP?

It depends...

First at all, FOTA makes for me only sense, if it is reliable. Otherwise ...

In some cases, approaches without "OTA" are not too bad, but that depends on the "deployment idea".
e.g. SmartPhones and Bluetooth may be an alternative (not really elegant ... but sometimes easier to handle).
Means the user or service-people downloads an App, and the App applies the contained firmware to the devices.

If that's no way, and OTA is really mandatory, I would first check, what works stable. If blockwise (RFC7959) is under develop, I would either try to engage myself in that development, or, as I wrote, try to do an application aware approach (in the meantime).