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

Guillermo Cañada Valverde guillermocanada at gmail.com
Mon Jun 2 11:10:48 UTC 2014


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>:

> Send 6lbr-dev mailing list submissions to
>         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
>
> You can reach the person managing the list at
>         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>
> Subject: [6lbr-dev] Multiple RPL instances support?
> To: 6lbr-dev at lists.cetic.be, Contiki developer mailing list
>         <contiki-developers at lists.sourceforge.net>
> Message-ID:
>         <
> 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
> http://lists.cetic.be/cgi-bin/mailman/listinfo/6lbr-dev
>
>
> End of 6lbr-dev Digest, Vol 13, Issue 5
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cetic.be/archives/6lbr-dev/attachments/20140602/a5006fbf/attachment.html>


More information about the 6lbr-dev mailing list