Co-Authored-By: zhuoshuguo <zhuosgzju@gmail.com>

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.

"val = -val" causes UB for INTMIN, thus explicitly cast to unsigned.

Without this patch _len_get reads one byte beyond the con->rxbuf
if the incoming packet consists only of the byte 0x01.

Otherwise duplicate fragments are added to the number of already
received datagram bytes in L153 leading to possible race-conditions.

Otherwise it gets never released

Co-Authored-By: Gunar Schorcht <gunar@schorcht.net>

This way the IID generation gets much simplified and code duplication
is avoided since it removes GNRC's requirement for NETOPT_IPV6_IID.

Fixes #10739

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>

The `l2addr` and `l2addr_len` members of the `gnrc_netif_t` struct did
not show up in the rendered documentation.