search

obgm / libcoap

A CoAP (RFC 7252) implementation in C
Other
784 stars 421 forks source link

Token mismatch after GET woth observation on PLAIN coap - connected to pull 1276 #1327

Closed golemik98 closed 5 months ago

golemik98 commented 6 months ago

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 incremented tx_token, which is set to state_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 because token_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 as state_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

  1. Establish PLAIN COAP cleint.
  2. Send GET with observation
  3. Send any other request and you will receive same token as GET was send.

Code to reproduce this issue

Should be the code from example client app writing to any server.

Debug Logs

Other items if possible

mrdeep1 commented 6 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.

golemik98 commented 6 months ago

@mrdeep1 thanks for rapid response - I will let you know