This simplifies (written and compiled) code by doing a head rather than
a tail insertion of the new listener into gcoap's list.
As handling of listeners without a link_encoder is now fixed,
gcoap_get_resource_list can handles this now without having to manually
skip over the .well-known/core handler (which is not the first entry any
more now).
Incidentally, this allows the user to install a custom handler for
.well-known/core, as the default handler is now evaluated last.
The NULL case can not regularly be reached (because regularly
gcoap_register_listener sets thel link_encoder to a default one), but if
it is (eg. because an application unsets its link_encoder to hide a
resource set at runtime), the existing `continue` is a good idea (skip
over this entry) but erroneously created an endless loop by skipping the
advancement step.
Using `gnrc_border_router` with `uhcp` is quite noisy.
uhcpc will regularly refresh the prefix and print a bunch of status messages.
Allow the user to tone it down by setting a higher `LOG_LEVEL`.
For this, convert calls to `printf()` and `puts()` to `LOG_xxx()`.
This requires a dummy header for `uhcpd`.
This changes the prefixes of the symbols generated from USEMODULE and
USEPKG variables. The changes are as follow:
KCONFIG_MODULE_ => KCONFIG_USEMODULE_
KCONFIG_PKG_ => KCONFIG_USEPKG_
MODULE_ => USEMODULE_
PKG_ => USEPKG_
Replace direct accesses to sched_active_thread and sched_active_pid with
the helper functions thread_getpid() and thread_get_active(). This serves
two purposes:
1. It makes accidental writes to those variable from outside core less likely.
2. Casting off the volatile qualifier is now well contained to those two
functions
The DHCPv6 server might send reponses multiple times.
The DHCPv6 client will only handle the first response, if additional
responses are comming in they are left in the RX queue.
That results in the client always reading the response of a previous
transaction on any subsequent transactions.
In this case the client will try again, creating a new transaction - that
will again only read the previous response.
To fix this, discard previous responses by flushing the RX queue before
sending a new message to the DHCPv6 server.
fixes#13834
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.
This adds two functions `coap_payload_add()` and `coap_payload_advance()`.
- `coap_payload_add()` will add n bytes to the payload buffer and advance
payload pointer accordingly.
const char hello[] = "Hello CoAP!";
coap_payload_add(pkt, hello, sizeof(hello));
- `coap_payload_advance()` will advance the payload buffer after data
has been added to it.
int len = snprintf(pkt->payload, pkt->payload_len, "%s %s!", "Hello", "CoAP");
coap_payload_advance(pkt, len);
I considered adding an additional parameter to keep track of the total request size
(returned size from coap_opt_finish() incremented by each added payload fragment),
but decided against it to keep consistency with the existing API.
There were two subtle bugs that prevented the DHCPv6 client to request
multiple prefixes for different interfaces.
- `dhcpv6_client_req_ia_pd()` would fill up *all* leases with the same interface
- `_parse_reply()` would return after parsing the first answer
With this patch, `gnrc_border_router` gets a prefix on both interfaces of the at86rf215.
This refactors nanocoap to seperate out the resource tree parsing. It
allows for calling the tree handler with custom resource trees. The
advantage is that a resource with COAP_MATCH_SUBTREE can parse a new
separate resource tree.
Saving RAM is more important than saving a few cycles
used by re-creating the request buffer in the error case.
Also reduce the size of the buffer to 128 bytes.
If we are just requesting the AAAA record it is unlikely
for the reply to take up the maximum size of 512 bytes.
We were already placing restrictions on the domain name length,
those are now actually a bit more relaxed (112 bytes instead of 64)
This implements a client for DHCPv6 IA_PD (Identity Association for
Prefix Delegation). Goal was to have a IETF-compliant alternative to
UHCP. The implementation was based on RFC 8415.
Without this change an attacker would be able to stop the emcute server
by sending a crafted packet triggering this branch. The solution is
using `continue` instead of `return`.
