Incorrect GET response after POST

Golioth Cloud Help
1

Hello, I’m in the process of reviving the golioth-rs repo and rebasing it on Embassy and nrf-modem for async support in Rust :slight_smile: I’ve run into a small problem and I’m not sure where to go from here. I’m using CoAP and DTLS.

I’m using an atomic u16 type that is incremented and used for the message header id anytime I make a CoAP request, just like the original repo. If I make a GET request I get a good response:

60 45 00 00 48 C2 2E 52 8D 07 04 8E 9D 80 FF 7B 22 73 74 61 74 61 74 61 74 65 22 3A 74 72 75 65 7D

which decodes into

UDP

Message:
{
  "type": "Acknowledgement",
  "code": "Content",
  "id": 0,
  "token": 0,
  "options": [
    "ETag(etag=C2 2E 52 8D 07 04 8E 9D",
    "Content-Format: text/plain; charset=utf-8"
  ]
}

Payload:
{"state":true}

If I attempt to GET after I perform a POST, I get this instead

60 44 00 00 48 00 00 00 00 00 00 CA 0C 80 FF 4F 4B

which decodes to

Message:
{
  "type": "Acknowledgement",
  "code": "Changed",
  "id": 0,
  "token": 0,
  "options": [
    "ETag(etag=00 00 00 00 00 00 CA 0C",
    "Content-Format: text/plain; charset=utf-8"
  ]
}

Payload:
OK

It seems that I am picking up a response from the previous POST? I’m not a networking guru, so I’m a little unsure of what is going on, should I use PUT instead of POST or should I wait a certain amount of time before doing a GET after PUT/POST?

2

Ha, I figured it out. I was right, the response is from the previous POST and not the GET (the id is the tale tell sign). I solved this, by making POSTs Nonconfirmable types so they don’t interfere with the responses of GETs.

Successful GET after LightDB Stream and State POSTs:

UDP

Message:
{
  "type": "Acknowledgement",
  "code": "Content",
  "id": 2,
  "token": 0,
  "options": [
    "ETag(etag=C2 2E 52 8D 07 04 8E 9D",
    "Content-Format: text/plain; charset=utf-8"
  ]
}

Payload:
{"state":true}
2 Likes
3

I’m back working on the golioth-rs repo :slight_smile: , and I wanted to update this post. After learning more about CoAP, it seems that making my POSTs Nonconfirmable was just a hack, not the solution to my previous problem.

The real answer is to make sure to include a request token to match on once a response is received. I’ve added a non-cryptographically secure PRNG function to my code that creates random tokens to include in my packets.

4

@dkhayes117 great to hear from you and thanks for following up! Sounds like you found the solution here :slight_smile: Message ID and Token can sometimes be conflated when using CoAP, which can cause confusion. As you have identified, the Message ID is useful for correlating Acknowledgement to a message, whereas the Token is useful for correlating the response to a request. In the event that the response is piggybacked onto an Acknowledgement then then it would include both a matching Message ID and a matching Token.

Thanks for all the awesome work you are doing on golioth-rs!

1 Like