Dtls handshake failed：Certificate[Reassembly error, protocol DTLS: New fragment overlaps old data (retransmission?)]

[obackup]

my app and device use mbedtls

app.txt

[hassanctech]

Can you please provide some more details like which version of the SDK you are using? We recommend using the most recent tagged release 1.6.0.

For debugging one thing you can do is expand the switch here to check for all of the possible profile types (including the unset one), they are listed here: https://github.com/ARMmbed/mbedtls/blob/448c80727dab5ad99c4ab1c82e4cee1125acafb1/programs/ssl/ssl_client2.c#L712-L716

The switch statement to add the additional cases to is here: https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/master/src/source/Crypto/Dtls_mbedtls.c#L502-L511

Inside the remaining 3 profile types you can put a log statement like:

DLOGD("Detected srtpProfile = <put the name of the profile here>");

[hassanctech]

Also I saw the Wireshark issue, do you think it could be related to this: https://www.wireshark.org/lists/wireshark-bugs/201508/msg00490.html

It looks like that could be an issue with Wireshark. It looks like if there are Server-Client Certificate frames and Client-Server Certificate frames with the same dtls.handshake.message_seq then that would confuse Wireshark and cause that error message you're seeing. You can validate this by examining those values.

[obackup]

@hassanctech I upgrade release 1.6.0

use the demo ， but core

cmake .. -DBUILD_STATIC_LIBS=TRUE -DUSE_OPENSSL=OFF -DUSE_MBEDTLS=ON -DBUILD_LIBSRTP_HOST_PLATFORM=x86_64-unknown-linux-gnu -DBUILD_LIBSRTP_DESTINATION_PLATFORM=arm-unknown-linux-uclibcgnueabi

[obackup]

my chip is Anyka

[disa6302]

Do you have a stack trace we can look at?

[obackup]

[disa6302]

Hmmm. This is not informative. We will need backtrace with thread info to understand what is happening. From this, it is not clear what the source is within the SDK.

[obackup]

the core file only this， cmakelists I have added add_definitions(-g)

[disa6302]

Hmm. This does not make a lot of sense. Doesnt look like all thread info is there, unless your application exists as soon as it starts, which does not seem to be the case based on the previous screenshot. Please run your application under GDB and run bt after that. We did have a libwebsocket update from 1.5.0 to 1.6.0, having said that, our travis CI runs clean on ARM platforms. This could also be platform specific. So my next suggestion would be to build libwebsockets on your platform and run a sample application from libwebsocket to see if it runs clean.

[disa6302]

Closing due to no response. Feel free to reopen if you have an update.