kw2xrf: packet loss when packets get fragmented

[cgundogan]

I realised that packets with big payloads get lost after they get fragmented by sixlowpan.
Reproduce:
Ping from a pba-d-01-kw2x board to a samr21-xpro board:
ping6 1 beef::1 59 0 will work
ping6 1 beef::1 60 0 will fail (fragmented)

Surprisingly, enabling DEBUG output of sixlowpan "fixes" that error, so it seems to be a race or timing related thing in the driver.

[PeterKietzmann]

If I see it correctly the send function is not guarded for ongoing transmissions (or other transactions). I think (as I don't really know the state machine) the correct way would be split the function kw2xrf_set_sequence into a "preparation" part to act as a guard and a separate execution function to trigger the actual transmission in case of making use of the pre-loading option.

Placing kw2xrf_set_sequence (as done in #4844) or simply adding a delay at the beginning of the send function prevents from the described misbehaviour. That strengthens my above described assumption. @jfischer-phytec-iot could you please have a look at it as you know the internals of that device best? I will merge #4844 for now to fix the bug but would be nice to have an efficient solution.

[jfischer-no]

#5469 should fix it

[miri64]

Can somebody confirm?

[smlng]

@miri64: yes I can. I tested #5469 and besides its adoption of netdev2 it also helps to resolve this issue. However, @jfischer-phytec-iot wanted to work on the said PR a little more - I'd like to merge that one ASAP, though.

[miri64]

Than discuss there please!

[OlegHahm]

What's up here?

[smlng]

close as soon as #5469 is merged

[PeterKietzmann]

To me it seems #5469 does not fix this issue. @smlng please re-check.

[PeterKietzmann]

I meant the follow-up PR #6453

[cgundogan]

@smlng @PeterKietzmann what's the status on this?

[smlng]

good question -care to check while you are running your own tests anyway 😉 ?

[smlng]

would be great, if you ( @adrianghc ) can test with other RIOT boards, i.e., samr21-xpro would be a good start. Linux/RasPi is a different story anyway ...

[adrianghc]

I've just tested with the samr21-xpro with the same result.

[miri64]

I just tested it with #5469 (which was said to fix the issue) as of the state on closing of that PR, but the same problem as on master exists. As soon as it reaches a certain size I don't receive a packet at the other end anymore (with ping6 that number is 92). I analyzed the problem from multiple sides:

1. Rebasing kw2xrf: adaption to netdev2 #5469 to maybe find the fix. Except for non-substential changes (netdev2 naming, introduction of luid in master and a little different usage of the GPIO and SPI API [most likely to updates on that side]) there is no difference however.
2. Sniffing the traffic
3. Debug output in the driver (in combination with sniffing)

While (as already stated) (1) had proven to be fruitless, (2) and (3) revealed that, though fragmentation is initiated and the driver actually receives the packets, only the first fragment is send (resulting in it being dropped by the receiver, since no subsequent fragments are received for reassembly). The reason is this line.

[miri64]

(Digging even deeper: seq is XCVSEQ_TX_RX at this point, which is why kw2xrf_can_switch_to_idle() returns 0).

[miri64]

@smlng maybe you can do similar steps and find out, what your board is doing differently and why.

[miri64]

@adrianghc a really shitty workaround would be to apply the following patch

diff --git a/sys/net/gnrc/network_layer/sixlowpan/frag/gnrc_sixlowpan_frag.c b/sys/net/gnrc/network_layer/sixlowpan/frag/gnrc_sixlowpan_frag.c
index d3c89a1..7d1fbcf 100644
--- a/sys/net/gnrc/network_layer/sixlowpan/frag/gnrc_sixlowpan_frag.c
+++ b/sys/net/gnrc/network_layer/sixlowpan/frag/gnrc_sixlowpan_frag.c
@@ -26,6 +26,7 @@
 #include "utlist.h"
 
 #include "rbuf.h"
+#include "xtimer.h"
 
 #define ENABLE_DEBUG    (0)
 #include "debug.h"
@@ -256,6 +257,7 @@ void gnrc_sixlowpan_frag_send(gnrc_sixlowpan_msg_frag_t *fragment_msg)
         thread_yield();
     }
     else {
+        xtimer_usleep(4317);
         /* (offset + (datagram_size - payload_len) < datagram_size) simplified */
         if (fragment_msg->offset < payload_len) {
             if ((res = _send_nth_fragment(iface, fragment_msg->pkt, payload_len, fragment_msg->datagram_size,

With this I was able to send out at least two fragments (with a significant increase of latency of course and risk of missing reception of course too), which is at max. 176 bytes and should be enough for your use-case. For more set a higher sleep period.

[miri64]

#8304 only says it partly fixes this issue, so I re-open again, in case it still prevails (please test).

[PeterKietzmann]

I said "partly" because pings with payloads greater than 900B (or so) did still not succeed. Maybe another issue which we need to figure out.

[miri64]

I said "partly" because pings with payloads greater than 900B (or so) did still not succeed. Maybe another issue which we need to figure out.

I can think of multiple reasons for that (apart from broken driver):

• Packet loss of 10% (900 B are already ~10 packets)
• Wrongly set MTU

[miri64]

However, I agree that it is most likely that this hints at a totally different error class. So please open a new issue with your report regarding the remaining issues.