gnrc_sixlowpan_frag: initial import of minimal forwarding

[miri64]

Contribution description

This implements minimal fragment forwarding for GNRC.

Testing procedure

There is a test application tests/gnrc_sixlowpan_frag_minfwd. Having a set-up with >2 nodes and forward packets between them should also work, but for some reason (I suspect the radio) it doesn't work that well at the moment. Once I find out why, I will update the PR and the testing procedures accordingly (see #11256 for what I found out).

examples/gnrc_networking should work as normal on a 6LoWPAN compatible board when not using gnrc_sixlowpan_frag_minfwd and when using the module both with fragmentation (packet size >100) or without.

Issues/PRs references

Depends on #11000, #11061, #11063, #11164, #11182, #11263, #11264, and #12629 (all merged):

[miri64]

Rebased to current master and #11063 to resolve conflict caused by merging #11135.

[miri64]

With the latest addition of #11164 as a dependency and the other fixes I am able to forward, at least when debug output is activated ... I'm not able to forward without it yet though :-(. I will for now first add some test-cases for the bugs I found in the real-world application, and then try to find the bug.

[miri64]

OK, I got one successful send (out of 15 so far) :(

[miri64]

In #11068 (comment) I wrote:

With the latest addition of #11164 as a dependency and the other fixes I am able to forward, at least when debug output is activated ... I'm not able to forward without it yet though :-(. I will for now first add some test-cases for the bugs I found in the real-world application, and then try to find the bug.

Some intensive days of hardware debugging later (thank you @PeterKietzmann for all the help and patience) we figured out what happens: appearently most of the time the framebuffer of the driver is overridden with the send data of the forwarded fragment, after the next fragment is received. I'll open a separate issue to explain this in a bit more detail.

[miri64]

Rebased and adapted for current master and dependencies (including new dependencies #11263 and #11264)

[miri64]

Rebased to include current RC (so I can refer to the 2019.04 release for my experiments)

[miri64]

And rebased once again to include fix in gnrc_netif

[miri64]

Set to WIP because I added some stuff that does not belong with this PR and need to be factored out.

[miri64]

• how many reassembly buffers can there?

Until the RAM is full, I'd say. The number is capped of by CONFIG_GNRC_SIXLOWPAN_FRAG_RBUF_SIZE.

• Will we wait a bit before sending the next fragment, so not to immediately cause a collision with the retransmission from the next hop?

That's basically what is done in SFR (#12648). One could add this as a feature generally to 6LoWPAN, but I rather would do it in a separate PR and when we go into congestion control.

I didn't check yet, but I guess there is no effect on code size / behavior if the module is not used.

Should be, yes.

[miri64]

Pushed everything. Please check, if everything was addressed.

[miri64]

Should have at least compile tested before pushing ^^"

[benpicco]

Please squash!

[miri64]

Squashed!

[benpicco]

Squashed!

almost 😉

[miri64]

Oh, there I seemed to have referenced a commit foreign to this PR (used git blame to identify it) Will see where I put it :D

[miri64]

Fixed!

[benpicco]

I didn't test multi-hop fragmenting since I don't have a test setup for that (already thought of extending the zep_dispatcher), but I rely on your extensive testing documented in your paper.

I can confirm that there are no regressions when the module is not used, so ACK.

[miri64]

Fixed and squashed the one doxygen error caused by a legacy name.

[benpicco]

ah looks like the test will need a Makefile.ci.
Do we have a script yet to generate that automatically, like add_insufficient_memory_board.sh?

[miri64]

And added boards that are to small to Makefile.ci to make Murdock happy.

[miri64]

Do we have a script yet to generate that automatically, like add_insufficient_memory_board.sh?

Murdock reported 35 boards. Most GNRC applications list 35 boards in their Makefile.ci, so I just copied it from tests/gnrc_dhcpv6_client. Chances are, those are the same boards ;-).

[miri64]

Finally 🎉