`gnrc_networking` is unusable when compiled for boards that do not have
any network devices on-board due to an assertion in RPL's auto-init. I
think this is pretty harsh. A friendly info message is enough, as it
might not even be an error. Also, if one expects RPL to work without
network interfaces they are a fool ;-).
Once the packet buffer is full on heavy network load, gnrc_netif_hdr_build may return NULL. In that case, the following unchecked access to hdr->data leads to a crash.
`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.
When a new queue entry is tried to be allocated for a neighbor who's
address is currently tried to be resolved there was no error case
before. The packet that was tried to be put in the queue was thus not
released and stayed in the packet buffer for ever.
This is just a compatibility issue waiting to happen as soon as there
is support for a more standard-compliant implementation of BLE (like
e.g. NimBLE ;-)).
The function to infer the link-layer address length from the length of
a S/TLLAO is very dependent on the IPv6 over X specification and thus
should be grouped with the other IP over X functions.
Use the `gnrc_netif_t::pid` member instead of the pid of the current thread when generating the the `gnrc_netif_hdr` in `gnrc_netif_ieee802154::_recv` function.
Use the `gnrc_netif_t::pid` member instead of the pid of the current thread when generating the the `gnrc_netif_hdr` in `gnrc_netif_ethernet::_recv` function.
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 having a non-6LN interface and a 6LN interface (e.g. on a border
router) the assertion can hit when a Router Advertisement is received.
This makes the check an `if` statement rather than an assertion, to
account for that case.
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
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.
