[6lbr-dev] DTLS retransmission problems : ¿Delay between sends?

Laurent Deru laurent.deru at cetic.be
Thu Jun 19 06:50:34 UTC 2014


Sorry, I've been quite busy lately. This issue looks a lot like one we 
have solved in 6LBR, there was some bugs in CSMA that causes fragmented 
packets to get dropped. Some of them are already merged into latest 
Contiki, but there are still open pull requests related. Also, if on the 
server you are using a slip-radio, there was also drops there as the 
slip buffer could only store two packets at a time.

If you want to add delays between packet, what you could do is instead 
add delays inside CSMA. Currently there already is some backoff 
mechanism, but you could activate it all the time an increase the delay

Kind regards,

Le 2/06/14 13:10, Guillermo Cañada Valverde a écrit :
> Hello,
> i am having packet lost problems while communicating 2 motes 
> (dtls-client and dtls-server).
> It only happens when the DTLS handshake try to send 3 packets ( 120 
> bytes each) in a aproximately 150 ms between the first and the last one.
> The sender(dtls-client) sends all properly ( wireshark detects it too, 
> properly), but the receiver(dtls-server) just receive the first one, 
> or the second one too, but never all of them. I think that is it not 
> problem of buffer size or queuebuf, since the defines are the following:
> #define QUEUEBUF_CONF_NUM 14
> #define UIP_CONF_BUFFER_SIZE 2560
> Since i think that the problem is caused by the lack of the delay 
> between sends, I would like to make a delay separation between the 
> packets to give to the receiver some extra time to receive all 
> properly, but the three packets are sent from a function, not directly 
> from the main of a process, so i am only able to make some 
> _delay_loop_2(50000); but this doesnt work because ( i think) its 
> stops all the retransmission by making the CPU stay busy.
> I have tried by calling a second process from the function, just to 
> make a process_wait_event_until ( etimer expired..) but when the 
> second process is waiting, the program returns to the first process, 
> where the function is running, so it doesnt works too.
> Any idea? Maybe any way to pause the first process from the second 
> process while the process_wait_event is waiting.. and then resume the 
> first process ( if its posible, i dont know..). I have read that the 
> process_wait_event doesnt makes the CPU stay busy so i guess that the 
> packets would be sent while the program is waiting, so i only need a 
> way to pause the first process while the second one is waiting.
> If you think that the problem is not the lack of delay between 
> packets, tell me please.
> If more information is needed, please just ask for it :)
> PD: i am using Contiki-2.7, ATMEGA256RFR2, csma.c and nullrdc.
> 2014-05-13 12:00 GMT+02:00 <6lbr-dev-request at lists.cetic.be 
> <mailto:6lbr-dev-request at lists.cetic.be>>:
>     Send 6lbr-dev mailing list submissions to
>     6lbr-dev at lists.cetic.be <mailto:6lbr-dev at lists.cetic.be>
>     To subscribe or unsubscribe via the World Wide Web, visit
>     http://lists.cetic.be/cgi-bin/mailman/listinfo/6lbr-dev
>     or, via email, send a message with subject or body 'help' to
>     6lbr-dev-request at lists.cetic.be
>     <mailto:6lbr-dev-request at lists.cetic.be>
>     You can reach the person managing the list at
>     6lbr-dev-owner at lists.cetic.be <mailto:6lbr-dev-owner at lists.cetic.be>
>     When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of 6lbr-dev digest..."
>     Today's Topics:
>        1. Multiple RPL instances support? (Francisco Vidal Meca)
>     ----------------------------------------------------------------------
>     Message: 1
>     Date: Tue, 13 May 2014 09:37:06 +0200
>     From: Francisco Vidal Meca <fvidalmeca at pacovi.es
>     <mailto:fvidalmeca at pacovi.es>>
>     Subject: [6lbr-dev] Multiple RPL instances support?
>     To: 6lbr-dev at lists.cetic.be <mailto:6lbr-dev at lists.cetic.be>,
>     Contiki developer mailing list
>     <contiki-developers at lists.sourceforge.net
>     <mailto:contiki-developers at lists.sourceforge.net>>
>     Message-ID:
>     <CAKtJ0d0DAbKdMG16xSoV4gdwQdW1S4Q8PSUcOyRu6obMDmopxw at mail.gmail.com <mailto:CAKtJ0d0DAbKdMG16xSoV4gdwQdW1S4Q8PSUcOyRu6obMDmopxw at mail.gmail.com>>
>     Content-Type: text/plain; charset="utf-8"
>     Hi all,
>     I have been trying to make work multiple RPL instances
>     concurrently in some
>     nodes on the network
>     tl;dr; Anyone knows a Contiki version (development branch or
>     whatnot) that
>     has support for multiple RPL global instances?
>     So far I have (without success) tried to form the RPL instances
>     using both
>     the master branch of Contiki 3.x and the 6lbr fork. Are multiple RPL
>     instances supported by some development branch or are they just not
>     supported yet? I have found some messages [1] relating to the work
>     that
>     would be needed to make them work but found no much information
>     about it.
>     The problem in the simplified scenario looks like this, being R_1
>     and R_2
>     two RPL roots, and N_n different nodes of the network. Nodes N_a
>     listen to
>     traffic from RPL instance of R_1 while nodes N_b listen to RPL
>     instance of
>     R_2, only N_c can listen to traffic from both RPL instances (just
>     because
>     it's in radio range).
>     R_1 --> N_a1 ---> N_a2
>                      \                  \
>                        ...                N_c
>                                          /
>                                        /
>     R_2---> N_b1 ---> N_b2
>                      \
>                        ....
>     Nodes behave correctly when only one RPL instance is involved, but
>     with 2
>     RPL instances it behaves like if it was using 2 different DODAGs
>     of the
>     same RPL instance (that is, getting a single preferred parent for
>     all known
>     DODAGs instead of a preferred parent for each RPL instance).
>     Any ideas?
>     Regards,
>     Paco
>     [1] http://sourceforge.net/p/contiki/mailman/message/31522911/
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>     URL:
>     http://lists.cetic.be/pipermail/6lbr-dev/attachments/20140513/de9268fe/attachment-0001.htm
>     ------------------------------
>     _______________________________________________
>     6lbr-dev mailing list
>     6lbr-dev at lists.cetic.be <mailto:6lbr-dev at lists.cetic.be>
>     http://lists.cetic.be/cgi-bin/mailman/listinfo/6lbr-dev
>     End of 6lbr-dev Digest, Vol 13, Issue 5
>     ***************************************
> _______________________________________________
> 6lbr-dev mailing list
> 6lbr-dev at lists.cetic.be
> http://lists.cetic.be/cgi-bin/mailman/listinfo/6lbr-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cetic.be/archives/6lbr-dev/attachments/20140619/911b02b9/attachment.html>

More information about the 6lbr-dev mailing list