The termination condition implemented in gnrc_pktbuf_malloc does not
work when using the sock interface as sock copies packet data to a local
buffer and frees the packet afterwards. As such, the fuzzing application
would exit before performing any input processing.
For this reason, the termination condition in gnrc_pktbuf_malloc is
disabled when using sock. Instead, the application terminates if
gnrc_sock_recv previously returned the fuzzing packet. The underlying
assumption of this implementation is that gnrc_sock_recv is called in a
loop.
Since RIOT is an operating system the native binary will never terminate
[0]. The termination condition for fuzzing GNRC is that the packet was
handled by the network stack and therefore freed. If it is never freed
we will deadlock meaning a memory leak was found, afl should be able to
detect this through timeouts.
This is currently only supported for gnrc_pktbuf_malloc since this is
the pktbuf implementation I used for fuzzing. Implementing this in
pktbuf.h is not possible.
[0]: Except NATIVE_AUTO_EXIT is defined, however, even with that define
set RIOT will only terminate when all threads terminated. Unfortunately,
gnrc_udp and other network threads will never terminate.
This adds a utility module which is used to write applications for
fuzzing RIOT network modules. The module provides a dummy network
interface which is configured with a static IPv6 addresses for modules
which perform operations on the underlying network interface. Besides,
it contains a utility function for transforming data received on
standard input into a `gnrc_pktsnip_t`.
There were two subtle bugs that prevented the DHCPv6 client to request
multiple prefixes for different interfaces.
- `dhcpv6_client_req_ia_pd()` would fill up *all* leases with the same interface
- `_parse_reply()` would return after parsing the first answer
With this patch, `gnrc_border_router` gets a prefix on both interfaces of the at86rf215.
With lwIP we have a chunked UDP payload, so just providing the
stack-internal buffer is not possible. To be able to iterate over such
a chunked payload, this change allows the `sock_*_recv_buf()` functions
to use the internal buffer context as an iteration state.
As the internal buffer space can be released when the function would
return 0, `sock_recv_buf_free()` becomes unnecessary.
RFC4648 specifies an alternate alphabet for base64 encoding / decoding
where '+' and '/' are exchanged for '-' and '-' to make the resulting
string safe to use in filenames and URLs.
This adds a base64url_encode() function that uses the alternate alphabet.
The base64_decode() function is extended to accept both alphabets.
The numeric value for EOF is -1. This caused the shell to return
the same code when EOF was encountered and when the line lenght was
exceeded. Additionally, if the line length is exceeded, the correct
behaviour is to consume the remaining characters until the end of
the line, to prevent the following line from containing (potentially
dangerous) garbage.
Co-authored-by: Hendrik van Essen <hendrik.ve@fu-berlin.de>
We don't want to advertise ourselves as a router to the upstream router.
This also leads to the border router ignoring advertisements from the upstream
router.
In 06aa65e1ba (#10627) a new behavior was
introduced in IPv6 route resolution to try address resolution only at
interfaces that have the prefix of the address to be resolved configured
in the prefix list. This however only makes sense, if the prefix
configured is [on-link], otherwise there is small likelihood of the
address to be resolved being on that link.
For the error case presented for 06aa65e (circular routing at the border
router) this made sense, however within a 6LoWPAN, due to the prefix
being valid for the entire mesh, this leads to the nodes always trying
classic address resolution for in-network addresses instead of just
routing to the default route.
Classic address resolution however fails, as 6LoWPAN hosts typically
[don't join the solicited-node multicast address of their unicast
addresses][6LN-iface-init], resulting in in-network addresses not being
reachable.
As such, to prevent both error cases
- the fallback to address resolution by prefix list must only be used
when the prefix is on-link,
- the prefix configured by DHCPv6/UHCP at the 6LoWPAN border router
must be configured as on-link, but
- the prefix must not be advertised as on-link within the 6LoWPAN to
still be [in line with RFC 6775][RFC-6775-forbidden]
With this change these cases are covered.
[on-link]: https://tools.ietf.org/html/rfc4861#page-6
[RFC 6775]: https://tools.ietf.org/html/rfc6775
[6LN-iface-init]: https://tools.ietf.org/html/rfc6775#section-5.2
[RFC-6775-forbidden]: https://tools.ietf.org/html/rfc6775#section-6.1
When pinging to a prefix for which there is a prefix list entry on the
node (so no next hop) but a default route, a packet to a non-existent
address under that prefix results in the packet being forwarded to the
default route instead. This fixes it, so the node tries address
resolution on the interface the prefix list entry is associated to.
This change amends the `sock` API by a set of functions to `sock` that
allow provisioning of stack-internal buffers to the caller on receive.
This allows to cover two use-cases
1. Zero-copy systems: if the stacks supported the buffer space provided
by these functions can be the same that was filled in the link-layer
2. asynchronous receive within a wrapping sock layer (e.g. `sock_dtls`
wrapping `sock_udp`): to receive packets of the lower level protocol
asynchronously, the wrapping implementation layer would currently
need to allocate its own buffer space, introducing a third buffer
space in addition to the one of the application and the network
stack. For a wrapping layer this is undesirable.
While there are security considerations exposing stack internal memory
space to the caller, I believe they are minor, as in the end the
application developer is the person in control of the node.
This refactors nanocoap to seperate out the resource tree parsing. It
allows for calling the tree handler with custom resource trees. The
advantage is that a resource with COAP_MATCH_SUBTREE can parse a new
separate resource tree.
This is the radio found in NXP Kinetis KW41Z, KW21Z. Only 802.15.4 mode
is implemented (KW41Z also supports BLE on the same transceiver).
The driver uses vendor supplied initialization code for the low level
XCVR hardware, these files were imported from KSDK 2.2.0 (framework_5.3.5)
This adds a driver for the SPI based AT86RF215 transceiver.
The chip supports the IEEE Std 802.15.4-2015 and IEEE Std 802.15.4g-2012 standard.
This driver supports two versions of the chip:
- AT86RF215: dual sub-GHz & 2.4 GHz radio & baseband
- AT86RF215M: sub-GHz radio & baseband only
Both radios support the following PHY modes:
- MR-FSK
- MR-OFDM
- MR-O-QPKS
- O-QPSK (legacy)
The driver currently only implements support for legacy O-QPSK.
To use both interfaces, add
GNRC_NETIF_NUMOF := 2
to your Makefile.
The transceiver is able to send frames of up to 2047 bytes according to
IEEE 802.15.4g-2012 when operating in non-legacy mode.
Known issues:
- [ ] dBm setting values are bogus
- [ ] Channel spacing for sub-GHz MR-O-QPSK might be wrong
- [ ] TX/RX stress test will lock up the driver on openmote-b
