gnrc_sixlowpan_frag: initial import of minimal forwarding#11068
gnrc_sixlowpan_frag: initial import of minimal forwarding#11068benpicco merged 10 commits intoRIOT-OS:masterfrom
Conversation
93d3b6c to
6542506
Compare
2e4c0ad to
e64b92b
Compare
|
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. |
|
OK, I got one successful send (out of 15 so far) :( |
66e2538 to
e19efcd
Compare
|
In #11068 (comment) I wrote:
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. |
e19efcd to
f9326d4
Compare
1596f20 to
9ef5f1d
Compare
91032ad to
189ff58
Compare
|
Rebased to include current RC (so I can refer to the 2019.04 release for my experiments) |
|
And rebased once again to include fix in |
496d05c to
9d835f2
Compare
|
Set to WIP because I added some stuff that does not belong with this PR and need to be factored out. |
Until the RAM is full, I'd say. The number is capped of by
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.
Should be, yes. |
|
Pushed everything. Please check, if everything was addressed. |
|
Should have at least compile tested before pushing ^^" |
|
Please squash! |
|
Squashed! |
229459b to
c8ef052
Compare
almost 😉 |
|
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 |
c8ef052 to
2c35465
Compare
|
Fixed! |
There was a problem hiding this comment.
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.
2c35465 to
3a90dc2
Compare
|
Fixed and squashed the one doxygen error caused by a legacy name. |
|
ah looks like the test will need a |
When a VRB entry exists use minfwd to forward. When a route exist for the first fragment received in reassembly create a virtual reassembly buffer entry.
This is only the case when minfwd is compiled in.
3a90dc2 to
e70a42c
Compare
|
And added boards that are to small to |
Murdock reported 35 boards. Most GNRC applications list 35 boards in their |
|
Finally 🎉 |
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_networkingshould work as normal on a 6LoWPAN compatible board when not usinggnrc_sixlowpan_frag_minfwdand 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):