Contiki: CoAP retransmissions are not discarded

Created on 21 Jan 2017 · 12Comments · Source: contiki-os/contiki

I found out that CoAP Server does not discard packets even if they were previously received.
In my case, the ACK sent by the server got lost, so the CoAP Client made a retransmission, and it was not discarded by the server.
To reproduce the problem, I filter all incoming packets coming from the server in the Client side.
$ sudo ip6tables -A INPUT -j DROP -p udp -s 2001:470:1f12:8c8:2::2000

Then I started monitoring the traffic in the Client side
$ sudo tcpdump -xx port 51461 -i tun0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
18:35:45.101755 IP6 2001:470:1f12:8c8:2::1001.52842 > 2001:470:1f12:8c8:2::2000.51461: UDP, length 65
    0x0000:  600f ed4c 0049 1140 2001 0470 1f12 08c8
    0x0010:  0002 0000 0000 1001 2001 0470 1f12 08c8
    0x0020:  0002 0000 0000 2000 ce6a c905 0049 39e9
    0x0030:  4402 e707 62d2 022a b961 6374 7561 746f
    0x0040:  7273 0672 656d 6f74 6511 32ff 7b22 636f
    0x0050:  6465 223a 5b32 3433 2c34 395d 2c22 6269
    0x0060:  7473 223a 3133 2c22 7469 6d65 7322 3a39
    0x0070:  7d
18:35:45.611813 IP6 2001:470:1f12:8c8:2::2000.51461 > 2001:470:1f12:8c8:2::1001.52842: UDP, length 9
    0x0000:  6000 0000 0011 113e 2001 0470 1f12 08c8
    0x0010:  0002 0000 0000 2000 2001 0470 1f12 08c8
    0x0020:  0002 0000 0000 1001 c905 ce6a 0011 2f76
    0x0030:  6445 e707 62d2 022a c0
18:35:47.694559 IP6 2001:470:1f12:8c8:2::1001.52842 > 2001:470:1f12:8c8:2::2000.51461: UDP, length 65
    0x0000:  600f ed4c 0049 1140 2001 0470 1f12 08c8
    0x0010:  0002 0000 0000 1001 2001 0470 1f12 08c8
    0x0020:  0002 0000 0000 2000 ce6a c905 0049 39e9
    0x0030:  4402 e707 62d2 022a b961 6374 7561 746f
    0x0040:  7273 0672 656d 6f74 6511 32ff 7b22 636f
    0x0050:  6465 223a 5b32 3433 2c34 395d 2c22 6269
    0x0060:  7473 223a 3133 2c22 7469 6d65 7322 3a39
    0x0070:  7d
18:35:48.344231 IP6 2001:470:1f12:8c8:2::2000.51461 > 2001:470:1f12:8c8:2::1001.52842: UDP, length 9
    0x0000:  6000 0000 0011 113e 2001 0470 1f12 08c8
    0x0010:  0002 0000 0000 2000 2001 0470 1f12 08c8
    0x0020:  0002 0000 0000 1001 c905 ce6a 0011 2f76
    0x0030:  6445 e707 62d2 022a c0
18:35:52.880162 IP6 2001:470:1f12:8c8:2::1001.52842 > 2001:470:1f12:8c8:2::2000.51461: UDP, length 65
    0x0000:  600f ed4c 0049 1140 2001 0470 1f12 08c8
    0x0010:  0002 0000 0000 1001 2001 0470 1f12 08c8
    0x0020:  0002 0000 0000 2000 ce6a c905 0049 39e9
    0x0030:  4402 e707 62d2 022a b961 6374 7561 746f
    0x0040:  7273 0672 656d 6f74 6511 32ff 7b22 636f
    0x0050:  6465 223a 5b32 3433 2c34 395d 2c22 6269
    0x0060:  7473 223a 3133 2c22 7469 6d65 7322 3a39
    0x0070:  7d
18:35:53.473285 IP6 2001:470:1f12:8c8:2::2000.51461 > 2001:470:1f12:8c8:2::1001.52842: UDP, length 9
    0x0000:  6000 0000 0011 113e 2001 0470 1f12 08c8
    0x0010:  0002 0000 0000 2000 2001 0470 1f12 08c8
    0x0020:  0002 0000 0000 1001 c905 ce6a 0011 2f76
    0x0030:  6445 e707 62d2 022a c0
18:36:03.250058 IP6 2001:470:1f12:8c8:2::1001.52842 > 2001:470:1f12:8c8:2::2000.51461: UDP, length 65
    0x0000:  600f ed4c 0049 1140 2001 0470 1f12 08c8
    0x0010:  0002 0000 0000 1001 2001 0470 1f12 08c8
    0x0020:  0002 0000 0000 2000 ce6a c905 0049 39e9
    0x0030:  4402 e707 62d2 022a b961 6374 7561 746f
    0x0040:  7273 0672 656d 6f74 6511 32ff 7b22 636f
    0x0050:  6465 223a 5b32 3433 2c34 395d 2c22 6269
    0x0060:  7473 223a 3133 2c22 7469 6d65 7322 3a39
    0x0070:  7d
18:36:03.768217 IP6 2001:470:1f12:8c8:2::2000.51461 > 2001:470:1f12:8c8:2::1001.52842: UDP, length 9
    0x0000:  6000 0000 0011 113e 2001 0470 1f12 08c8
    0x0010:  0002 0000 0000 2000 2001 0470 1f12 08c8
    0x0020:  0002 0000 0000 1001 c905 ce6a 0011 2f76
    0x0030:  6445 e707 62d2 022a c0
18:36:23.989485 IP6 2001:470:1f12:8c8:2::1001.52842 > 2001:470:1f12:8c8:2::2000.51461: UDP, length 65
    0x0000:  600f ed4c 0049 1140 2001 0470 1f12 08c8
    0x0010:  0002 0000 0000 1001 2001 0470 1f12 08c8
    0x0020:  0002 0000 0000 2000 ce6a c905 0049 39e9
    0x0030:  4402 e707 62d2 022a b961 6374 7561 746f
    0x0040:  7273 0672 656d 6f74 6511 32ff 7b22 636f
    0x0050:  6465 223a 5b32 3433 2c34 395d 2c22 6269
    0x0060:  7473 223a 3133 2c22 7469 6d65 7322 3a39
    0x0070:  7d
18:36:24.523162 IP6 2001:470:1f12:8c8:2::2000.51461 > 2001:470:1f12:8c8:2::1001.52842: UDP, length 9
    0x0000:  6000 0000 0011 113e 2001 0470 1f12 08c8
    0x0010:  0002 0000 0000 2000 2001 0470 1f12 08c8
    0x0020:  0002 0000 0000 1001 c905 ce6a 0011 2f76
    0x0030:  6445 e707 62d2 022a c0

Every time the packet was received by the Server, it wasn't discarded and an ACK was sent back to the Client.

Thank you.

Source

alejandr0

😕2

Most helpful comment

Yes, you are correct. This is a missing feature. We will take a look at a minimal implementation that at least will ignore duplicates of the last received packet (e.g. not send on to the application). But still handle acks.

joakimeriksson on 14 Mar 2017

👍6

All 12 comments

Any update on this? Still having the same issue with the last Contiki version. @joakimeriksson could you give me any help with this?.

Thank you in advance.

alejandr0 on 15 Feb 2017

We are experiencing exactly the same problem. Any help on this would be much appreciated!

dariushs20 on 8 Mar 2017

alejandr0 did you get a response? ...we had similar issues with discarding packets! would really appreciate your help

raminsj13 on 8 Mar 2017

I'm sorry @raminsj13 didn't get any support yet, will inform you as soon as I get any help.

alejandr0 on 8 Mar 2017

Same here, retransmissions of packets that were previously received, but not acknowledged, are not being discarded. @joakimeriksson Please help.

axlalvaro on 8 Mar 2017

This behavior does not honor the rfc7252 4.5 which talks about duplicate messages:

4.5.  Message Deduplication

   A recipient might receive the same Confirmable message (as indicated
   by the Message ID and source endpoint) multiple times within the
   EXCHANGE_LIFETIME (Section 4.8.2), for example, when its
   Acknowledgement went missing or didn't reach the original sender
   before the first timeout.  The recipient SHOULD acknowledge each
   duplicate copy of a Confirmable message using the same
   Acknowledgement or Reset message but SHOULD process any request or
   response in the message only once.  This rule MAY be relaxed in case
   the Confirmable message transports a request that is idempotent (see
   Section 5.1) or can be handled in an idempotent fashion.

The KEY is

but SHOULD process any request or response in the message __only once__

cquijano on 9 Mar 2017

joakimeriksson on 14 Mar 2017

👍6

Hi all,
also experiencing this problem and looking forward to get a fix!
Thanks!

jcharlet on 16 Mar 2017

Thank you so much @joakimeriksson for replying to this issue, really appreciate your help because this is a critical feature for our application, since the nodes are performing an action that can't be done twice.
Hope you can make the implementation of this soon.

alejandr0 on 17 Mar 2017

I'm having the same issue. Will we get updated when there's a fix?

vcifani on 28 Mar 2017

Any update on this, @joakimeriksson ??

alejandr0 on 15 Jun 2017

Added a list of packages already processed, so in case the ACK is missed the retransmitted message is not handled again.
Messages are identified by the MID, ip address and port.

There are two configurable parameters:

COAP_CHECK_DUPLICATES_LIST_SIZE
Define the maximum number of messages to track
COAP_CHECK_DUPLICATES_MAX_SECONDS
Amount of seconds to wait until a message on the list is expired