The tokenizer (the code that breaks up the line given to the shell into
strings to create argv) was quite a messy piece of code. This commit
refactors it into a more traditional state-machine based parser.
This fixes the issues with quote handling exposed by the recently
introduced test.
Co-authored-by: Juan Carrano <j.carrano@fu-berlin.de>
This does two things:
The documentation of `luid_get()` is wrong, or at least confusing.
It talks about
> an 8-bit incrementing counter value into the most significant byte
while the implementation does
((uint8_t *)buf)[0] ^= lastused++; // 0 is LSB!
Now it could be argued that the intention was that the ID is supposed
to be used in Big Endian contexts and that was an omission, however
to keep everyone's sanity, let's keep it simple and just state that this
actually changes the LSB.
Also add a `luid_get_lb()` function that does the same, but modifies the
most significant byte - or the last byte if looking at the index.
This can then be used directly by e.g. #13743
ztimer_clock are meant to be chained. At the end of the chaine
there is always a timer device object (periph_rtt/rtc/timer).
Since ZTIMER_MSEC and ZTIMER_USEC can be the scaled/shifted with
respect to the base periph_rtt/rtc/timer it makes sense to chain
other ZTIMER_XXX on top of the base rtc/timer/rtt in order to avoid
chained convertions.
`od_hex_dump()` is called if `hdr_len < pkt->size` to print the rest
after `hdr_len` of `pkt`. So if we just leave `hdr_len = 0` instead of
calling `od_hex_dump()` for every other NETTYPE, we achieve the same
effect.
As it is more effective (and already done in some cases) to re-set
`hdr_len` when the header was printed, we initialize `hdr_len` first
with 0 now.
Instead of making a NETTYPE definition dependent on an implementation
module, this change makes it dependent on a pseudo-module for each
specific NETTYPE and makes the respective implementation modules
dependent on it.
This has two advantages:
- one does not need include the whole implementation module to
subscribe to a NETTYPE for testing or to provide an alternative
implementation
- A lot of circular dependencies related to GNRC could be untangled.
E.g. the only reason `gnrc_icmpv6` needs the `gnrc_ipv6` is because it
uses `GNRC_NETTYPE_IPV6` to search for the IPv6 header in an ICMPv6
when demultiplexing an ICMPv6 header.
This change does not resolve these dependencies or include usages where
needed. The only dependency change is the addition of the
pseudo-modules to the implementation modules.
This adds two functions `coap_payload_add()` and `coap_payload_advance()`.
- `coap_payload_add()` will add n bytes to the payload buffer and advance
payload pointer accordingly.
const char hello[] = "Hello CoAP!";
coap_payload_add(pkt, hello, sizeof(hello));
- `coap_payload_advance()` will advance the payload buffer after data
has been added to it.
int len = snprintf(pkt->payload, pkt->payload_len, "%s %s!", "Hello", "CoAP");
coap_payload_advance(pkt, len);
I considered adding an additional parameter to keep track of the total request size
(returned size from coap_opt_finish() incremented by each added payload fragment),
but decided against it to keep consistency with the existing API.
- pm_off() should prevent other threads from getting executed after it is
called, as it should turn off the MCU completely according to its doc
- Previously, the fallback implementation would still allow other threads
to continue working
- Simply disabling IRQs and never enabling them again should make sure
the MCU behaves like it would be completely off
- pm_off() should reduce the power consumption as much as possible
- Previously, when IRQs came after the call to pm_set_lowest() in the
fallback implementation of pm_off(), `while(1) {}` got executed at full
power consumption
- Just calling `pm_set(0);` in a loop while make sure that lowest power mode
is restored if the MCU wakes up again.
- The check if the lowest power mode is available is skipped, as no code
gets executed afterwards anyway
With multiple 6LoWPAN interfaces the router for the given interface
—the one the triggering RA came over—should be used to register the
address with.
Co-Authored-By: Benjamin Valentin <benpicco@googlemail.com>
The macros US_PER_MS and friends are assumed to be 32 bit unsigned integers
by users. However, e.g. on AVR a `1000U` is only 16 bit long. Thus, e.g.
`xtimer_usleep(100 * US_PER_MS)` will wrap around and only sleep for ~34ms.
This commit declares them as unsigned long, which is on all currently supported
platforms 32 bit wide.
Previously, ztimer would happily set an absolute RTT alarm value that exceeds
RTT's maximum value (though not a longer interval), as the `val` was
simply added to `rtt_get_counter()`.
This commit ensures that the target value wraps around RTT_MAX_VALUE.
Fixes#13920.
Enabled by the gnrc_netif_events pseudo module. Using an internal event
loop within the gnrc_netif thread eliminates the risk of lost interrupts
and lets ISR events always be handled before any send/receive requests
from other threads are processed.
The events in the event loop is also a potential hook for MAC layers and
other link layer modules which may need to inject and process events
before any external IPC messages are handled.
Co-Authored-By: Koen Zandberg <koen@bergzand.net>
With #10970 only existing *.c files will be added to SRC when using
the SUBMODULES mechanism, so SUBMODULES_NOFORCE (used to filter out
non existing source files) is now redundant so remove the usage.
This makes the code of `readline()` clearer and shorter. It also fixes a
minor artifact of the long line handling.
Previously it was not possible to recover from a long line. That is, if too
many characters were sent, the line would be invalidated and pressing backspace
would not fix it- the only option was to discard the line. It is now possible
to bring the line back to size. Note that visual effects when deleting characters
will still depend on the host's terminal.
The new code is written in a way that all writes to memory are guarded by
bounds check, so an assertion was removed.
Co-authored-by: Juan Carrano <j.carrano@fu-berlin.de>
There was some code added to "prevent putchar from being inlined", which
supposedly enlarged the code size.
Co-authored-by: Juan Carrano <j.carrano@fu-berlin.de>
This fixes `xtimer` to use `xtimer_now64()` instead of `xtimer_now()`
for updating the `*now` variable during the iteration in
`_update_short_timers()` function. The same function is used to
initialize `*now` in `_timer_callback()` below.
While using `xtimer_now()` in this iteration step does not hinder the
proper execution of all timers in the short term timers (for those the
`xtimer` module only looks at the `start_time` member, not the
`long_start_time` member) at least for the current long term time window
(I did not test higher cases), it sets the `long_start_time` member to 0
for all timers following in the list of timers after this iteration
step. However, external modules that rely on this to be correct,
e.g. evtimer [1], fail their calculations when trying to compare to
the current value to `xtimer_now64()`.
[1] https://github.com/RIOT-OS/RIOT/blob/11f3d68/sys/evtimer/evtimer.c#L118-L121
Co-Authored-By: Cenk Gündoğan <mail+dev@gundogan.net>
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
