RFC3610 states that len_encoding is only valid for "0x0001 ... 0xFEFF"
If 0 < l(a) < (2^16 - 2^8), then the length field is encoded as two
octets which contain the value l(a) in most-significant-byte first
order.
sock_[udp|ip]_recv returns `pkt->size` after pkt was released via `gnrc_pktbuf_release(pkt)`.
This can result in wrong values returned by this functions and thus is not according to its sepecification.
Storing this values before releasing pkt returning the stored values should fix this.
Without this the first packet to a new link-local address will not be
delivered in non-6Lo environments, since the interface is not provided.
With this change, if an internet was provided to the address resolver it
will be stored within an allocated `gnrc_netif_hdr_t`.
At this point [IPv6 already striped](netif strip) the packet of its
netif header, so there is no risk that there will be to, in case it was
provided and the `netif` came from its existence.
`_decapsulate()` is called by callees of `_receive()` so the call to
the latter function within the first creates a recursion we don't want.
Using `gnrc_netapi` instead removes that and provides the added benefit
that other subscribers to IPv6 are also informed.
Update return values in documentation
Improve comments with separate @return statement for each rv
Remove incorrect return value for aes_init
Use @return instead of @returns
Fix comment lines over 80 chars
Empty array uint8_t data[] is not allowed in ISO-C++. Replacement: function coap_hdr_data_ptr, which handles
the pointer arithmetic to point where hdr.data pointed
1. When the 32 bit target of the xtimer overflowed the timer was not placed in the right list.
2. When the hardware timer overflowed the comparison was wrong for setting next target.
3. Backoff condition
In RIOT native, sending CTRL+D to a shell started using shell_run would resulted in and
endless prompt loop. I've been unable to trigger such a behaviour
on actual hardware using a UART connection, but calling `pm_off` seemed
like a better alternative than having an `#ifdef BOARD_NATIVE`.
Fixes#9946
The auto initialization of the sht1x module differs from the initialization of
other sensors, but previously no documentation pointed that out. This lack of
documentation led to a bug being introduced. This commit provides the previously
missing documentation.
- the driver for sht1x is initialized two times
- the second initialization is done only when SAUL is used, but sht1x needs
to be initialized in any case. (SAUL registration is also done there, but
only when SAUL is actually being used.)
This commit fixes both.
