Thread SDK / OTA bug

[krbvroc1]

I merged in some of my code to the examples/thread/dfu/client in the v4.1.0 SDK for Thread and Zigbee. After getting OTA DFU working, I moved onto some commissioning related stuff. I spent several days trying to figure out why I could not join my 52840DK to the Border Router. No matter what I did, I would get 'Join failed [Security]'. Wireshark shows failure in the DTLS handshake. I thought I had done something wrong, but turns out something in Nordic code has broken openthread.

For me this was very easy to reproduce. Simply take the examples/thread/dfu/client, and modify main.c to change ' .autocommissioning = true,' to ' .autocommissioning = false, .autostart_disable = true' so you can join a thread network rather than using built in hardcoded credentials.

Program the device (being sure to follow nordic instructions for mbr, bootloader, and this app), connect using the UART, and try to join a border router that is ready to accept the device.

> ifconfig up
Done
> joiner start TEST1234
Done
> Join failed [Security]

On a packet sniffer note that DTLS handshake fails.

I saw some other UNANSWERED devzone messages with a theme of nrf crypto breaking openthread DTLS. Not sure if that related, but one big difference between the thread/dfu/client and thread/cli example is the inclusion of nrf crypto related libraries. Also the thread/dfu/bootloader is part of the picture.

I am completely stuck at this point.

[Jørgen Holmefjord]

Hi,

I will try to reproduce this behavior, but just wanted to ask first if you have reproduced this with any other examples (for instance the CLI example), or if it only happens with the DFU client examples?

Best regards,
Jørgen

[Jørgen Holmefjord]

I have recreated the problem on my setup, and have created an internal report of the issue.

Will get back to you as soon as I have some more information to share.

[krbvroc1]

In your experience, how long before I should expect some workaround or fix? As I mentioned in one of my responses, because I had to rewrite all my CoAP interface code to use the IoT CoAP stack rather than the Openthread CoAP stack, I am left in a situation where I cannot proceed with development of the two feature I am currently working on... Thread DFU updates and Device commissioning.

[krbvroc1]

I have setup a border router with some debugging information. I am finding the following error message on the border router when commissioning fails. I am 99% sure it is somehow related to nrf_security being initialized / used. Maybe this helps whomever is researching it.

SECURITY: SSL - None of the common ciphersuites is usable (eg, no suitable certificate, see debug messages)

[Achim Kraus]

Such failures are mostly caused by not proper setup/configured dtls-libraries. Maybe you need to enable the right cipher suites (and disable the not supported ones in order to get a small hello_client),

If you're able to capture a successful handshake and the failing one, I may check, what I see.

I'm not sure, if this short instructions work in your case

Logs and IP Capturing ‐ How To Provide The Right Information

but at least, it's point to start.

[krbvroc1]

The DTLS Client Hello is pretty close to identical. The one difference is that in the successful handshake, according to Wireshark, the successful handshake contains an extra 334 bytes at the end. Wireshark labels that as an Extension of Unknown type 256 that contains 330 bytes. The failed example is missing that part of the Client Hello. Other than that, everything else appears identical.

[Achim Kraus]

"pretty close" or "identical"?

The success of the handshake depends not only on the list of cipher suites, for some there are additional parameters, which may cause the "incompatibility".

Just if you want, you may zip the capture(s) of two client_hellos and provide this somehow to me. On way to do that would be to create an issue in "Eclipse/Californium"'s github and "drag and drop" the zipped capture there. Please ensure, you only provide the two client_hellos and not other traffic!

[Achim Kraus]

Just, if providing the captures it too complex, you may also get some textual copies by selecting a item an use the context menu for "copy -> All visible selected tree items".

Cipher Suites (1 suite)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (0xc0ae)

Extension: supported_groups (len=6)
    Type: supported_groups (10)
    Length: 6
    Supported Groups List Length: 4
    Supported Groups (2 groups)
        Supported Group: secp256r1 (0x0017)
        Supported Group: secp384r1 (0x0018)

Extension: signature_algorithms (len=6)
    Type: signature_algorithms (13)
    Length: 6
    Signature Hash Algorithms Length: 4
    Signature Hash Algorithms (2 algorithms)
        Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
            Signature Hash Algorithm Hash: SHA256 (4)
            Signature Hash Algorithm Signature: ECDSA (3)
        Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
            Signature Hash Algorithm Hash: SHA256 (4)
            Signature Hash Algorithm Signature: RSA (1)

That's an example with the cipher suite list (1)

though it uses ecdsa/ecdhe with the supported groups,

though it uses ecdsa with the supported signature algorithms,

[krbvroc1]

Here you go...

JoinFail_DTLS.pcapng

JoinSuccess_DTLS.pcapng