45f7966 made the `src_len` field the "emptiness signifier" for the VRB.
However, when `gnrc_sixlowpan_frag` is compiled in, the remove function
`gnrc_sixlowpan_frag_vrb_rm()` does not set the `src_len` to zero,
resulting in already deleted entry to be recognized as non-empty.
This allows to set a timer between the completion of a datagram in the
reassembly buffer and the deletion of the corresponding reassembly
buffer entry. This allows to ignore potentially late incoming link-layer
duplicates of fragments of the datagram that then will have the
reassembly buffer entry be blocked.
This was noted in this [discussion] for classic 6LoWPAN reassembly (and
minimal fragment forwarding) and is recommended in the current
[selective fragment recovery draft][SFR draft].
[discussion]: https://mailarchive.ietf.org/arch/msg/6lo/Ez0tzZDqawVn6AFhYzAFWUOtJns
[SFR draft]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-07#section-6
cd1ce6b98d accidentally disabled generating documentation for
`xtimer_msg_*()` functions.
Always define those functions when building the documentation.
This imports the protocol parameters for Selective Fragment Recovery
(SFR). For the values I took some educated guesses based on my
experience with previous experimentation with fragment forwarding.
The defines currently are based on [draft v7].
[draft v7]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-07#section-7.1
fixup! gnrc_sixlowpan_frag: initial import of SRF parameters
The name `fragment_msg` or `frag_msg`/`msg_frag` always to me was a bit
misplaced, as it basically implements an asynchronous fragmentation
buffer and doesn't necessarily have anything to do with messages.
This change
1. changes the name to `fb` (for fragmentation buffer)
2. factors its code out to its own sub-module so it can be re-used by
other 6LoWPAN fragmentation schemes like [Selective Fragment
Recovery]
[Selective Fragment Recovery]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-05
This module was intended to be a test framework for GNRC but it never
really got used. It was not maintained for 3 years. It will be removed
after 2020.07 release at the latest.
Added a header to allow defining C interfaces using the default C11 atomic
types. Those types are however fully opaque and inaccessible from C++, as C11
atomics are completely incompatible with C++.
The functions now are semantic distinct:
- gnrc_netif_is_6lo(): the interface is a 6Lo interface
- gnrc_netif_is_6ln(): the interface is using Neighbor Discovery
according to RFC 6775
Preparation step to introduce a semantic difference between an
interface being a 6Lo interface and a 6LN according to RFC 6775 [[1]]
(i.e. performs Neighbor Discovery as defined there).
[1]: https://tools.ietf.org/html/rfc6775#section-2
