This refactors reception/decoding part of `gnrc_sixlowpan_iphc` to the
more layered approach modeled in #8511. Since the reception part is
already complicated enough I decided to divide send and receive up into
separate changes.
This refactors sending/encoding part of `gnrc_sixlowpan_iphc` to the
more layered approach modeled in #8511. Since the reception part is
already was pretty complicated to refactor, I decided to divide send
and receive up into separate changes.
This will be used in the IPHC refactoring to control the reassembly
buffer as a context.
I also adapted the name of `gnrc_sixlowpan_frag_gc_rbuf()` to be in
line with the rest of the newer functions.
While refactoring IPHC I noticed that the page actually can already be
used for fragmentation: Given @cgundogan's work on [ICN LoWPAN] we can
already assume, that the page context may (among other thing) determine
the type of the reassembled packet. This PR provides the basis for
that.
[ICN LoWPAN]: https://tools.ietf.org/html/draft-gundogan-icnrg-ccnlowpan-01
While the current approach for garbage collection in the 6Lo reassembly
buffer is good for best-effort handling of
*fragmented* packets and nicely RAM saving, it has the problem that
incomplete, huge datagrams can basically DoS a node, if no further
fragmented datagram is received for a while (since the packet buffer is
full and GC is not triggered).
This change adds a asynchronous GC (utilizing the existing
functionality) to the reassembly buffer, so that even if there is no new
fragmented packet received, fragments older than `RBUF_TIMEOUT` will be
removed from the reassembly buffer, freeing up the otherwise wasted
packet buffer space.
Since IPHC also manipulates the total number of bytes of a received
datagram (by decompressing it), this also needs to be exposed. I guess
I was too focused on introducing a *generic* packet buffer for a future
virtual reassembly buffer (where it isn't needed, but so isn't `pkt` to
be honest), that I totally forgot about it in #9352.
This refactors the `gnrc_sixlowpan_frag` module for the API proposed
in #8511.
The `ctx` for `gnrc_sixlowpan_frag_send()` is required to be a
`gnrc_sixlowpan_msg_frag_t` object, so IPHC can later on use it to
provide the *original* datagram size (otherwise, we would need to adapt
the API just for that, which seems to me as convoluted as this
proposal).
I also provide an expose function with a future possibility to provide
more than just one `gnrc_sixlowpan_msg_frag_t` object later on (plus
having cleaner module separation in general).
While working on #9352 I noticed that the order of members in the
`gnrc_sixlowpan_msg_frag_t` struct costs us 4 bytes in RAM due to byte
alignment. This PR fixes the order of members, so they are the most
packed.
This exposes the parts of the reassembly buffer to be usable as context
as proposed in #8511.
I only exposed *parts of* for two reasons:
1. I don't need to expose further types (like `rbuf_int_t`), that are
not of interest outside of fragmentation.
2. This allows for an easy future extension for the virtual reassembly
buffer as proposed in [[1]].
This makes this change a little bit more involved, because instead of
just renaming the type, I also need to add the usage of the `super`
member, but I think in the end this little preparation work will be
beneficial in the future.
[1]: https://tools.ietf.org/html/draft-watteyne-6lo-minimal-fragment-01#section-3
Summary:
Even ehen COMP is cleared, the algorithm always elides part of the address when a matching
context is found.
This behviour occurs because in the line
if ((src_ctx != NULL) || ipv6_addr_is_link_local(&(ipv6_hdr->src)))
the COMP bit is not tested.
This patch fixes the problem by setting [src|dst]_ctx to NULL if the
context must not be used.
If all rbuf slots are in use, `_rbuf_gc` removes the oldest entry even if the
entry for the current fragment exists. This effectively decreases usable slots
by one. This patch makes `_rbuf_gc` removes the oldest entry only if there is
no entry for the current fragment.
https://tools.ietf.org/html/rfc4944#section-5.3 says:
> If a link fragment that overlaps another fragment is received, as
> identified above, and differs in either the size or datagram_offset
> of the overlapped fragment, the fragment(s) already accumulated in
> the reassembly buffer SHALL be discarded. A fresh reassembly may be
> commenced with the most recently received link fragment.
When `gnrc_ndp_node_next_hop_l2addr` cannot resolve L2 address, it creates a
temporary neighbor cache entry with interface `KERNEL_PID_UNDEF` (unless the
interface is already known) to send a neighbor solicitation. When another packet
directed to the same address is going to sent before receiving a neighbor
advertisement, `gnrc_sixlowpan_nd_next_hop_l2addr` gets the temporary neighbor
cache entry and calls `gnrc_ipv6_netif_get` with `KERNEL_PID_UNDEF`, resulting
get a `NULL`. We must check `NULL` before dereference it.
FYI, both `gnrc_ndp_node_next_hop_l2addr` and
`gnrc_sixlowpan_nd_next_hop_l2addr` are enabled when
`gnrc_sixlowpan_border_router_default` module is enabled with `GNRC_NETIF_NUMOF`
is greater than 1:
gnrc_sixlowpan_border_router_default
→ gnrc_ipv6_router_default
→ gnrc_ndp_router (if GNRC_NETIF_NUMOF > 1)
→ gnrc_ndp_node
→ gnrc_ndp_node_next_hop_l2addr is called from _next_hop_l2addr
gnrc_sixlowpan_border_router_default
→ gnrc_sixlowpan_nd_border_router
→ gnrc_sixlowpan_nd_router
→ gnrc_sixlowpan_nd
→ gnrc_sixlowpan_nd_next_hop_l2addr is called from _next_hop_l2addr
