| [tinydtls-dev] handshake message not received due to long processing |
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 |