When using convert_frac to slow down a timer, the extension machinery is
used to prevent converting values that would be larger than, after
conversion, 2**32. In order to calculate the maximum value, UINT32_MAX
is converted.
Previously, this was mistakenly converted by multiplying with the
fraction used to scale up a value. E.g., when using convert_frac to
slow down a 1us timer to provide a 1ms timer, UINT32_MAX was multiplied
by 1000. As the result is used % UINT32_MAX, this lead to a wrong value
close to UINT32_MAX, as ((UINT32_MAX * N) % UINT32_MAX = (UINT32_MAX - N - 1)).
This PR fixes the calculation so max_value is determined by multiplying
with the fraction used to scale down a value.
Modelled GNRC_MAC_ENABLE_DUTYCYCLE_RECORD as bool. Introduced
CONFIG_GNRC_MAC_DISABLE_DUTYCYCLE_RECORD to invert the logic.
Tagged GNRC_MAC_ENABLE_DUTYCYCLE_RECORD for deprecation.
This changes the configuration macro to be the exponent of 2^n, as the
mbox buffer size needs to be always power of 2. The macro now has the
GNRC prefix.
Also a compile configuration documentation group is created.
This changes the configuration macro to be the exponent of 2^n, as the
mbox buffer size needs to be always power of 2.
Also a compile configuration documentation group is created.
This changes the configuration macro to be the exponent of 2^n, as the
message queue size needs to be always power of 2.
Also a compile configuration documentation group is created.
This changes the configuration macro to be the exponent of 2^n, as the
message queue size needs to be always power of 2.
Also a compile configuration documentation group is created.
Introduced 'GNRC_PKTDUMP_MSG_QUEUE_SIZE_EXP' to hold exponent
value and made GNRC_PKTDUMP_MSG_QUEUE_SIZE dependant on
GNRC_PKTDUMP_MSG_QUEUE_SIZE_EXP.
Moved 'GNRC_PKTDUMP_MSG_QUEUE_SIZE_EXP' to 'CONFIG_' namespace.
Exposed configurations to Kconfig
Co-authored-by: Martine Lenders <mail@martine-lenders.eu>
Co-authored-by: Leandro Lanzieri <leandro.lanzieri@haw-hamburg.de>
The 6Lo network interfaces can only support a max_frag_size of
SIXLOWPAN_FRAG_MAX_LEN (2047 bytes) as the length field is only 11-bits.
This limits the max_frag_size in the case that the L2-PDU is higher than
that.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
For boards that have terminals in their shipped configurations it makes sense
to reuse those VID/PIDs when providing a terminal in RIOT as well.
That affects the builtin-peripherals IDs and not the custom specified ones.
Co-authored-by: chrysn <chrysn@fsfe.org>
802.15.4g devices have a 2047 byte PDU.
So the assertion `netif->ipv6.mtu == IPV6_MIN_MTU` is too strict here.
This is only enforced on init, so changing the modulation at run-time
did not catch this bug.
To test, use e.g. `at86rf215` with
CFLAGS += -DAT86RF215_DEFAULT_PHY_MODE=IEEE802154_PHY_MR_OQPSK
fixes#14164
Implemented a check in coap_parse() to verify if TKL value is within valid range as specified by RFC7252. The token length must be within 0-8 range, any other value should be considered as invalid and the packet should produce message format error.
A test case was added to tests-nanocoap.c to verify correct behavior in case of TKL in range and out of range.
Update sys/net/application_layer/nanocoap/nanocoap.c
Prefixed debug message with module name and abbreviations expanded.
Co-authored-by: Martine Lenders <mail@martine-lenders.eu>
Update sys/net/application_layer/nanocoap/nanocoap.c
Prefixed debug message with module name and abbreviations expanded.
Co-authored-by: Martine Lenders <mail@martine-lenders.eu>
If token length in the header was longer than actually provided in the following payload, read out of the input buffer bounds or processing of data beyond the actual input packet bound could happen. In order to remove the risk, the options loop condition was modified to early detect the condition and abort packet processing if a malformed packet is detected.
nanocoap: Added pointer range check after token length parsing.
Added a check to verify if the current packet parsing pointer is still within the packet boundaries after incrementing by the token length declared in the header. If packet is malformed an error code is returned.
nanocoap: Combined packet length checks
Combined packet length checks after reading token length and processing options into a single packet length validation after the options parsing loop. The entry to the options parsing loop is safe as the while loop condition protects against entering the loop if the token length was invalid.
saul_reg_rm can not be used safely unless in tight coordination with the
application. This points out the issue, puts the onus of making sure
nobody calls vanishing registrations on the device driver and deprecates
the call (as the requirements for correct usage are practically
impossible to fulfull for a generic driver).
