Not only does this leave open a risk to crash the node for the check
in `_compressible()` but also is the `tmp` check below getting confused
when `ptr` is `NULL`, since `gnrc_pktbuf_start_write()` returns `NULL`
in that case.
With newlib nano-specs the debug output without this change will be
6lo: dispatch 0hx ... is not supported
With this PR this will provide a correct output, e.g.
6lo: dispatch 0x3f ... is not supported
Fragment size calculation previously failed for devices that are able to
transmit bigger layer 2 PDUs that 802.15.4 devices. This commit fixes the issue.
When either `gnrc_sixlowpan_iphc_nhc` or `gnrc_udp` is not compiled
in `_compressible()` never returns `true`. This causes the
`dispatch` snip in `gnrc_sixlowpan_iphc_send()` to be of length 0,
meaning `dispatch->data` is `NULL`, causing possible crashes when
trying to send IPv6 packets over 6LoWPAN without NHC or UDP.
`gnrc_sixlowpan_frag` internally derives the offset value directly
from the fragment header, so for normal usage within GNRC this
assertion is redundant, but to make the tests of `rbuf_add` 100%
water-tide I added it.
Currently the loop just continues to run after a viable type is found.
In #10851 this lead to a crash of the tests, when the dependency of
`gnrc_sixlowpan` to `gnrc_ipv6` was removed.
While the recursion in `gnrc_sixlowpan_frag` shouldn't be infinite we
still should avoid using recursions in general (also to be able to
statically analyze stack usage). This unrolls the recursion.
When issueing the sending of the next fragment the current version of
`gnrc_sixlowpan_frag` doesn't check if the queue is full. This leads to
leakage of the packet buffer, since when it is full, the package never
gets released.
This change adds a checks and error exits in case the queue is full.
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
