As per Section 5.2.1 of the MQTT-SN specification, the MQTT-SN length
header is either 1- or 3-octet long. If it is 3-octet long then the
first octet is 0x01. The asymcute implementation currently only checks
that the incoming packet is at least 2-octet long before attempting to
parse it (MIN_PKT_LEN). However, if the first octet is 0x01 the packet
must be more than 3 octet long in order to be valid. Since asymcute
does not check this it reads one octet beyond the packet data for a
2-octet packet where the first octet has the value 0x01. This commit
fixes this issue by adding an additional sanity check to _len_get.
Currently, asymcute only matches an MQTT-SN request to its
acknowledgement using the MsgId header. However, I strongly believe
this to be insufficient as asymcute would thus also match a SUBACK
to a prior PUBLISH message (for example) as long as the message ID
matches. To address this issue, this commit modifies _req_preprocess
to also compare the request message type in addition to the message id.
The _parse_reply function iterates over the DHCPv6 message options
twice but only performs sanity checks on the option length in the
first iteration. As such, both loop iterations need to be identical.
Unfortunately, there aren't without this commit as (1) they use
different maximum length values and (2) the first iteration stops
parsing as soon as it encounters a zero option while the second
doesn't. As such, it is possible for out-of-bounds read to be
performed by the second loop iteration. This commit fixes this.
The handlers for these MQTT message lock the connection mutex on
function entry. During automated testing of asymcute, I discovered
return paths for these function which do not unlock the connection
mutex. This results in a deadlock which prevents asymcute from
sending any further messages.
The assertion is a bit overeager.
In case of receiving a wrong message ID, we re-try receive without
entering the STATE_REQUEST_SEND state again, so it is expected that
we get a non-NULL ctx/response from sock_udp_recv_buf().
What this assert should actually check is that we don't get a non-NULL
ctx after calling sock_udp_recv_buf() with a non-NULL ctx.
So make this explicit to not falsely fail the assertion.
Most of the caching operation was moved to the client code. Since the
forward proxy is using that code for upstream messaging, interacting
with the cache directly is not necessary anymore.
The only cache-related thing necessary for the proxy is validating ETags
from upstream. However, that can be done by just looking at the ETags
from the upstream response (which may or may not have come from the
cache).
Some user callbacks might just return the result of some other operation
that returns written bytes or negative error.
Let's not break those, only consider negative callback returns an error.
This adds a coap_handler_t function that can be used to parse new
subtrees. The subtree information is included in the context pointer of
the call and must be of type coap_resource_subtree_t. This object then
contains the pointer and length of a different coap_resource_t instance.
This removes the need for a user provied work buffer from nanocoap.
Instead we let the user operate directly on network stack internal
memory and provide a callback mechanism to make sure the memory is
properly freed again.
The REPLY of a TP-Link router (WR400 v4.20) ends with a 0 option
that has a bogus length.
When subtracting the length from the remaining length, we get an
underflow (remaining `len` is 3, option len is 4).
To get a working DHCP response, consider 0 (Reserved) an end marker.
If we did not enable downstream interfaces yet but have IA_PD enabled
or if we did not configure an interface for IA_NA but have the module
enabled, don't discard the DHCP reply.
If a server does not support an option it will respond with an error
code.
23a8659bdf introduced DTLS support for
CoAP, but did not make it possible to select the transport on request.
Since switching between CoAP and CoAPS (CoAP-over-DTLS) as client is a
valid use case (one might want to e.g. talk to one server over CoAP and
to another over CoAPS), this change makes that possible.
The `coap_socket_t` and `coap_socket_type_t` types are used by gCoAP
only and the `coap_` prefix is usually used to namespace the `nanocoap`
module's API. This makes it confusing to locate the types in question.
Signed-off-by: Martine Lenders <m.lenders@fu-berlin.de>
Prefix delegation used to be the only supported feature of our DHCPv6
client, but by now it also supports MUD, DNS recursive name servers and
IA_NA is on the horizon. So it makes sense to make IA_PD an optional
module like all those other features are as well.
There is no real reason for that pseudo-module to use the `gnrc_`
prefix. Neither does it need GNRC-components (except, but optionally, as
a network stack of course), nor is it implemented with in the GNRC
network stack.
Apart from advancing the buffer by RR_TYPE_LENGTH, RR_CLASS_LENGTH,
and RR_TTL_LENGTH the code also attempts to read a two byte unsigned
integer using _get_short(bufpos):
unsigned addrlen = ntohs(_get_short(bufpos));
The bounds check must therefore ensure that the given buffer is large
enough to contain two more bytes after advancing the buffer.
Add a an assertion on the added listener not having a trailing chain
instead of silently overwriting it, point out the precondition in the
documentation, and guide users who want to add more than one listener
towards a more efficient way.
This introduces an additional state to the COAP_MEMO_* series to avoid
enlarging the memo struct needlessly. While they are documented
publicly, practically only the COAP_MEMO_TIMEOUT and COAP_MEMO_RESPONSE
are used in communication with the application, as a
gcoap_request_memo_t is only handed out in that state.
This generalizes the existing code for answering CoAP pings into general
message-layer responses. Such responses are now also sent as a reaction
to CON responses, which can otherwise follow the same code path as
existing other responses.
As a side effect, issues that would crop up when responding to odd empty
requests that have token length set are resolved.
Contributes-To: https://github.com/RIOT-OS/RIOT/issues/14169
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.
