The following functions can now be wrapped around the more generalized
approach:
- gnrc_netif_ipv6_iid_from_addr()
- gnrc_netif_ipv6_iid_to_addr()
- gnrc_netif_ndp_addr_len_from_l2ao()
- gnrc_netif_eui64_from_addr()
According to the documentation of `gnrc_ipv6_nib_get_next_hop_l2addr()`
`pkt` may be `NULL`. However, whenever that function sends an error
message (the methods for that require `orig_pkt` not to be NULL) `pkt`
is not checked, which may lead to failed assertions.
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.
Size 0 snips are legal packet snips (empty payload e.g.) so it doesn't
make sense to issue an error in the write-protection in that case.
API documentation doesn't mention it either and the tests still pass
with the check removed.
Size 0 snips are legal packet snips (empty payload e.g.) so it doesn't
make sense to issue an error in the write-protection in that case.
API documentation doesn't mention it either and the tests still pass
with the check removed.
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
With `DEVELHELP` activated all required options required by GNRC are
now checked at interface initialization, so that developers of new
link-layer protocols or device drivers notice as soon as possible that
something is missing.
Currently the constructed NA for a delayed NA case is neither used nor
released nor does it get an IPv6 header to be used properly. This fixes
that case.
When working on the previous commit I was unsure if a
garbage-collectible entry should remain in the list, so I added this
comment so I don't have to wonder about this in the future ;-).
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.
The `_next_removable` list manages the cache-out of the neighbor cache.
However, when a neighbor cache entry is removed, it is not removed
from that list, which may lead to a segmentation fault when that list is
accessed, since the whole entry (including its list pointer) is zeroed
after removal.
With this change the entry is removed from that list accordingly before
the zeroing happens.
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.
This the first step in moving the collection of layer 2 netstats from
the low level driver to a central location, ie. gnrc_netif, to avoid
code duplication.
`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.
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.
