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)
