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.
Add additional checks to the port number parsing in str2ep to validate
the port number supplied in the string. This only verifies that the port
number is no longer than 5 chars and the resulting number fits in a
uint16_t.
It is still possible to supply up to 5 random chars.
URLs without a path were treated as invalid, while according to the URL
specification they are valid
Also fixes a missing null terminator in the returned path
On a NETOPT_STATE set call with NETOPT_STATE_RESET the netdev device
resets the callback event flags. This requires that after the netdev
device resets, the network stack also reapplies these callback event
flags
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 fixes an alignment issue I encountered in the static version of
the packet buffer.
The bug is caused by a race-condition where a certain order of
operations leads to a chunk being released according to the
byte-alignment of the platform, but overlapping potential space for
a future `_unused_t` struct e.g. (x mark allocated regions):
Future leak of size sizeof(_unused_t) Time
v |
+------------+-----+--------------------+ |
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| +
+------------+-----+--------------------+ |
|
+------------+--+--+--------------------+ |
| |xxxxxxxxxxxxxxxxxxxxxxx| +
+------------+--+--+--------------------+ |
|
+-----+------+--+--+--------------------+ |
|xxxxx| |xxxxxxxxxxxxxxxxxxxxxxx| +
+-----+------+--+--+--------------------+ |
|
+-----+------+-----+---------+----------+ |
|xxxxx| |xxxxxxxxxx| +
+-----+------+-----+---------+----------+ |
|
+-----+------+-----+--------------------+ |
|xxxxx| |xxxxxxxxxxxxxxxxxxxxxxxxxx| +
+-----+------+-----+--------------------+ |
|
+------------+-----+--------------------+ |
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| +
+------------+-----+--------------------+ |
|
+------------+-----+--------------------+ |
|xxxxxxxxxxxxxxxxxx| | +
+------------+-----+--------------------+ |
|
+------------+-----+--------------------+ |
| |xxxxx| | +
+------------+-----+--------------------+ |
v
Sadly, I wasn't able to create a reproducable unittest that show-cases
this corner-case, since I don't understand the order of operations that
cause this one 100%, but the bug is reproducable (but also not
reliably) by sending large (i.e. fragmented) packets to a 6Lo-enabled
host from more than 1 host simultaneously (use `gnrc_pktbuf_cmd` to
check).
By making the size of `_unused_t` the only condition for alignment,
this bug is fixed.
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
Fix re-register when using the same token.
Handle edge cases when change token for a resource.
Only set observer and resource on initial registration.
Discuss re-registration in documentation.
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
With #9209 gCoAP got the ability to re-register and OBSERVE with a new
token, sadly the `observer` variable wasn't set in that fix, so a
re-registration actually led to the deletion of the observer (because it
is still `NULL` when the old registration is overwritten in l. 317)
Currently, `gnrc_pktdump` only prints the header part of a snip.
However, if the snip wasn't parsed yet by the corresponding GNRC
module (or the module doesn't exist because the node is e.g. just a
forwarder), additional data might not be printed.
This makes it hard to analyze the data properly (sometimes you not only
want to know where the IPv6 packet is supposed to go, you also want to
know what's in it). So this just prints the rest of the snip as a hex
dump.
The nanocoap_get function is refactored to split of the request part
into a separate function for reuse by other modules. Support for
retransmissions when the received frame is malformed is dropped as it
was broken anyway.
The "new" forwarding table does not update an old route but just adds
another as long as it is not *exactly* the same. However, the RPL
adaptation missed to remove the old route so RPL got easily confused
about where it actually needed to send packets.
RFC 2460 was obsoleted by RFC 8200. This PR changes the references
around, so we don't reference an obsoleted RFC ;-).
Also I'm moving these references from the old-style HTML-like format
to the newer-style Markdown-like format.
Skald is a very small and simple, TX-only BLE stack that supports
sending advertisements only. It is useful for building all kinds
of BLE beacons with very minimal memory footprints.
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.
gnrc_sock currently does not compile with `gnrc_neterr` included, since
both `msg_try_receive()` and `msg_try_send()` expect a *pointer* to a
`msg_t`, not a `msg_t`.
To test, just compile an application using `gnrc_sock` (e.g.
`examples/gcoap`) with `USEMODULE+=gnrc_neterr`.
[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
According to RFC 6724 ch. 5 rule 8, the source address candidate with
the longest matching prefix has to be selected. The current
implementation discards source addresses that have no matching prefix
(`match = 0`) which is perfectly fine for any global address.
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)
