Closed golemik98 closed 5 months ago
@golemik98 Thanks for reporting this and tracking down the root cause. The fix should be in #1329 - please test that out and confirm or otherwise that this fixes your issue.
@mrdeep1 thanks for rapid response - I will let you know
Environment
libcoap Configuration Summary
Problem Description
Hi!
I think this fix can cause problems in one particular scenario, which I stumbled on lately. https://github.com/obgm/libcoap/blob/c7c3275e5326396b0b41463f9205c1c84295d4ea/src/coap_net.c#L1421 When we use PLAIN COAP we do not call this code unless it is GET method with observation option. When it is GET method with observation option we call this and set
state_token
as pre-incremented value of tx_token from session. Then we want to send next request to the server with newly generated token, by this function: https://github.com/obgm/libcoap/blob/c7c3275e5326396b0b41463f9205c1c84295d4ea/src/coap_session.c#L1603 So the message token is (post)not incrementedtx_token
, which is set tostate_token
. Then server is responding with the same token (as it supposed to do). We handle this response in function https://github.com/obgm/libcoap/blob/c7c3275e5326396b0b41463f9205c1c84295d4ea/src/coap_block.c#L3469 and what is happening next, we encounter this condition: https://github.com/obgm/libcoap/blob/c7c3275e5326396b0b41463f9205c1c84295d4ea/src/coap_block.c#L3496 which happen this time to be false. It is false becausetoken_match != STATE_TOKEN_BASE(p->state_token)
match. So this function starts to malfunction, and its result is handling response of wrong (updated) token, not the token that was originally send (this token was generated with the same value asstate_token
) but due to this condition: https://github.com/obgm/libcoap/blob/c7c3275e5326396b0b41463f9205c1c84295d4ea/src/coap_block.c#L3797, updated.This happens always when we use PLAIN COAP and send GET with observation and after that any other request from client, client is handling response with wrong (updated by itself) token. Problem is in my opinion with this bug-fix that you mention here https://github.com/obgm/libcoap/pull/1276. This case is not taking place when we do increment token to PDU first then use this value as newly generated token. Would be great if you consider this issue. Thanks!
Expected Behavior
I am expecting this token to be matched by user, not having token mismatch after sending GET with observation and sending whatever request after that which will be recognised wrongly.
Actual Behavior
Described above.
Steps to reproduce
Code to reproduce this issue
Should be the code from example client app writing to any server.
Debug Logs
Other items if possible