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.
The inclusion of `net/gnrc.h` in `net/gnrc/mac/types.h` header makes it
impossible to include the `net/gnrc/netif.h` header within
`net/gnrc/netif/hdr.h`, due to `net/gnrc/mac/types.h` being included
with `net/gnrc/netif/mac.h` (which is included in `net/gnrc/netif.h`)
While it is an edge case in our configuration it is technically
possible for a (6Lo) router not to maintain an address resolution state
machine. This fix allows for that with the `gnrc_ndp` module.
Check for:
- if it exists (critical error condition -- non-IPv6 headers should
not trigger these functions) => assert
- if it has a multicast source (that shouldn't really happen but
people might try weird stuff ;-)
- if it has an unspecified source (can't determine receiver of error
message => don't send it, don't build it)
sock_[udp|ip]_recv returns `pkt->size` after pkt was released via `gnrc_pktbuf_release(pkt)`.
This can result in wrong values returned by this functions and thus is not according to its sepecification.
Storing this values before releasing pkt returning the stored values should fix this.
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.
`_decapsulate()` is called by callees of `_receive()` so the call to
the latter function within the first creates a recursion we don't want.
Using `gnrc_netapi` instead removes that and provides the added benefit
that other subscribers to IPv6 are also informed.
Adds a gnrc_netif specific rawmode flag to indicate that the netdev
device is configured in raw mode. This flag is kept in sync with a
possible flag in the netdev device and should only be modified via the
setter call.
gnrc_sock_recv used to duplicate functionality of gnrc_ipv6_get_header,
but additionally checked whether the IPv6 snip is large enough.
All checks are now included in gnrc_ipv6_get_header, but as most of them
stem from programming / user errors, they were moved into asserts; this
constitutes an API change.
Our `gnrc_minimal` example configures the link-local address from the
IEEE 802.15.4 short address since it does not include 6Lo-ND.
This causes the application to be incompatible with our other GNRC
application that do include 6Lo-ND, since it [assumes][1] the link-local
address to be based on the EUI-64 for address resolution.
This enforces long addresses (aka EUI-64) for all IEEE 802.15.4 devices
when IPv6 is compiled in so `gnrc_minimal` is compatible again to the
rest.
Fixes#9910
[1]: https://tools.ietf.org/html/rfc6775#section-5.2
Currently the length of the full ICMPv6 packet is passed to the
validator function causing validation failures on valid packets. This
fixes that by passing the length of remaining RPL options of the packet.
The code originally assumed that the location of DIS struct is directly
after the ICMPv6 struct. This is not necessarily true when both structs
are individually allocated by pktbuf. This commit fixes this issue by
directly accessing the location of the DIS struct.
Linux doesn't have ARO support at the moment so this is a workaround to
try to speak 6Lo-ND while still being able to do DAD with a border
router that doesn't.
UDP port 0 is reserved for system usage, e.g., to tell the OS to
set a random source port. Hence, neither source nor destination
port should be 0 when transmitting. This PR adds proper asserts.
