While browsing through the rendered doc, I found the precondition of
`gnrc_netreg_register()` somewhat lacking. What is a "message queue"?
`gnrc_netreg_entry_t`s have types. Does this apply for all types?
This specifies the requirement more: The calling thread **only** needs
a message queue (also provides a link to `msg_init_queue()` now for
further information), if the provided `gnrc_netreg_entry_t` is of type
`GNRC_NETREG_TYPE_DEFAULT` (i.e. thread-wise IPC).
Fix re-register when using the same token.
Handle edge cases when change token for a resource.
Only set observer and resource on initial registration.
Discuss re-registration in documentation.
Otherwise, it may happen that `::` or a global address is chosen by
the IPv6 header fill function. Both types of addresses are
[not valid for RAs](https://tools.ietf.org/html/rfc4861#section-4.2)
Parts of [RFC4862] were already implemented when NDP via the NIB was
first implemented. This change just includes the DAD portion of
[RFC4862]. This should be enough to make RIOT fully RFC4862 compliant.
[RFC4862]: https://tools.ietf.org/html/rfc4862
With #9209 gCoAP got the ability to re-register and OBSERVE with a new
token, sadly the `observer` variable wasn't set in that fix, so a
re-registration actually led to the deletion of the observer (because it
is still `NULL` when the old registration is overwritten in l. 317)
The macro MODULE_TLSF_MALLOC indicates if tlsf is being used as the system-wide
allocator. MODULE_TLSF only incates if TLSF is present.
PS should check for MODULE_TLSF_MALLOC to decide if heap information should be
displayed.
OutputterPrintHeaderFunction is declared as a function of 1 parameter
but CompilerOutputter_printHeader was defined as taking 2.
It is a mystery why this code compiled before.
Currently, `gnrc_pktdump` only prints the header part of a snip.
However, if the snip wasn't parsed yet by the corresponding GNRC
module (or the module doesn't exist because the node is e.g. just a
forwarder), additional data might not be printed.
This makes it hard to analyze the data properly (sometimes you not only
want to know where the IPv6 packet is supposed to go, you also want to
know what's in it). So this just prints the rest of the snip as a hex
dump.
The nanocoap_get function is refactored to split of the request part
into a separate function for reuse by other modules. Support for
retransmissions when the received frame is malformed is dropped as it
was broken anyway.
Provides functions for type 3, 4 and 5 UUID generations.
UUID type 1 is timestamp based and requires an accurate time source. For
this reason it is left out of this implementation. UUID type 2 is not
defined in RFC 4122 and thus also not included here
