gnrc_sixlowpan_frag: initial import of Selective Fragment Recovery

[miri64]

Contribution description

This provides an implementation for 6LoWPAN Selective Fragment Recovery (SFR), an alternative fragmentation protocol for 6LoWPAN, which allows for end-to-end recovery and congestion control (currently not implemented) for fragmented IPv6 datagrams.

Testing procedure

There is still a lot of more in-depth testing required including a dedicated test application (this is why is it still WIP), but you can compile examples/gnrc_networking with SFR already for a 6LoWPAN-capable board:

USEMODULE="gnrc_sixlowpan_frag_sfr" BOARD=samr21-xpro make -C examples/gnrc_networking flash term

and then ping another node also shipping with gnrc_sixlowpan_frag_sfr:

ping6 -s 1232 fe80::7b65:822:8693:9d5a

[edit]: after posting this PR, I noticed, that there is a leak in the packet buffer after this... All the more reason why this is still WIP[/edit]

There are also tests that should pass on a board of your choice:

BOARD=... make -C tests/gnrc_sixlowpan_frag_sfr -j flash term

Issues/PRs references

Requires #12220 (merged), #12559 (merged), #12629, #12845, and #12848 (merged):

[miri64]

Some thoughts from my subway ride home ;-)

[miri64]

Rebased to current to include #12653 for make debug ;-)

[miri64]

Rebased to current master as #12220 and #12559 got merged.

[miri64]

Ok, I now can ping with huge datagrams in "rapid" (200ms as this is the estimate RTT) intervals without any crashes or leaks between two nodes. I'm not 100% sure resending is working as it should be. Further testing will show this hopefully. Next: actual forwarding.

[miri64]

Forwarding is now also working. There is still some weirdness happening with the ACKs and retries (I'm not sure if there is >1 retry made and the ACK timeout is restarted after it was fired even though the datagram is complete)... Will investigate this next week.

[miri64]

the ACK timeout is restarted after it was fired even though the datagram is complete

At least this I found now.

[miri64]

Rebased to current master

[miri64]

Rebased to current master and dependencies.

[miri64]

Added first round of tests.

[miri64]

I have full test coverage now (at least as far as I can judge without a coverage tester right now 😅). On native they succeed, bur are still a bit flaky, on iotlab-m3 and samr21-xpro they reliably fail. I will investigate what's up next. If that is found, I think I can remove the WIP label. @cgundogan may I squash before that?

[miri64]

On native they succeed, bur are still a bit flaky, on iotlab-m3 and samr21-xpro they reliably fail. I will investigate what's up next. If that is found, I think I can remove the WIP labe

And done. It was in the end as I suspected a timing issue with the ARQ timeout.

[miri64]

Seems only to happen with netdev tests though, so might be caused by some dependency re-ordering.

IIRC there is no netdev-related dependency stuff happening in this PR. So this must be some weird side effect of unexpected netdev dependencies then ;-).

[miri64]

Mhhh the Murdock errors seem to be something related to gnrc_netif pulling in SFR headers, pulling in evtimer, pulling in xtimer and then xtimer having some messed up definitions. Not really sure exactly what is happening here... This used to work. Maybe @maribu or @kaspar030 can help?

[miri64]

Fixed static tests and squashed fixes in the meantime.

[miri64]

The problem with examples/nanocoap_server was also legitimate. Fixed and squashed.

[miri64]

If that was @benpicco's intention: the problem is not fixed when merging #15627 :-/

[miri64]

1. There was a rebase error, that un-guarded the xtimer.h include in gnrc_netif.c
2. If I #if IS_USED(...) guard the sfr.h include, tests/driver_w5100 compiles for waspmote-pro now. It is only used to call the interface-specific init function of SFR, so I think the pre-processor magic is small enough. Still would be interesting why without 6LoWPAN and xtimer compiled in, ztimer-only boards have problems compiling such a combination...

[maribu]

2. Still would be interesting why without 6LoWPAN and xtimer compiled in, ztimer-only boards have problems compiling such a combination...

The issue is that the ztimer-only boards cannot function with plain xtimer, due to incompatible clock frequency. To fix that, there is an

ifneq (,$(filter xtimer,$(USEMODULE)))
  USEMODULE += xtimer_on_ztimer
endif

There is a compile time check via preprocessor that gets run when including xtimer.h that verifies that the XTIMER_HZ value is correctly set and compatible. Since boards incompatible with xtimer cannot provide a compliant value for them, this check will fail. However, if xtimer_on_ztimer is used, that check is skipped - ztimer can manage any timer frequency.

So the include to xtimer.h only works for those boards, if xtimer_on_ztimer is used - which is for those boards automatically done if xtimer is used.

[miri64]

So the include to xtimer.h only works for those boards, if xtimer_on_ztimer is used - which is for those boards automatically done if xtimer is used.

So the conclusion is: if xtimer.h is included without the xtimer module compiled in, for those boards that are incompatible to xtimer, the compilation fails :-) (as xtimer_on_ztimer is not automatically included to fix the situation).

[miri64]

And some more bugs found by the compile tests fixed and squashed.

[benpicco]

Did some testing (only single hop) and fragmentation works between two 6lo nodes with SFR enabled.
As expected fragmentation does not work between a SFR node and a 'classic' node, not sure if we should add that to the documentation.

Two nodes with 'classic' fragmentation can still communicate as before.

[miri64]

As expected fragmentation does not work between a SFR node and a 'classic' node, not sure if we should add that to the documentation.

Will add a note.

[miri64]

Done.

[miri64]

🎉 Thanks for the review and your input @benpicco