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.
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)
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.
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
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.
While `tmp` in the loop for write-protection for the check-sum
calculation is used to check the return value of
`gnrc_pktbuf_start_write()`, it was never overwriting `payload` causing
the original snip to be used in the following iteration `prev` when
duplicated, and destroying the sanity of `ipv6`.
This refactors reception/decoding part of `gnrc_sixlowpan_iphc` to the
more layered approach modeled in #8511. Since the reception part is
already complicated enough I decided to divide send and receive up into
separate changes.
This refactors sending/encoding part of `gnrc_sixlowpan_iphc` to the
more layered approach modeled in #8511. Since the reception part is
already was pretty complicated to refactor, I decided to divide send
and receive up into separate changes.
This will be used in the IPHC refactoring to control the reassembly
buffer as a context.
I also adapted the name of `gnrc_sixlowpan_frag_gc_rbuf()` to be in
line with the rest of the newer functions.
This change is a gnrc_ipv6_nib/gnrc_netif(2)-based rework of #7210.
Packet duplication
==================
Its main optimization is that it restructures `gnrc_ipv6` handling of
sent packets so that duplication for write-protection happens at the
latest possible step:
* potential `gnrc_netif` headers added by upper layers are
write-protected before their removal
* This unifies the duplication of the IPv6 header directly after
that
* Extension headers in-between the IPv6 header and the payload header
are duplicated just before the check sum is duplicated
Especially the last point allows for only handing a single packet snip
to all lower functions instead of an already searched IPv6 header
(which now is always the first until it is handed to the interface) +
payload header.
Further clean-ups
=================
* Next-hop link-layer address determination was moved to the
`_send_unicast` function, greatly simplifying the unicast case in the
`_send` function
* Code for loopback case was added to a new function `_send_to_self`
* Removed some code duplication
While refactoring IPHC I noticed that the page actually can already be
used for fragmentation: Given @cgundogan's work on [ICN LoWPAN] we can
already assume, that the page context may (among other thing) determine
the type of the reassembled packet. This PR provides the basis for
that.
[ICN LoWPAN]: https://tools.ietf.org/html/draft-gundogan-icnrg-ccnlowpan-01
While the current approach for garbage collection in the 6Lo reassembly
buffer is good for best-effort handling of
*fragmented* packets and nicely RAM saving, it has the problem that
incomplete, huge datagrams can basically DoS a node, if no further
fragmented datagram is received for a while (since the packet buffer is
full and GC is not triggered).
This change adds a asynchronous GC (utilizing the existing
functionality) to the reassembly buffer, so that even if there is no new
fragmented packet received, fragments older than `RBUF_TIMEOUT` will be
removed from the reassembly buffer, freeing up the otherwise wasted
packet buffer space.
Since IPHC also manipulates the total number of bytes of a received
datagram (by decompressing it), this also needs to be exposed. I guess
I was too focused on introducing a *generic* packet buffer for a future
virtual reassembly buffer (where it isn't needed, but so isn't `pkt` to
be honest), that I totally forgot about it in #9352.
This refactors the `gnrc_sixlowpan_frag` module for the API proposed
in #8511.
The `ctx` for `gnrc_sixlowpan_frag_send()` is required to be a
`gnrc_sixlowpan_msg_frag_t` object, so IPHC can later on use it to
provide the *original* datagram size (otherwise, we would need to adapt
the API just for that, which seems to me as convoluted as this
proposal).
I also provide an expose function with a future possibility to provide
more than just one `gnrc_sixlowpan_msg_frag_t` object later on (plus
having cleaner module separation in general).
While working on #9352 I noticed that the order of members in the
`gnrc_sixlowpan_msg_frag_t` struct costs us 4 bytes in RAM due to byte
alignment. This PR fixes the order of members, so they are the most
packed.
This exposes the parts of the reassembly buffer to be usable as context
as proposed in #8511.
I only exposed *parts of* for two reasons:
1. I don't need to expose further types (like `rbuf_int_t`), that are
not of interest outside of fragmentation.
2. This allows for an easy future extension for the virtual reassembly
buffer as proposed in [[1]].
This makes this change a little bit more involved, because instead of
just renaming the type, I also need to add the usage of the `super`
member, but I think in the end this little preparation work will be
beneficial in the future.
[1]: https://tools.ietf.org/html/draft-watteyne-6lo-minimal-fragment-01#section-3
Otherwise, it may happen that `::` or a global address is chosen by
the IPv6 header fill function. Both types of addresses are
[not valid for RAs](https://tools.ietf.org/html/rfc4861#section-4.2)
Parts of [RFC4862] were already implemented when NDP via the NIB was
first implemented. This change just includes the DAD portion of
[RFC4862]. This should be enough to make RIOT fully RFC4862 compliant.
[RFC4862]: https://tools.ietf.org/html/rfc4862
If the payload length is zero and the next header field is not set to
NONXT, GNRC will interpret the current header as the payload because the
first snip is always interpreted as the payload. This can lead to loops
and or crashes.
When the payload length of an encapsulated IPv6 packet is 0, the
`_receive` function of IPv6 can be given a NULL pointer, causing the
IPv6 header checker to crash because of a NULL pointer dereference.
With the previous fix, we only have to register addresses that are not
VALID yet on reception of router advertisements. This removes the need
for the hacky `GNRC_NETIF_FLAGS_6LO_ADDRS_REG` flag that was only
introduced to prevent unnecessary re-registration.
The whole address registration looses its point if all addresses are
marked valid from the get-go. With this fix non-link-local addresses
are first marked TENTATIVE and only after successful registration
marked as VALID. Link-local addresses are assumed to always be VALID.
[RFC6775] only talks of *routers* processing router advertisements,
with regards of discarding them if they do not contain an ABRO.
Additionally, this change makes configuration of tests setups a lot
easier, where one note is a router distributing a prefix and the other
is a host to be configured with the RA. Just do the following on the
router:
```
> ifconfig <if> add <GUA>
> ifconfig <if> rtr_adv
```
e voilà! In current master both nodes would have needed to be compiled
with `GNRC_IPV6_NIB_CONF_MULTIHOP_P6C=0`.
[RFC6775]: https://tools.ietf.org/html/rfc6775#section-8.1.3
At the moment ping is crashing if one pings the loopback address.
This was caused in #8214 when we moved interfaces from `kernel_pid_t`
ID to pointer-based handling, since loopback doesn't evaluate to such
an interface.
This fix
* assures that the periodicity of the final router advertisements is
kept (so that no administrative change e.g. adding prefixes to the
prefix list causes additional RAs outside the rate limitation)
* removes all administrative options (PIO, ABRO, 6CO) from final router
advertisements (with router lifetime == 0)
I applied the following terminology and changed the wording in the doc
accordingly:
* must not: If the parameter is of the value it *must not* be it either
hits an assert or crashes the system.
* may not: The value can be that value, but the function will return an
error.
This renames the following functions
* `gnrc_netif_ipv6_addr_add()`
* `gnrc_netif_ipv6_addr_remove()`
* `gnrc_netif_ipv6_group_join()`
* `gnrc_netif_ipv6_group_leave()`
by appending the suffix `_internal`.
\## Reasoning
I'd like to provide a helper function for the *public* equivalent using
`gnrc_netapi_set()`, and those names are to nice to not be taken for
those.
\## Procedure
I used a combination of `git grep` and `sed` to do this and fixed the
alignment in the result of some cases by hand.
```sh
git grep --name-only "\<gnrc_netif_ipv6_\(addr\|group\)_\(add\|remove\|join\|leave\)\>" | \
xargs sed -i 's/\<gnrc_netif_ipv6_\(addr\|group\)_\(add\|remove\|join\|leave\)/\0_internal/g'
```
When a neighbor becomes UNREACHABLE which causes neighbor solicitations
to be send only up to every minute. If the medium is very busy this can
easily get lost, basically causing the neighbor never to be reachable
again from the perspective of the sending node. To fix this the backoff
is reduced to its start value, every time a packet is sent to that
neighbor.
This assertion doesn't make any sense. The function is called by
_copy_and_handle_aro() on a router which causes `nce` to be NULL
(because there is no NCE known yet) and then the function called
directly after (_reg_addr_upstream()) checks if `nce` might be NULL and
creates an NCE if necessary.
While the GNRC_IPV6_NIB_RTR_TIMEOUT is properly handled, it is actually
never fired. Moreover, the router lifetime is set, but never read.
This removes the router lifetime and switches it out for an evtimer
to does the GNRC_IPV6_NIB_RTR_TIMEOUT event.
When there are holes in the NIB (e.g. when entries were removed)
currently the NIB crashes the system due to a failed assertion
(`DEVELHELP` needs to be activated to test this behavior).
This fixes this behavior by making the assertion a check that is always
compiled in.
In the case that GNRC_IPV6_NIB_CONF_ARSM is set but
GNRC_IPV6_NIB_CONF_6LN is not, clang complains about
the function _get_l2addr_from_ipv6 never being used.
I couldn't easily figure out why this passes in Murdock,
but I'm guessing that clang is simply being smarter than
GCC. Can someone comment on whether there is a better fix
for this?
Relates to #6473
_is_reachable is only used when GNRC_IPV6_NIB_CONF_ARSM
is enabled, and as such it must be guarded so that clang
doesn't complain about a unused function in case
GNRC_IPV6_NIB_CONF_ARSM is not set
Similar to #7910
Relates to 6473
Since gcc-7 `Wimplicit-fallthrough` is activated by using `-Wextra`.
This leads to the following problem when compiling `gnrc_networking`:
```
RIOT/sys/net/gnrc/network_layer/ndp/internal/gnrc_ndp_internal.c: In function ‘gnrc_ndp_internal_set_state’:
RIOT/sys/net/gnrc/network_layer/ndp/internal/gnrc_ndp_internal.c:106:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
t = ipv6_iface->reach_time;
~~^~~~~~~~~~~~~~~~~~~~~~~~
RIOT/sys/net/gnrc/network_layer/ndp/internal/gnrc_ndp_internal.c:109:9: note: here
case GNRC_IPV6_NC_STATE_DELAY:
^~~~
```
The fall-through in this code is intentional. There are several ways to
warn the comiler about such intentional fall-throughs, which include
e.g. attributed empty statements (`__attribute__ ((fallthrough));`).
I don't like tis approach however. The best way would probably be to
remove this fall-through from the code. However, to keep the diff
minimal, and since ndp will change in the future, I went for warning
the compiler using comments.
The compiler checks comments for several *fall through* regexs to
decide whether a fallthrough was intentional or not.
You can read more about this gcc option in [1]. A note about
fallthrough comment regexs is at the bottom of this article.
[1] https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
Summary:
Even ehen COMP is cleared, the algorithm always elides part of the address when a matching
context is found.
This behviour occurs because in the line
if ((src_ctx != NULL) || ipv6_addr_is_link_local(&(ipv6_hdr->src)))
the COMP bit is not tested.
This patch fixes the problem by setting [src|dst]_ctx to NULL if the
context must not be used.
Upper layers might want to utilize the flags (e.g. to tell 6LoWPAN to elide
UDP checksums). This change allows for this by copying non-addressing related
flags to the address resolution generated netif header from the user generated
netif header.
This is a temporary quick-fix for #5122 to not have GUAs removed on an
interface.
It solves the issue by both not letting the registration run out on the router
and by not letting the lifetime of an auto-configured address expire.
