Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tinydtls-dev] handshake message not received due to long processing
Hi Jan Kün

One question, before applying the possible solutions, when you are having this scenario, the  server  sent multiple Hello Verify Request meanwhile the client is processing the messages?  This only to try to see a relation to the issues I was having with Contiki.

By the way, sadly, what you describe is the current limitation of the motes, not something that  relies only in TinyDTLS, although as Olef already stated, moving to the micro-ECC could helps a lot.

By the way, Olef

There might be another effect kick in here: As Contiki uses cooperative
threading, data received on the network interface is not handled while
other threads run. Now, the tinydtls thread takes loooong for the ECC
operations during the handshake, blocking the network interface during
this time.

Is strictly required that TinyDTLs have the extra contiki thread in the library ?  (dtls.c:4062)

I mean, the contiki examples already create a thread, and then the state machine  generates a second one which remains in an infinite cycle. I still don't get  inside of the details of how Contiki handle its threads, so I could be missing an important point here.





2016-07-26 9:41 GMT+02:00 Jan Kühn <kuehnj@xxxxxxxxxxxxxxxxxxxxxxxxxx>:

Hi,

 

I encountered another problem regarding tinydtls together with contiki on the CC2538dk.

 

In the handshake, after receiving ClientHello the Server sends 5 messages to the client: ServerHello, Certificate, ServerKeyExchange, Certificate Request, ServerHelloDone. The problem is, that some of the packets are not received by the client, however this is not due to random package loss. It appears that the client’s radio has a fifo buffer overflow because it doesn’t handle the messages fast enough. First the problem was that I had a lot of debugging messages on the serial port and the client didn’t get the ServerKeyExchange message. After removing the debugging outputs, it worked fine until the client receives ServerKeyExchange. As I’m using the ECC cipher suite, the client has to perform a ECDSA verification which takes 20 seconds! In that time the client receives CertificateRequest and ServerHelloDone; CertificateRequest can be processed, ServerHelloDone however doesn’t fit in the client’s radio buffer and is therefore lost.

 

To the solution:

 

Eventually I want to use the CC2538’s ECC hardware components which should speed up the processing dramatically and hopefully solve this issue. But as putting in the hardware will most probably lead to other bugs I would like to get the pure software implemented DTLS handshake running first. I see two options:

1.       Artificially slow down the handshake message so both sides have enough time to process (simple but nasty).

2.       Use a second buffer to first receive all handshake messages before starting any long processing. I think that the netq structure might be quite useful for this because it can store all the handshake messages. But I’m not sure how exactly it is used (I think the purpose is message reordering?) and if I could use it for this matter. Do you think this might work at all? Also do I have to use a “second” netq or might it be possible to use the one that is already used.

3.       I’m open for any other suggestions.

 

Another problem is, that if processing takes too long, even if all messages would be received, the retransmit process will kick in. I solved this by increasing the retransmit timer dramatically, which also doesn’t feel like a very good solution.

 

Grüße

Jan


_______________________________________________
tinydtls-dev mailing list
tinydtls-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tinydtls-dev


Back to the top