sicslowpan input: Dropping 6lowpan packet that is not a fragment

contiki-os / contiki

The official git repository for Contiki, the open source OS for the Internet of Things

http://www.contiki-os.org/

Other

3.71k stars 2.58k forks source link

sicslowpan input: Dropping 6lowpan packet that is not a fragment #1430

Closed neophob closed 8 years ago

neophob commented 8 years ago

I try to send rather large packages (payload between 500-900 bytes) to a jn5168 based node. It works mostly, but I also see some sicslowpan input: Dropping 6lowpan packet that is not a fragment error messages.

here are some config value we use in our project:

#define NETSTACK_CONF_MAC     csma_driver
#define NETSTACK_CONF_RDC     nullrdc_driver
#define NETSTACK_CONF_FRAMER  framer_802154

#undef UIP_CONF_BUFFER_SIZE
#define UIP_CONF_BUFFER_SIZE    1280
#undef UIP_CONF_ROUTER
#define UIP_CONF_ROUTER 0

#define COAP_RESPONSE_TIMEOUT       3

#define COAP_MAX_RETRANSMIT         3

One observation we made when the transmission fails is, that the sending UDP port is 40000+. I know this is a bit vague - do you have some hints where we could dig?

simonduq commented 8 years ago

Hello, This happens whenever receiving a fragment from a datagram other the one being currently reassembled. That is, if nodes are subject to too much load of fragmented traffic. Expected in the current implementation of 6lowpan. https://github.com/contiki-os/contiki/pull/1258 should help (if you try it out, please send an update on whether this helps or not).

joakimeriksson commented 8 years ago

Yes, this is a significant problem when sending fragmented packets. The fix is needed and as @simonduq says - please test and check that it gets better. That will help the merge team to pull it faster! I lost around thousand packets per day due to that type of problem in a 40 nodes network.

neophob commented 8 years ago

Thanks for the fast answers! I'll try to apply the patch and send feedback.

Just to make sure I understand the problem correctly. While I enabled 6lowpan fragmentation (and disabled ipv6 fragmentation) and I currently have one RPL and 1 node it's possible that the node receive a packed which is from another sequence? Maybe due a resend of an older package?

joakimeriksson commented 8 years ago

It might even be due to a single-frame RPL packet (e.g. routing control packets).

joakimeriksson commented 8 years ago

I guess this could be closed now? Did you test - if not the PR is in so just do a test with master and it should work better.

neophob commented 8 years ago

yes, can be closed - sorry for the delay