The ubjson module has a number of quality defects and is unsafe.
Considering CBOR is popular, standarized and supported in RIOT and that
the ubjson implementation is a home-grown one whose API will likely be
unfamiliar to new users, I propose to delete it.
This removal, of course, dows not have to be NOW. We can deprecate it for
one or two releases before.
What's wrong with this module?
- Unsafe: the parsing is done recursively. This is embedded in the API, so it
is not possible to fix it without changing the API. A document with too much
nesting can cause a stack overflow.
- Does not validate writing: it is possible to produce invalid output. From
the docs:
> The library won't complain if you write multiple values that are not
> inside an array or object. The result will just not be properly serialized.
- Poorly tested. As shown by #11702, #11703 the tests were not even detecting
that a False was stored as True.
- In line with the previous remark, see
68dc5b0d6e/tests/unittests/tests-ubjson/tests-ubjson.c (L66-L77)
Why is the following code in the unit tests??
```c
irq_disable();
sched_set_status(data->main_thread, STATUS_PENDING);
```
- #2175 is still unfixed after 3.5 years.
- Code quality. The code has multiline macros that assign variables and
return. See c332514875/sys/ubjson/ubjson-write.c (L34-L41)
Can we mark it as deprecated this release and sweep it in the following one?
`gnrc_sixlowpan_frag_rb_base_rm()` cleans up the intervals which is part
of `gnrc_sixlowpan_frag_rb`, not `gnrc_sixlowpan_frag`, so when the
`gnrc_sixlowpan_frag` is not compiled in, but `gnrc_sixlowpan_frag_rb`,
the intervals allocated in the reassembly buffer and inherited by the
virtual reassembly buffer are never released.
Preprocesor fails to evaluate the if condicion on L91-92 because
RTT_FREQUENCY is not defined, and therefore a division by 0 occurs.
TO avoid this replicate the RTT_FREQUENCY undefined warning.
Currently the bitfield type mixes up the order of bits: While the byte
order is big-endian (most significant byte first), the bit order of each
single byte within the bitfield is little-endian (most significant bit
last). While this isn't a problem for most applications of the bitfield
type it becomes one when sending the bitfield over the network (as done
e.g. in the [ACKs of Selective Fragment Recovery][SFR-ACKs]).
This change unifies byte order and bit order to both be most
significant bX first.
[SFR-ACKs]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-07
Right now 'ipv6_addr_split_iface' assumes that the interface specifier
will always be a number (based on GNRC way of identifying interfaces),
but this may not be always the case.In order to be able to use the
Network Interface API, interfaces should be referred by their name.
This changes 'ipv6_addr_split_iface' so it returns a pointer to the
string that specifies the interface.
45f7966 made the `src_len` field the "emptiness signifier" for the VRB.
However, when `gnrc_sixlowpan_frag` is compiled in, the remove function
`gnrc_sixlowpan_frag_vrb_rm()` does not set the `src_len` to zero,
resulting in already deleted entry to be recognized as non-empty.
This allows to set a timer between the completion of a datagram in the
reassembly buffer and the deletion of the corresponding reassembly
buffer entry. This allows to ignore potentially late incoming link-layer
duplicates of fragments of the datagram that then will have the
reassembly buffer entry be blocked.
This was noted in this [discussion] for classic 6LoWPAN reassembly (and
minimal fragment forwarding) and is recommended in the current
[selective fragment recovery draft][SFR draft].
[discussion]: https://mailarchive.ietf.org/arch/msg/6lo/Ez0tzZDqawVn6AFhYzAFWUOtJns
[SFR draft]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-07#section-6
cd1ce6b98d accidentally disabled generating documentation for
`xtimer_msg_*()` functions.
Always define those functions when building the documentation.
This imports the protocol parameters for Selective Fragment Recovery
(SFR). For the values I took some educated guesses based on my
experience with previous experimentation with fragment forwarding.
The defines currently are based on [draft v7].
[draft v7]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-07#section-7.1
fixup! gnrc_sixlowpan_frag: initial import of SRF parameters
The name `fragment_msg` or `frag_msg`/`msg_frag` always to me was a bit
misplaced, as it basically implements an asynchronous fragmentation
buffer and doesn't necessarily have anything to do with messages.
This change
1. changes the name to `fb` (for fragmentation buffer)
2. factors its code out to its own sub-module so it can be re-used by
other 6LoWPAN fragmentation schemes like [Selective Fragment
Recovery]
[Selective Fragment Recovery]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-05
This module was intended to be a test framework for GNRC but it never
really got used. It was not maintained for 3 years. It will be removed
after 2020.07 release at the latest.
Added a header to allow defining C interfaces using the default C11 atomic
types. Those types are however fully opaque and inaccessible from C++, as C11
atomics are completely incompatible with C++.
The functions now are semantic distinct:
- gnrc_netif_is_6lo(): the interface is a 6Lo interface
- gnrc_netif_is_6ln(): the interface is using Neighbor Discovery
according to RFC 6775
Preparation step to introduce a semantic difference between an
interface being a 6Lo interface and a 6LN according to RFC 6775 [[1]]
(i.e. performs Neighbor Discovery as defined there).
[1]: https://tools.ietf.org/html/rfc6775#section-2
Rather than dispatching the packet automatically once it is complete,
`gnrc_sixlowpan_frag_rb_add()` now only returns success, and leaves it
to the caller to dispatch the packet.
Due to some changes to the minimal forwarding draft and in preparation
for Selective Fragment Recovery some changes to the VRB API were
needed. Now the index of a VRB entry is only (L2 src, tag) not as
before (L2 src, L2 dst, length, tag).
I know that the current `rbuf_base` causes waste, as all the fields not
used by the new index are effectively not used by the VRB. I'd like to
fix that however in a later change, since that also requires some
modifications of the classic reassembly buffer, and thus would
complicate the review and testing of the change.
Sources for the index change:
- https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-04#section-1
- https://mailarchive.ietf.org/arch/browse/6lo/?gbt=1&index=DLCTxC2X4bRNtYPHhtEkavMWlz4
This change is in preparation to [PR 10788]. PR 10788 will make the
shell exitable which may lead to unexpected behavior in comparison to
previous usage of the shell.
To prevent this, this PR introduces two "new" functions to the shell's
API: `shell_run_once()` and `shell_run_forever()`.
`shell_run_once()` basically has the same behavior as `shell_run()` in
current master: Start a shell and continue reading lines until EOF is
reached.
`shell_run_forever()` wraps around `shell_run_once()` and restarts the
shell if it exits.
`shell_run()` is re-introduced as a back-porting alias for
`shell_run_forever()`.
As a consequence all current calls to `shell_run()` won't exit even
with [PR 10788] merged (which would add EOT as additional exit
condition for `shell_run_once()`).
[PR 10788]: https://github.com/RIOT-OS/RIOT/pull/10788
TCP options have up to three fields (kind, length, value). The
current code only checks for the presence of the first field. Before
accessing the second field (length) the code must ensure that a length
field is even present.
