Hi,
Please i need steps to implement and testing DTLS on contiki-ng with native mode and with cooja....
thanks a lot

In the master branch (53a0d97), DTLS server allows to receive the over-large packets. By sending over-large packets, the stack will overflow and attacker can arrive to the address he want.

#0 is_record (msglen=8484, msg=0x6196d9 <error: Cannot access memory at address 0x6196d9>)
at dtls.c:361
#1 dtls_handle_message (ctx=0x61b00001f180, session=0x7fffffffdf60,
msg=0x6196d9 <error: Cannot access memory at address 0x6196d9>, msglen=8484) at dtls.c:3779
#2 0x0000000000402165 in dtls_handle_read (ctx=0x61b00001f180) at dtls-server.c:183
#3 0x0000000000402ee5 in main (argc=1, argv=0x7fffffffe408) at dtls-server.c:351

If packets is over large, the variable "rlen" in is_record function will be very large but it still lower than packet length and "rlen" not be set to "0" , so when program carries to the dtls.c:3916 , "msg += rlen", the value of "msg "is larger ,so the stack overflows, and the BUG is triggered.

In my test case, the packet's length is 28073, and the "rlen" will be 19545, "rlen" is lower than 28073,so it won't set to be "0", when pointer "msg" adds the "rlen" , huge value of "msg" causes the stack overflow.

Currently the loglevel has to be hardcoded although the help message indicates a -v option.

In the last months a couple of issues and bugs have been solved in the current "develop" branch of Eclipse/tinyDTLS. Additionally I added experimental client support for the upcoming RFC9146. So it may be worth, to start a "develop" branch for contiki-ng as well.

I was trying to send CKE with some additional data[21000] which is obviously very large. Fragmentation at IP layer doesnt work properly and CKE is never exchanged.

Do you have a code with supported fragmentation in tinyDTLS.

In the master branch 53a0d97, an assertion failure in check_certificate_request() causes the server to exit unexpectedly and denial of service.

Here is the backtrace of failure:
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
1 0x00007ffff7df2859 in __GI_abort () at abort.c:79
2 0x00007ffff7df2729 in __assert_fail_base (fmt=0x7ffff7f88588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x422e9b "is_tls_ecdhe_ecdsa_with_aes_128_ccm_8(peer->handshake_params->cipher)",
file=0x421b0d "dtls.c", line=2834, function=) at assert.c:92
3 0x00007ffff7e03f36 in __GI___assert_fail (assertion=0x422e9b "is_tls_ecdhe_ecdsa_with_aes_128_ccm_8(peer->handshake_params->cipher)", file=0x421b0d "dtls.c", line=2854,
function=0x422ee1 "int check_certificate_request(dtls_context_t *, dtls_peer_t *, uint8 *, size_t)") at assert.c:101
4 0x000000000041184f in check_certificate_request (ctx=, peer=0x44af40, data=0x44b5a8 "\r", data_length=78) at dtls.c:2854
5 handle_handshake_msg (ctx=0x44a480, peer=, session=0x7fffffffe400, role=DTLS_SERVER, state=DTLS_STATE_WAIT_SERVERHELLODONE, data=0x44b5a8 "\r", data_length=78) at dtls.c:3266
6 0x0000000000406a84 in handle_handshake (ctx=0x44a480, peer=0x44af40, session=0x7fffffffe400, role=DTLS_SERVER, state=DTLS_STATE_CLOSING, data=0x42937d <dtls_handle_read.buf+13> "\f",
data_length=) at dtls.c:3547
7 dtls_handle_message (ctx=0x44a480, session=, msg=, msglen=15637) at dtls.c:3884
8 0x0000000000402ce8 in dtls_handle_read (ctx=0x44a480) at dtls-server.c:187
9 main (argc=, argv=) at dtls-server.c:355

dtls-client concatenates the key from the key file (using -k) with a newline.

Until TinyDTLS , an infinite loop bug had been found during handling ClientHello handshake message. This bug allows remote attackers to cause a denial of service via sending a malformed ClientHello handshake message with an odd cipher suites' length, which triggers an infinite loop until consuming all resources and buffer over-read to disclose sensitive information.

Suppose you have a malicious ClientHello message with the following values for the mentioned fields:

1. Cipher Suites Length is an odd number like 3 (this is a malicious number)
2. Two Suites whose length is 4 bytes
3. Extension Length whose length is not zero like 26 bytes

After handling this message in the normal handling way as follows, we enter into the function dtls_update_parameters() at the dtls.c:1024.

1. 0x4e2b02 in dtls_update_parameters /home/etinydtls/dtls.c:1024:22
2. 0x4e2b02 in handle_handshake_msg /home/etinydtls/dtls.c:3403:11
3. 0x4cb1ce in handle_handshake /home/etinydtls/dtls.c:3493:14
4. 0x4cb1ce in dtls_handle_message /home/etinydtls/dtls.c:3881:13
5. 0x4c4efc in dtls_handle_read /home/etinydtls/tests/dtls-server.c:177:10
6. 0x4c4efc in main /home/etinydtls/tests/dtls-server.c:352:2
7. 0x7fb176ab10b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
8. 0x41c45d in _start (/home/etinydtls/tests/dtls-server+0x41c45d)

When coming to dtls.c:1024 in the function dtls_update_parameters(), variable i is assigned to an int number, which stands for all cipher suites' length 3 in this message. After that, the condition data_length < i + sizeof(uint16) cannot refuse this packet cannot exclude this packet, as 4+26 < 3+2 is not satisfied. Hence, we come to the loop of confirming suites at the dtls.c:1024, where i is decreased by 2 each loop. The ending loop condition includes (i == 0), while the initial value of i is 3 thereby this condition will not be satisfied. Unfortunately, dtls server loops forever with unreachable exit conditions.

Hello,
please i need to implement an encryption algorithm like AES to analyse the flow between client udp and server udp, so hwo to modify udp-cleint.c and udp-server.c to exchange message encrypted by client and decrypted by server.
best regards

In the master branch (until current 53a0d97), an illegal buffer over-read in the dtls_sha256_update function of TinyDTLS has been found. This bug allows remote attackers to cause a denial of service (crash) and possibly read sensitive information via sending a malformed packet with an over-large fragment length field, due to servers incorrectly handling malformed packets.

Here is the bug trace:
Program received signal SIGSEGV, Segmentation fault.
0x000055555556134e in dtls_sha256_transform (context=context@entry=0x7fffffffe090, data=0x55555558c002, data@entry=0x55555558bffa) at sha2/sha2.c:494
494 REVERSE32(*data++,W256[j]);
(gdb) bt
#0 0x000055555556134e in dtls_sha256_transform (context=context@entry=0x7fffffffe090, data=0x55555558c002, data@entry=0x55555558bffa) at sha2/sha2.c:494
1 0x000055555556157f in dtls_sha256_update (len=4849685, data=0x55555558bffa "", context=0x7fffffffe090) at sha2/sha2.c:587
2 dtls_sha256_update (context=0x7fffffffe090, data=, len=) at sha2/sha2.c:553
3 0x000055555555ea72 in dtls_hash_update (len=, input=, ctx=) at dtls-hmac.h:39
4 dtls_hmac_update (ctx=, input=, ilen=) at dtls-hmac.c:60
5 0x00007fffffffe3c0 in ?? ()
6 0x0000000000000023 in ?? ()
7 0x0000000000000000 in ?? ()

Here are captured packets by Wireshark. We could clearly find the reason for causing this bug. After receiving a malformed packet, whose value in the Length field is larger than the real one, servers try to read more bytes than the real one, which leads to disclosing sensitive information and denial of service.

In testing TinyDTLS, we found that the server (launched by running ./tests/dtls-server) can be crashed by applying certain malformed inputs. We traced this to bugs in the code. Does it present a security risk to post the inputs here, so people can fix the bugs?

We can also fix the bugs ourselves, the concern is that we are not network specialists, so we might break TinyDTLS inadvertently. Thanks!

Non-conformance bug

The Contiki-NG TinyDTLS client proceeds in a handshake after receiving two distinct CertificateRequest messages. A similar issue was posted for eclipse's TinyDTLS. Below is the capture of the non-conforming behavior taken on my machine. Note that the CertificateRequest messages are distinct (their message_seq differs). Hence the client should have rejected the second CertificateRequest and not proceeded with the handshake.

Steps to Reproduce
I attached files necessary for reproduction using DTLS-Fuzzer, a Java-based tool for testing DTLS libraries. Also included in the archive is a capture of the interaction show above. DTLS-Fuzzer requires the JDK for Java 8. On Ubuntu, this can be installed by running:
sudo apt-get install openjdk-8-jdk

Unpack the archive, cd to resulting folder and run bash reproduce.sh, while running an instance of Wireshark on the side. The reproduction script will:

• setup Contiki-NG TinyDTLS and DTLS-Fuzzer
• launch the TinyDTLS client using the 'tests/dtls-client utility;
• launch DTLS-Fuzzer to execute the input sequence 'test_sequence' which exposes the bug.

Thanks!

reproduction.tar.gz

Hello

I am currently implementing the tinyDTLS in 6lbr with the Sensortag CC2650. Has anyone had success with doing this?

How to compiling and configuring tinyDTLS in 6lbr and Sensortag CC2650?

How to flash the tinyDTLS in Sensortag CC2650?

I am really confused about where to start.

Thank you!

Hi,

For my project i need to create additional service with the following requirements:

DTLS Handshaking
UDP port 2100 is used for DTLS handshaking and streaming. Only DTLS mode version 1.2 with Pre-Shared Key (PSK) Key exchange method with TLS_PSK_WITH_AES_128_GCM_SHA256 set as Cipher Suite is supported.

I want to know if i can start with your project to create this service.

Thanks,
Marius.

How can we report a discovered security vulnerability? The security policy on GitHub is empty, so we do not have a contact to report a security vulnerability.

Best regards,
Nurullah Erinola

In the master branch 53a0d97, DTLS servers allow remote attackers to reused the same epoch number within two times the TCP maximum segment lifetime, which is prohibited in RFC6347. This vulnerability allows remote attackers to obtain sensitive application data of connected clients.

This bug could be reproduced by sending packets with the same epoch number to complete two times handshakes. The following shows the packets captured by Wireshark, which display the two times of handshakes completed.

Non-conformance Bug affecting usability of the library

A similar issue was reported for eclipse's TinyDTLS implementation.

Contiki-NG TinyDTLS client generates an unwarranted decrypt_error alert upon receiving an unencrypted HelloVerifyRequest with epoch 1. Similarly, the server generates a decrypt_error upon receiving a CKE with epoch 1. Below captures for the two behaviors are shown.

Upon investigating this matter, we found that by terminating the initial handshake on receiving messages with epoch 1, TinyDTLS no longer ensures reliability of the handshake protocol. If the client/server receive Finished (epoch 1) before ChangeCipherSpec (epoch 0), Contik-NG TinyDTLS will abort the handshake. Such an event can happen due to reordering. This problem is exposed in the below capture for a TinyDTLS client. Notice that the server ChangeCipherSpec is received after an encrypted record which is the Finished message. This leads to unwarranted handshake termination.

Steps to Reproduce
I attached files necessary for reproduction using DTLS-Fuzzer, a Java-based tool for testing DTLS libraries. Also included in the archive the captures of the interaction show above. DTLS-Fuzzer requires the JDK for Java 8. On Ubuntu, this can be installed by running:
sudo apt-get install openjdk-8-jdk

Unpack the archive, cd to resulting folder and run bash reproduce.sh test_sequence_decrypt or bash reproduce.sh test_sequence_reorder, while running an instance of Wireshark on the side. The reproduction script will:

• setup Contik-NG TinyDTLS and DTLS-Fuzzer
• launch the TinyDTLS client using the 'tests/dtls-client utility;
• launch DTLS-Fuzzer to execute the input sequences 'test_sequence_decrypt' or 'test_sequence_reorder' which expose the two problems.

I also added the test sequence 'test_sequence_handshake'. This is similar to the reordering sequence, but without the reordering. By executing this sequence via bash reproduce.sh test_sequence_handshake, you should complete the handshake with the client.

Note that the problems affect both clients and servers. On request, I can provide reproduction scripts also for servers. I am guessing fixing the problem for clients will also do it for servers.

Thanks!

reproduction.tar.gz

Hi,
i try to compile sha2, rijindael:
1-i extract tinydtls-master
2- i copy aes /sha2 to examples
3- i create a makefile
4- in a terminal i launch make TARGET=z1 (aes or sha2)
5- the same error for both projects

LD build/z1/rijndael.z1
rijndael.o: file not recognized: File format not recognized
collect2: ld a retourné 1 code d'état d'exécution
../../Makefile.include:416: recipe for target 'build/z1/rijndael.z1' failed
make: *** [build/z1/rijndael.z1] Error 1

LD build/z1/sha2.z1
sha2.o: file not recognized: File format not recognized
collect2: ld a retourné 1 code d'état d'exécution
../../Makefile.include:416: recipe for target 'build/z1/sha2.z1' failed
make: *** [build/z1/sha2.z1] Error 1

please how can i resolve this problem
best regards

I am currently trying to use CoAPs on contiki-ng. I’ve made following changes before building:

in Makefile.coap
MAKE_WITH_DTLS ?= 1
MAKE_COAP_DTLS_KEYSTORE ?= MAKE_COAP_DTLS_KEYSTORE_SIMPLE

and in proj-conf.h
#define COAP_DTLS_PSK_DEFAULT_IDENTITY "user"
#define COAP_DTLS_PSK_DEFAULT_KEY "password"

However when I try to use the coap-client in libcoap (the dtls bransch) to get data from my coap server run on a cc1350 sensortag with contiki-ng I get no return data. And when I look in Wireshark it seems like the UDP port is 5683 and not 5684 for the CoAP package.

Is there more that need to be enabled to get CoAP + DTLS to work in contiki-ng?

In the master branch 53a0d97, DTLS servers mishandle the early use of a large epoch number. This vulnerability allows remote attackers to cause a denial of service and false-positive packet drops.

This vulnerability could be reproduced by sending packets to complete two times of handshakes. The epoch number in the first handshake is larger than that in the second handshake; however, servers still could allow completing these handshakes. The following shows the packets captured by Wireshark.

In the master branch 53a0d97, an illegal over-read bug has been found when the server handles a malicious message with the following values for the mentioned fields:

Fragment length may be a larger number like 8143, whose value can be up to (2^24-1) bytes theoretically.
the peer exists and is not null.
After the server handles this message in the normal way as follows(in the master branch), we enter into the function dtls_ccm_decrypt_message() at dtls-ccm.c:250.

1. 0x4e4b33 in dtls_ccm_decrypt_message /home/Research/benchmarks/tinydtls/dtls-ccm.c:250
2. 0x4dd76a in dtls_ccm_decrypt /home/Research/benchmarks/tinydtls/dtls-crypto.c:255
3. 0x4dd76a in dtls_decrypt /home/Research/benchmarks/tinydtls/dtls-crypto.c:512
4. 0x4cbfe7 in decrypt_verify /home/Research/benchmarks/tinydtls/dtls.c:3056
5. 0x4c9bbc in dtls_handle_message /home/Research/benchmarks/tinydtls/dtls.c:3782
6. 0x4c67bc in dtls_handle_read /home/Research/benchmarks/tinydtls/tests/dtls-server.c:187
7. 0x4c67bc in main /home/Research/benchmarks/tinydtls/tests/dtls-server.c:355

In the function dtls_ccm_decrypt_message(), the value of variable lm is larger than the length of the current packet, whose value is less than 1400. Hence, an illegal memory access bug appears, which leads to the server crashing, memory leak and other effects.

From DTLS12 RFC, the server should have the ability to fragment large packets. If not, over-large packets should be refused.

Until the master branch 53a0d97, one incorrect handshake is completed with different epoch numbers in the packets Client_Hello, Client_key_exchange and Change_cipher_spec.

Here are captured packets with Wireshark,

Hi,
I try to connect libcoap's coap-client and contiki-ng's coap-server.
Without DTLS they can connect and exchange messages as expected.
Using TinyDTLS on client's site and compiling coap-server with TinyDTLS (I append in project.conf: MAKE_WITH_DTLS=1
MAKE_COAP_DTLS_KEYSTORE=MAKE_COAP_DTLS_KEYSTORE_SIMPLE
#define COAP_DTLS_PSK_DEFAULT_IDENTITY "Client_identity"
#define COAP_DTLS_PSK_DEFAULT_KEY "secretPSK"), the server reject the connection with this output :

pi@raspberrypi:~/libcoap/examples $ ./coap-client -m get coaps://[fd00::212:4b00:1204:ddc6]/ -u Client_identity -k secretPSK -v9
Jul 21 00:54:19.530 DEBG ***[fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: new outgoing session
Jul 21 00:54:19.530 DEBG ***new session 0x1a1a120
Jul 21 00:54:19 DEBG dtls_new_peer: [fd00::212:4b00:1204:ddc6]:5684
Jul 21 00:54:19 DEBG DTLSv12: initialize HASH_SHA256
Jul 21 00:54:19 DEBG send handshake packet of type: client_hello (1)
Jul 21 00:54:19 DEBG send header: (13 bytes):
00000000 16 FE FF 00 00 00 00 00  00 00 00 00 36 
Jul 21 00:54:19 DEBG send unencrypted: (12 bytes):
00000000 01 00 00 2A 00 00 00 00  00 00 00 2A 
Jul 21 00:54:19 DEBG send unencrypted: (42 bytes):
00000000 FE FD 00 00 00 00 2B 03  A4 B1 8A 6C 3A A7 09 63 
00000010 53 2B 02 27 A2 32 70 E0  F8 52 79 BA 00 34 0C 87 
00000020 26 39 00 00 00 02 C0 A8  01 00 
Jul 21 00:54:19.531 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: sent 67 bytes
Jul 21 00:54:19.531 DEBG sending CoAP request:
Jul 21 00:54:19.531 DEBG ** [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: tid=22224: delayed
Jul 21 00:54:19.531 DEBG timeout is set to 90 seconds
Jul 21 00:54:19.531 DEBG ** DTLS global timeout set to 2000ms
Jul 21 00:54:20.532 DEBG ** DTLS global timeout set to 999ms
Jul 21 00:54:21 DEBG ** retransmit handshake packet of type: client_hello (1)
Jul 21 00:54:21 DEBG retransmit header: (13 bytes):
00000000 16 FE FD 00 00 00 00 00  00 00 01 00 36 
Jul 21 00:54:21 DEBG retransmit unencrypted: (54 bytes):
00000000 01 00 00 2A 00 00 00 00  00 00 00 2A FE FD 00 00 
00000010 00 00 2B 03 A4 B1 8A 6C  3A A7 09 63 53 2B 02 27 
00000020 A2 32 70 E0 F8 52 79 BA  00 34 0C 87 26 39 00 00 
00000030 00 02 C0 A8 01 00 
Jul 21 00:54:21.532 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: sent 67 bytes
Jul 21 00:54:21.532 DEBG ** DTLS global timeout set to 4001ms
Jul 21 00:54:21.532 DEBG ** DTLS global timeout set to 4000ms
Jul 21 00:54:21.642 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: received 44 bytes
Jul 21 00:54:21 DEBG dtls_handle_message: FOUND PEER
Jul 21 00:54:21 DEBG got packet 22 (44 bytes)
Jul 21 00:54:21 DEBG receive header: (13 bytes):
00000000 16 FE FD 00 00 00 00 00  00 00 00 00 1F 
Jul 21 00:54:21 DEBG receive unencrypted: (31 bytes):
00000000 03 00 00 13 00 00 00 00  00 00 00 13 FE FD 10 EB 
00000010 B7 C4 4E 39 B0 C0 7D 96  E9 C1 C0 AA B2 E8 D5 
Jul 21 00:54:21 DEBG received handshake packet of type: hello_verify_request (3)
Jul 21 00:54:21 DEBG handle handshake packet of type: hello_verify_request (3)
Jul 21 00:54:21 DEBG clear MAC
Jul 21 00:54:21 DEBG add MAC data: (12 bytes): 0100003A000100000000003A
Jul 21 00:54:21 DEBG add MAC data: (58 bytes): FEFD000000002B03A4B18A6C3AA70963532B0227A23270E0F85279BA00340C8726390010EBB7C44E39B0C07D96E9C1C0AAB2E8D50002C0A80100
Jul 21 00:54:21 DEBG send handshake packet of type: client_hello (1)
Jul 21 00:54:21 DEBG send header: (13 bytes):
00000000 16 FE FF 00 00 00 00 00  00 00 02 00 46 
Jul 21 00:54:21 DEBG send unencrypted: (12 bytes):
00000000 01 00 00 3A 00 01 00 00  00 00 00 3A 
Jul 21 00:54:21 DEBG send unencrypted: (58 bytes):
00000000 FE FD 00 00 00 00 2B 03  A4 B1 8A 6C 3A A7 09 63 
00000010 53 2B 02 27 A2 32 70 E0  F8 52 79 BA 00 34 0C 87 
00000020 26 39 00 10 EB B7 C4 4E  39 B0 C0 7D 96 E9 C1 C0 
00000030 AA B2 E8 D5 00 02 C0 A8  01 00 
Jul 21 00:54:21.644 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: sent 83 bytes
Jul 21 00:54:21.644 DEBG ** DTLS global timeout set to 2000ms
Jul 21 00:54:22.645 DEBG ** DTLS global timeout set to 999ms
Jul 21 00:54:23 DEBG ** retransmit handshake packet of type: client_hello (1)
Jul 21 00:54:23 DEBG retransmit header: (13 bytes):
00000000 16 FE FD 00 00 00 00 00  00 00 03 00 46 
Jul 21 00:54:23 DEBG retransmit unencrypted: (70 bytes):
00000000 01 00 00 3A 00 01 00 00  00 00 00 3A FE FD 00 00 
00000010 00 00 2B 03 A4 B1 8A 6C  3A A7 09 63 53 2B 02 27 
00000020 A2 32 70 E0 F8 52 79 BA  00 34 0C 87 26 39 00 10 
00000030 EB B7 C4 4E 39 B0 C0 7D  96 E9 C1 C0 AA B2 E8 D5 
00000040 00 02 C0 A8 01 00 
Jul 21 00:54:23.645 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: sent 83 bytes
Jul 21 00:54:23.645 DEBG ** DTLS global timeout set to 4001ms
Jul 21 00:54:23.645 DEBG ** DTLS global timeout set to 4000ms
Jul 21 00:54:23.813 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: received 63 bytes
Jul 21 00:54:23 DEBG dtls_handle_message: FOUND PEER
Jul 21 00:54:23 DEBG got packet 22 (63 bytes)
Jul 21 00:54:23 DEBG new packet arrived with seq_nr: 1
Jul 21 00:54:23 DEBG new bitfield is               : ffffffffffffffff
Jul 21 00:54:23 DEBG receive header: (13 bytes):
00000000 16 FE FD 00 00 00 00 00  00 00 01 00 32 
Jul 21 00:54:23 DEBG receive unencrypted: (50 bytes):
00000000 02 00 00 26 00 01 00 00  00 00 00 26 FE FD 00 00 
00000010 03 F9 FC 5F BC AF 79 17  49 A5 8F B9 53 47 50 85 
00000020 6C 80 B1 18 C9 2A CC F8  6E 1C 2D CD F5 B8 00 C0 
00000030 A8 00 
Jul 21 00:54:23 DEBG received handshake packet of type: server_hello (2)
Jul 21 00:54:23 DEBG handle handshake packet of type: server_hello (2)
Jul 21 00:54:23 DEBG add MAC data: (50 bytes): 020000260001000000000026FEFD000003F9FC5FBCAF791749A58FB9534750856C80B118C92ACCF86E1C2DCDF5B800C0A800
Jul 21 00:54:23.837 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: received 25 bytes
Jul 21 00:54:23 DEBG dtls_handle_message: FOUND PEER
Jul 21 00:54:23 DEBG got packet 22 (25 bytes)
Jul 21 00:54:23 DEBG new packet arrived with seq_nr: 2
Jul 21 00:54:23 DEBG new bitfield is               : ffffffffffffffff
Jul 21 00:54:23 DEBG receive header: (13 bytes):
00000000 16 FE FD 00 00 00 00 00  00 00 02 00 0C 
Jul 21 00:54:23 DEBG receive unencrypted: (12 bytes):
00000000 0E 00 00 00 00 02 00 00  00 00 00 00 
Jul 21 00:54:23 DEBG received handshake packet of type: server_hello_done (14)
Jul 21 00:54:23 DEBG handle handshake packet of type: server_hello_done (14)
Jul 21 00:54:23 DEBG add MAC data: (12 bytes): 0E0000000002000000000000
Jul 21 00:54:23.838 DEBG got psk_identity_hint: ''
Jul 21 00:54:23.838 INFO Identity Hint '' provided
Jul 21 00:54:23 DEBG add MAC data: (12 bytes): 100000110002000000000011
Jul 21 00:54:23 DEBG add MAC data: (17 bytes): 000F436C69656E745F6964656E74697479
Jul 21 00:54:23 DEBG send handshake packet of type: client_key_exchange (16)
Jul 21 00:54:23 DEBG send header: (13 bytes):
00000000 16 FE FD 00 00 00 00 00  00 00 04 00 1D 
Jul 21 00:54:23 DEBG send unencrypted: (12 bytes):
00000000 10 00 00 11 00 02 00 00  00 00 00 11 
Jul 21 00:54:23 DEBG send unencrypted: (17 bytes):
00000000 00 0F 43 6C 69 65 6E 74  5F 69 64 65 6E 74 69 74 
00000010 79 
Jul 21 00:54:23.838 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: sent 42 bytes
Jul 21 00:54:23 DEBG psk: (9 bytes):
00000000 73 65 63 72 65 74 50 53  4B 
Jul 21 00:54:23 DEBG client_random: (32 bytes): 000000002B03A4B18A6C3AA70963532B0227A23270E0F85279BA00340C872639
Jul 21 00:54:23 DEBG server_random: (32 bytes): 000003F9FC5FBCAF791749A58FB9534750856C80B118C92ACCF86E1C2DCDF5B8


Jul 21 00:54:23 DEBG pre_master_secret: (22 bytes): 0009000000000000000000000973656372657450534B
Jul 21 00:54:23 DEBG master_secret: (48 bytes): 3E223992F158E4BA08F73CD0C8ACA7095121006FC2CC847D1AACC8AAC0FB9CAE7B85AA0F2B56AEC5B58119C87B20D598
Jul 21 00:54:23 DEBG key_block (40 bytes):
Jul 21 00:54:23 DEBG   client_MAC_secret: (0 bytes): 
Jul 21 00:54:23 DEBG   server_MAC_secret: (0 bytes): 
Jul 21 00:54:23 DEBG   client_write_key: (16 bytes): 4A34346C03C2663C6B8E841013D1DDCC
Jul 21 00:54:23 DEBG   server_write_key: (16 bytes): 54587DE735010C566107EFAE354174FD
Jul 21 00:54:23 DEBG   client_IV: (4 bytes): FB407F58
Jul 21 00:54:23 DEBG   server_IV: (4 bytes): 4F528AD3
Jul 21 00:54:23 DEBG send header: (13 bytes):
00000000 14 FE FD 00 00 00 00 00  00 00 05 00 01 
Jul 21 00:54:23 DEBG send unencrypted: (1 bytes):
00000000 01 
Jul 21 00:54:23.840 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: sent 14 bytes
Jul 21 00:54:23 DEBG server finished MAC: (12 bytes): 2D9C9F21432DFAF331BD2A76
Jul 21 00:54:23 DEBG add MAC data: (12 bytes): 1400000C000300000000000C
Jul 21 00:54:23 DEBG add MAC data: (12 bytes): 2D9C9F21432DFAF331BD2A76
Jul 21 00:54:23 DEBG send handshake packet of type: finished (20)
Jul 21 00:54:23 DEBG dtls_prepare_record(): encrypt using TLS_PSK_WITH_AES_128_CCM_8
Jul 21 00:54:23 DEBG nonce:: (16 bytes): FB407F58000100000000000000000000
Jul 21 00:54:23 DEBG key:: (16 bytes): 4A34346C03C2663C6B8E841013D1DDCC
Jul 21 00:54:23 DEBG message:: (40 bytes): 000100000000000075F072E5F4D55546D2D95CECE8104F7D9C3744F9F0C8F092B0B2B86FDA1479C5
Jul 21 00:54:23 DEBG send header: (13 bytes):
00000000 16 FE FD 00 01 00 00 00  00 00 00 00 28 
Jul 21 00:54:23 DEBG send unencrypted: (12 bytes):
00000000 14 00 00 0C 00 03 00 00  00 00 00 0C 
Jul 21 00:54:23 DEBG send unencrypted: (12 bytes):
00000000 2D 9C 9F 21 43 2D FA F3  31 BD 2A 76 
Jul 21 00:54:23.841 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: sent 53 bytes
Jul 21 00:54:23.842 DEBG ** DTLS global timeout set to 1997ms
Jul 21 00:54:23.919 DEBG *  [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: received 15 bytes
Jul 21 00:54:23 DEBG dtls_handle_message: FOUND PEER
Jul 21 00:54:23 DEBG got packet 21 (15 bytes)
Jul 21 00:54:23 DEBG new packet arrived with seq_nr: 3
Jul 21 00:54:23 DEBG new bitfield is               : ffffffffffffffff
Jul 21 00:54:23 DEBG receive header: (13 bytes):
00000000 15 FE FD 00 00 00 00 00  00 00 03 00 02 
Jul 21 00:54:23 DEBG receive unencrypted: (2 bytes):
00000000 02 33 
Jul 21 00:54:23 INFO ** Alert: level 2, description 51
Jul 21 00:54:23 ALRT 51 invalidate peer
Jul 21 00:54:23 DEBG removed peer: [fd00::212:4b00:1204:ddc6]:5684
Jul 21 00:54:23 WARN received alert, peer has been invalidated
Jul 21 00:54:23.920 DEBG ***EVENT: 0x0200
Jul 21 00:54:23.920 DEBG ***[fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: session disconnected (reason 3)
Jul 21 00:54:23.920 DEBG ***removed session 0x1a1a120
Jul 21 00:54:23.920 DEBG ***EVENT: 0x0000
Jul 21 00:54:23.920 DEBG ** [fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: tid=22224: not transmitted after disconnect
Jul 21 00:54:23.921 DEBG ***[fd00::1]:37517 <-> [fd00::212:4b00:1204:ddc6]:5684 DTLS: session closed

Can somebody help to solve this problem please ?
I suppose there are many other that faced this problem. How they solved it ?
Thanks in advance

how to fix this problem?