Thread DTLS Success vs Failure

gistfile1.txt

// Demo difference

JoinFail_DTLS.pcapng

JoinSuccess_DTLS.pcapng

Extension: Unknown type 256 (len=330)
                Type: Unknown (256)
                Length: 330
                Data: 41045eec00943e591e16f0eeaec1cacc22dffe701dc2d9fe…

At least IANA doesn't list that extension. I'm not sure, if therefore a "special dtls library is required".

So, the "openthread" client works, the none "openthread" not, right?

If so, I guess, asking with that "hello extension number" 256 the right experts in openthread my bring the light. I'm not too optimistic, that other dtls-libraries will do it as well.

What was your reason, not to use the openthread coap/dtls client?

The successful one, which includes that 'unknown' data is the one that works. When the nordic 'nrf_crypto' library is enabled then that data is missing and the handshake fails.

I am not familiar with the contents of a DTLS handshake. Could those 330 bytes be part of a key?

I first started my codebase using the 'examples/thread/cli' which works and generates the correct handshake. Next, I wanted to add the OTA Thread DFU feature, which allows background firmware updates over thread. Nordic provides that in 'examples/thread/dfu/client'. The SDK provided DFU code uses their own CoAP stack to register CoAP endpoints, so I had to switch my application to use that stack. Otherwise two different stacks are binding to that same CoAP UDP ports.

However, regardless of the changes I made at the application level for my application level messaging, I believe internally to openthread library, it still uses its own openthread coap/dtls regardless. I think the difference between the two is that the 'nrf_crypto' libraries tries to hardware accelerate stuff.

A HELLO_EXTENSION could be everything, a parameter choice for the server to select and maybe also a key, but that's usually not in the CLIENT_HELLO (at least not for DTLS 1.2, for 1.3 that's different.) AFAIK, if a HELLO_EXTENSION should be "interoperable", then it requires a IANA registration, and that's missing.

I think the difference between the two is that the 'nrf_crypto' libraries tries to hardware accelerate stuff.

Maybe, and I guess, 'nrf_crypto' libraries doesn't come with support for that HELLO_EXTENSION 256 ... ;-(.

I filed a report on openthread...maybe they can help focus this issue and explain the mystery extension.

In my experience, that group is responsive and there are the openthread experts. :-)

In my experience, that group is responsive and there are the openthread experts. :-)

Hopefully they will not refer me back to Nordic. Anyway, thanks for taking a look, I do appreciate your time.

Just an FYI for you ... From the Thread specification - 'The value being used for ecjpake_key_kp_pair is 256.' That answers the mystery extension question.

I found also a related one from last summer

Nordic devices cannot join with external commissioner

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).