Closed pawszw2 closed 3 months ago
As there are multiple types of CoAP PDU header format (i.e. Unreliable, Reliable, WebSockets), there would have been a general assumption that people accessing the PDU from within an application would only be interested in the content of the PDU using the functions in coap_pdu_access(3) and so this would be an oversight.
Furthermore, PDUs that contain a body of data that spans across multiple packets do not used the likes of pdu->used_size
- which is why the coap_get_data_large(3) function is provided.
I cant immediately think of any side effects for your proposal (other than there being a bit of a processing overhead) - which would need to be applied to all instances where the PDU is getting the token updated before presenting the PDU to the application. I need to do some regression testing though.
Thanks for quick reply, I'll look forward to updates on that.
Apologies in being slow to respond. This, what appears to be a simple change to coap_update_token()
, is creating some anomalies which I am trying to tack down.
Please checkout #1401 to confirm that this now works for you.
Thanks for that. Unfortunately I won't be able to check it till Monday.
I've checked #1401 and it fixes my problem. Thanks for that!
Thanks for confirming.
Environment
libcoap Configuration Summary
From important stuff: CONFIG_LIBCOAP_OSCORE_SUPPORT=y
Problem Description
Hi!
I've encountered a problem with header after libcoap updates a token in specific situation. There is a section of RFC for OSCORE that says there should be second message exchange if we sent a new OSCORE message after server reboot. Here everything looks fine on libcoap side, but after receiving a response for the second message, the token in it is replaced with the token from the first message. However, after this operation header doesn't get updated. It is not an issue when both tokens are the same length, but in other cases it can be. Later on, this header might be updated in send procedure, although there is also a case when pdu is passed to response handler before updating the header. Members of
coap_pdu_t
structure have valid values, but if we want to see raw CoAP message, there is a mismatch between token length declared in header and real token length.I'm not sure if this behavior is intended or is it an oversight?
Token update takes place in coap_block.c:3884
I have a solution for this problem, which is to update header after updating a token. It can be done by replacing:
With:
But I don't know if it could cause some other problems.
Another idea is to update header always before calling response handler.
Expected Behavior
CoAP message held in memory should be up to date when passed to response handler.
If reading whole CoAP message from memory in response handler is invalid, probably there should be some note in
coap_pdu_t
documentation about it?Actual Behavior
In my case (sending 8-byte token), CoAP header suggests, that there is a 7-byte long token in message, but in reality the token is 8-byte. Then, when I try to use external CoAP message parser, the last byte of token is read as option, leading to error in message parsing.
Steps to reproduce
This may be tricky and I don't think it would be helpful, but if you want I can try to describe it.
Debug Logs
Example flow:
coap_update_token
incoap_block.c:3884
)But in memory layout we have old header (printed
pdu->used_size + pdu->hdr_size
bytes, starting frompdu->token - pdu->hdr_size
):