Thread DTLS Success vs Failure

gistfile1.txt

// Demo difference

JoinFail_DTLS.pcapng

JoinSuccess_DTLS.pcapng

Here is my screenshot for that same file with Wireshark 3.2.3

Great! then this may be caused by a too old version on my machine (2.6.10).

I try to update ...

Here is 'Success'

Datagram Transport Layer Security
    DTLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: DTLS 1.2 (0xfefd)
        Epoch: 0
        Sequence Number: 0
        Length: 438
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 426
            Message Sequence: 0
            Fragment Offset: 0
            Fragment Length: 426
            Version: DTLS 1.2 (0xfefd)
            Random: 4bb461a7f5194340ca7a1806b121a8cfdb5c378ab9cbbf38…
                GMT Unix Time: Apr  1, 2010 05:04:39.000000000 EDT
                Random Bytes: f5194340ca7a1806b121a8cfdb5c378ab9cbbf38b111b0e8…
            Session ID Length: 0
            Cookie Length: 0
            Cipher Suites Length: 4
            Cipher Suites (2 suites)
                Cipher Suite: TLS_ECJPAKE_WITH_AES_128_CCM_8 (0xc0ff)
                Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 380
            Extension: signature_algorithms (len=12)
                Type: signature_algorithms (13)
                Length: 12
                Signature Hash Algorithms Length: 10
                Signature Hash Algorithms (5 algorithms)
                    Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: SHA224 ECDSA (0x0303)
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: ecdsa_sha1 (0x0203)
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: ECDSA (3)
            Extension: supported_groups (len=20)
                Type: supported_groups (10)
                Length: 20
                Supported Groups List Length: 18
                Supported Groups (9 groups)
                    Supported Group: secp521r1 (0x0019)
                    Supported Group: secp384r1 (0x0018)
                    Supported Group: secp256r1 (0x0017)
                    Supported Group: secp256k1 (0x0016)
                    Supported Group: brainpoolP256r1 (0x001a)
                    Supported Group: secp224r1 (0x0015)
                    Supported Group: secp224k1 (0x0014)
                    Supported Group: secp192r1 (0x0013)
                    Supported Group: secp192k1 (0x0012)
            Extension: ec_point_formats (len=2)
                Type: ec_point_formats (11)
                Length: 2
                EC point formats Length: 1
                Elliptic curves point formats (1)
                    EC point format: uncompressed (0)
            Extension: Unknown type 256 (len=330)
                Type: Unknown (256)
                Length: 330
                Data: 41045eec00943e591e16f0eeaec1cacc22dffe701dc2d9fe…

And 'Failure` - note the missing 'data' at the end:

Datagram Transport Layer Security
    DTLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: DTLS 1.2 (0xfefd)
        Epoch: 0
        Sequence Number: 0
        Length: 104
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 92
            Message Sequence: 0
            Fragment Offset: 0
            Fragment Length: 92
            Version: DTLS 1.2 (0xfefd)
            Random: 20b689ede8f4ad3e54292b2610550b03803057681db200d3…
                GMT Unix Time: May 24, 1987 01:49:33.000000000 EDT
                Random Bytes: e8f4ad3e54292b2610550b03803057681db200d30aff1262…
            Session ID Length: 0
            Cookie Length: 0
            Cipher Suites Length: 4
            Cipher Suites (2 suites)
                Cipher Suite: TLS_ECJPAKE_WITH_AES_128_CCM_8 (0xc0ff)
                Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 46
            Extension: signature_algorithms (len=12)
                Type: signature_algorithms (13)
                Length: 12
                Signature Hash Algorithms Length: 10
                Signature Hash Algorithms (5 algorithms)
                    Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: SHA224 ECDSA (0x0303)
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: ecdsa_sha1 (0x0203)
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: ECDSA (3)
            Extension: supported_groups (len=20)
                Type: supported_groups (10)
                Length: 20
                Supported Groups List Length: 18
                Supported Groups (9 groups)
                    Supported Group: secp521r1 (0x0019)
                    Supported Group: secp384r1 (0x0018)
                    Supported Group: secp256r1 (0x0017)
                    Supported Group: secp256k1 (0x0016)
                    Supported Group: brainpoolP256r1 (0x001a)
                    Supported Group: secp224r1 (0x0015)
                    Supported Group: secp224k1 (0x0014)
                    Supported Group: secp192r1 (0x0013)
                    Supported Group: secp192k1 (0x0012)
            Extension: ec_point_formats (len=2)
                Type: ec_point_formats (11)
                Length: 2
                EC point formats Length: 1
                Elliptic curves point formats (1)
                    EC point format: uncompressed (0)

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