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.
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.
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>
Since the recursion into `gnrc_ipv6_demux()` was removed in
`gnrc_ipv6_ext`, `gnrc_ipv6.c` is the only user of this function,
so it can be made private. It was only made public so it can be used
from `gnrc_ipv6_ext`.
As `pkt` isn't pre-parsed the write-protection of *the whole* packet
(except the netif-header) comes for free, when this was done in the
receive routine of IPv6.
Since with #10233 we now assume IPv6 packets always to not be
pre-parsed, we can iterate over the extension headers by gradually
"eating" them away. This allows us to move the iteration over them
out of `gnrc_ipv6_ext_demux()` and into `gnrc_ipv6_demux()`.
By moving the iteration over all extension headers out of
`gnrc_ipv6_ext_demux()` we also can
1. simplify the extension header handling a lot, as it now
just a loop inside `gnrc_ipv6_demux()`,
2. remove the recursion to `gnrc_ipv6_demux()` within
`gnrc_ipv6_ext_demux()`.
Since the packet is now guaranteed to be preparsed, the currently
handled IPv6 header will always be in the first snip. Because of this
the packet parser can't get confused anymore which IPv6 header is the
one to be handled so we don't need to remove the more outer ones.
Because of this we can just use the normal packet dispatching (which is
already used by other `GNRC_NETTYPE_*`-known protocol numbers such as
UDP).
This also reverts d54ac38f84.
Though this change might seem more complicated, it has the benefit, that
after #9484 we don't have to assume that a received packet within IPv6's
receive function can be handed to the function pre-parsed, making that
function far less complicated (will be provided in a future PR).
Also this might give the forwarding via routing header a little
performance boost, as we now don't *receive* the packet first only to
forward it later-on.
Without this the first packet to a new link-local address will not be
delivered in non-6Lo environments, since the interface is not provided.
With this change, if an internet was provided to the address resolver it
will be stored within an allocated `gnrc_netif_hdr_t`.
At this point [IPv6 already striped](netif strip) the packet of its
netif header, so there is no risk that there will be to, in case it was
provided and the `netif` came from its existence.
