The change in 399e25cc was did not have the intended effect: As the
local crates still all defined 0.7 as the riot-wrappers version, that
dependency was actually down- rather than upgraded, and thus did not
effect the stabilizations.
This pulls in versions of previously nightly-only crates that can be
built on 1.65 beta.
The Cargo overrides that direct the resolver to the git repositories are
disabled while the version used in tree also happens to be a released
version of the crates, as it should be the case as per [251].
[251]: https://github.com/RIOT-OS/Release-Specs/issues/251
This will allow more components to build on 1.64 stable, and contains a
fix relevant for https://github.com/RIOT-OS/RIOT/pull/18619.
CoAP modules are held back as they appear to need an even newer nightly
than in the current riotdocker to build without feature declarations.
As far as I can tell, no DHCPv6 RFC specifies this option. The handling
for the zero option was added in #17736 by @benpicco to fix issues
encountered while trying to retrieve a DHCHPv6 lease. However, I
strongly suspect that the zero option was encountered in this case due
to an out-of-bounds read performed in RIOT's DHCPv6 client
implementation (i.e. the option parsing loop read beyond the packet
bounds). This issue was fixed in #18307 and I strongly suspect that it
should also fix the issue @benpicco originally encountered in #17736. As
such, I propose that we remove the if statement which treats the zero
option as an end-of-payload marker.
Fixes#18309
This header-only module provides a `string_utils.h` that currently
only provides the non-standard function `explicit_bzero()` to securely
wipe memory. It may be extended with other utility functions in the
future.
`tiny_strerror()` is a drop-in replacement for `strerror()`, but
instead of a long help message it returns the much shorter macro name
matching the given number.
The (pseudo-)module `tiny_strerror_as_strerror` can be used to
replace all calls to `strerror()` with calls to `tiny_strerror()`.
My spell checker says "receival" should be "reception". Also, the
terms allow list and deny list are preferred over whitelist and
blacklist. But since scripts may depend on the shell command name,
only the help description is changed, not the cmd names.
Previously `shell_commands` was a "catch-all" module that included
shell commands for each and every used module that has a shell
companion. Instead, the new `shell_cmds` module is now used to provide
shell commands as individually selectable submodules, e.g.
`cmd_gnrc_icmpv6_echo` now provides the ICMPv6 echo command (a.k.a.
ping).
To still have a "catch all" module to pull in shell commands of modules
already used, `shell_cmds_default` was introduced. `shell_commands`
depends now on `shell_cmds_default` for backward compatibility, but
has been deprecated. New apps should use `shell_cmds_default`
instead.
For a handful of shell commands individual selection was already
possible. Those modules now depend on the corresponding `cmd_%` module
and they have been deprecated.
This fixed compilation, as the use of the interal `_xtimer_now()`
function is not compatible with `ztimer_xtimer_compat`. However, this
bug never triggered due to a bug in the build system preventing the
compilation of the shell command. We are about to fix this, so let's
fix the source first.
This adds support for netdevs implementing the new API that provides
`netdev_driver_t::confirm_send()`. This allows implementing netdevs
in an event based non-blocking fashion, making live of driver
developers a bit easier. In addition, `gnrc_tx_sync` will now throttle
users of `sock_udp_send()` so that they can only send datagrams as
fast as the network stack and hardware is able to send out.
Finally, this lays the groundwork to fetch TX statistics (such as
TX timestamps, reception of layer 2 ACKs/NACKs, etc.) from the network
devices.
- most were trivial
- missing group close or open
- extra space
- no doxygen comment
- name commad might open an implicit group
this hould also be implicit cosed but does not happen somtimes
- crazy: internal declared groups have to be closed internal
Previously `tests/pkg_littlefs2` crashed on the `samr21-xpro`. This
now aligns the buffers in `littlefs2_desc_t` to the alignment
requirement of `uint32_t`.
Specifically the issue causing the crash at hand was that
`struct lfs_free::buffer` is of type `uint32_t *`, so access are
expected to be aligned to `uint32_t`. After this commit, this
assumption is fulfilled.
Previously `tests/pkg_littlefs` crashed on the `samr21-xpro`. This
now aligns the buffers in `littlefs_desc_t` to the alignment
requirement of `uint32_t`.
Specifically the issue causing the crash at hand was that
`lfs_free_t::buffer` is of type `uint32_t *`, so access are expected
to be aligned to `uint32_t`. After this commit, this assumption is
fulfilled.
A if `netdev_driver_t::confirm_send()` is provided, it provides the
new netdev API. However, detecting the API at runtime and handling
both API styles comes at a cost. This can be optimized in case only
new or only old style netdevs are in use.
To do so, this adds the pseudo modules `netdev_legacy_api` and
`netdev_new_api`. As right now no netdev actually implements the new
API, all netdevs pull in `netdev_legacy_api`. If `netdev_legacy_api` is
in used but `netdev_new_api` is not, we can safely assume at compile
time that only legacy netdevs are in use. Similar, if only
`netdev_new_api` is used, only support for the new API is needed. Only
when both are in use, run time checks are needed.
This provides two helper function to check for a netif if the
corresponding netdev implements the old or the new API. (With one
being the inverse of the other.) They are suitable for constant folding
when only new or only legacy devices are in use. Consequently, dead
branches should be eliminated by the optimizer.
As per Section 5.2.1 of the MQTT-SN specification, the MQTT-SN length
header is either 1- or 3-octet long. If it is 3-octet long then the
first octet is 0x01. The asymcute implementation currently only checks
that the incoming packet is at least 2-octet long before attempting to
parse it (MIN_PKT_LEN). However, if the first octet is 0x01 the packet
must be more than 3 octet long in order to be valid. Since asymcute
does not check this it reads one octet beyond the packet data for a
2-octet packet where the first octet has the value 0x01. This commit
fixes this issue by adding an additional sanity check to _len_get.
Currently, asymcute only matches an MQTT-SN request to its
acknowledgement using the MsgId header. However, I strongly believe
this to be insufficient as asymcute would thus also match a SUBACK
to a prior PUBLISH message (for example) as long as the message ID
matches. To address this issue, this commit modifies _req_preprocess
to also compare the request message type in addition to the message id.
