sjlongland
commented
6 years ago So it looks like it's a firmware bug:
4.4. Message Correlation
An Acknowledgement or Reset message is related to a Confirmable
message or Non-confirmable message by means of a Message ID along
with additional address information of the corresponding endpoint.
The Message ID is a 16-bit unsigned integer that is generated by the
sender of a Confirmable or Non-confirmable message and included in
the CoAP header. The Message ID MUST be echoed in the
Acknowledgement or Reset message by the recipient.
The same Message ID MUST NOT be reused (in communicating with the
same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2).
Implementation Note: Several implementation strategies can be
employed for generating Message IDs. In the simplest case, a CoAP
endpoint generates Message IDs by keeping a single Message ID
variable, which is changed each time a new Confirmable or Non-
confirmable message is sent, regardless of the destination address
or port. Endpoints dealing with large numbers of transactions
could keep multiple Message ID variables, for example, per prefix
or destination address. (Note that some receiving endpoints may
not be able to distinguish unicast and multicast packets addressed
to it, so endpoints generating Message IDs need to make sure these
do not overlap.) It is strongly recommended that the initial
value of the variable (e.g., on startup) be randomized, in order
to make successful off-path attacks on the protocol less likely.
For an Acknowledgement or Reset message to match a Confirmable or
Non-confirmable message, the Message ID and source endpoint of the
Acknowledgement or Reset message MUST match the Message ID and
destination endpoint of the Confirmable or Non-confirmable message.That's the issue I'm running afoul of. My query regarding timeouts on requests still stands though.
mwasilak
Hi,
I'm trying to integrate
txThingsinto a Tornado application that I'm working on in order to communicate with some devices running OpenThread. For some requests, the devices need to asynchronously communicate with a Modbus energy meter, and so they send an emptyACKto say, "Got that, please wait"… go communicate with the meter, then send the finalACKwhen they get the reply.This works fine with Copper on Firefox, but I note I'm not seeing the data in
txThings. Instead it seems to complain about a duplicateACKand drop the message:The upshot of this is I'm unable to see what the final response was. My understanding is (and this could be wrong) that when responding to a message, you don't change the token or message ID… and so the devices round-trip this unchanged.
Could you clarify the behaviour that's expected of
txThingsin relation to non-piggy-backed replies?Also somewhat related: how do I specify a timeout? I've been looking for API documentation but haven't stumbled on any, nor have I found any way to set a time out on my CoAP requests.