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.
