rpl-border-router + TSCH: corrupted payloads

[thvdveld]

When using the RPL border router, using TSCH, packets get corrupted when fragmented by 6LoWPAN.

Setup

• A RPL border router using RPL classic (I think this does not matter) and using TSCH (with the default scheduler)
• connected to a computer using tunslip6. We only tested using the Zolertia RE-Mote and the firefly's (they are the only platforms we have).
• A receiver node that has a UDP socket listening on some port.

Reproduction

1. Once the network is stable, we send big packets (using nc), for example 512 bytes, from the computer to the receiver node.
2. Packets over SLIP seem to look fine.
3. Packets transmitted by the radio are corrupted on the network layer. The UDP checksum is wrong (in Wireshark). We investigated this, and we found out that the checksum value was correct, however, the data that was in the 6LoWPAN fragments was incorrect. The corruption also happens when unfragmented packets are transmitted in a very high rate.

The following image is an image from the radio traffic (where the checksum is incorrect):

The (correct) payload we used was:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi dapibus varius arcu, ut pulvinar tellus commodo ut. Mauris condimentum sed massa ac interdum. Duis eu fermentum lectus. Nullam hendrerit ultrices consectetur. Quisque in orci lectus. Aliquam non imperdiet enim, non lacinia nisl. Donec sit amet dui fermentum, lacinia enim in, dictum elit. Integer quis tempus magna, id consequat ex. Sed id tempor massa, sit amet posuere dolor. Integer sodales, augue non malesuada luctus, justo erat gravida ligula.

The data actually in the UDP payload (when using the radio):

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi dapibus varius arcu, ut pulvinar tellus commodo ut. Mauris condimentum sed massa ac interdum. Duis eu fermentum lectus. Nullam hendrerit ultrices consectetur. Quisque i Aliquam non imperdiet enim, non lacinia nisl. Donec sit amet dui fermentum, lacinia enim in, dictum elit. Integer quis tmpus magna, id consequat ex. Sed id tempor massa, sit amet posuere dolor. Integer sodales, augue non malesuada luctus, justo erat gravida ligula.

The radio payload removed some parts, which are in italic/bold in the correct payload. The radio payload also contained extra 0's to make up for what it removed.

Note that this is just an example and that the behavior is kind of random. The radio never removed data from the same places. Sometimes it also just adds data. Here is another example:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbs arcu, ut pulvinar tellus commodo ut. Mauris condimentum sed massa ac interdum. Duis eu fermentum lectus. Nullam hendrerit ultrices consectetur. Quisque in orci lectus. Aliquam non imperdiet enim, non lacinia nisl. Donec sit amet dui fermentum, lacinia enim in, dictum elit. Integer quis teInteger quis tempus magna, id consequat ex. Sed id tempor massa, sit amet posuere dolor. Integer sodales, augue non malesuada luctus, justo erat gravida ligula.

In this packet "i dapibus variu" is missing and "Integer quis te" was added.

When using CSMA instead of TSCH everything seemed to behave correctly. So we suspect that something is iffy with the SLIP + BORDER_ROUTER + TSCH combination.

Can someone confirm that they can reproduce this issue?

Maybe the source of the issue is the same as in #2381?

---

Update 1: We now used a nRF52840-DK as border router: we see the same behavior on this device.

Update 2: After the full packet is received over slip, we print out the UIP_BUF. The content is already corrupted here. So we suspect the problem is when we are handling the bytes received from SLIP.

Update 3: If sending small packets, but quickly after each other, theses one byte UDP payloads are also corrupted.

[dianadeac]

This pull request seems related #1399