Coap message type, confirmable/non-confirmable

[Amadeus]

Hello,

I am using the coap Client example from nRF Connect SDK, which uses the Coap utils library https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/include/net/coap_utils.html

As stated in the documentation, this library only enables non-confirmable communication, since in the source file ncs\nrf\subsys\net\lib\coap_utils\coap_utils.c, the application level function used, coap_send_request(), calls coap_init_request() with hardcoded COAP_TYPE_NON_CON coap_msgtype. I reckon changing this would not help. How can I achieve confirmable communication with the coap client example? Do I need to enable another coap library than coap utils?

The coap server example, which uses the openthread coap api, however, calls otCoapMessageInit()  at application level, which takes an otCoapType aType argument. Thus, it looks like the openthread coap api supports confirmable coap communication. Is this correct? I have not tested this yet.

Another thing, in the header of coap_send_request() in coap_utils.h, it says

 * @retval 0    On success.

 * @retval != 0 On failure.

However, the return value of the functions called from in coap_send_request() is only checked against a negative value. Indeed, according to the headers of the functions called in coap_init_request(), which is called by coap_send_request(), only a negative value should indicate an error. The second and last function returning an error code in coap_send_request() is coap_send_message(), but I cannot find any documentation of the return value of sendto() called by this function. Is the header of coap_send_request() wrong?
I have seen return values such as e.g. 38 and 48 from my coap_send_request() calls, but I am still receiving the packets. So what do these numbers indicate?

[Edvin]

Hello,

Sorry for the late reply. I had to check in with our Thread team.

The coap_utils does not support confirmable communication for now. The easiest way to acheive confirmable coap communication is to use OpenThread CoAP API in a similar way to how it is presented in the coap_server sample.

There is a bug in the coap_utils.h description. In fact, coap_send_request() returns retval >= 0 on sucess, and retval < 0 on failure.

Zephyr sendto() description:

https://docs.zephyrproject.org/latest/reference/networking/sockets.html?highlight=sendto#c.zsock_sendto

Thank you for reporting the retval description bug. It has been fixed now:

https://github.com/nrfconnect/sdk-nrf/pull/2899/commits

Hopefully, this answers some of your questions.

Best regards,

Edvin

[Amadeus]

I understand, thank you.

I tried to change to the OpenThread CoAP API by doing this:

However, nothing is received by the server. No error messages are printed either, the program executes the whole function.

If I use the Zephyr CoAP API with the same IPv6 address as I have used in the example above, it works fine:

Is there anything obviously wrong with the function calls in the OpenThread CoAP example? Indeed, I have added the resources with the appropriate URI options, which I guess is confirmed by the fact that it works with the Zephyr implementation.

For the record, I have merged together the client and server example in the ncs so both are able to initiate traffic on the same port.

[Edvin]

Is there some way for me to reproduce this? Can you verify that the behavior is the same in NCS Version 1.3.0? If so, is it possible to zip the project folder and attach it here? I can't see anything wrong in the snippets you have sent, but I am not sure I would detect any bugs just by looking at it. Also, I am not sure of what changes you did (URI options). And I don't know what your merge looks like. Is it reproducible on nRF52840 DKs?

BR,
Edvin

[Amadeus]

I zeroed the uninitialized messageInfo struct and then it worked as expected.

Now I have some questions about confirmable messaging:

- When I send a confirmable message, should I always add an otCoapResponseHandler in otCoapSendRequest()? 

- At the receiving side, when receiving a confirmable message, should I always respond with a message taking an OT_COAP_TYPE_ACKNOWLEDGMENT type, by calling otCoapMessageInitResponse() (which uses the message ID and token of the received message) and otCoapSendResponse()?

When trying to do this, the otCoapResponseHandler gets called at the sender after something like 20 seconds after the confirmable request, and sometimes keeps getting called, which I reckon isn't right. What can be the reason for that?

[Edvin]

Where is otCoapResponseHandler implemented, and what does it look like? Do you seee any Result or messageinfo? Anything that can be relevant?

Would it be possible to share a project so that I can look at what you are talking about? Is this related to the coap_client example?

[Amadeus]

Hello, I fixed the problem by using the coap type OT_COAP_CODE_CONTENT instead of OT_COAP_CODE_PUT in the ack response.

I cannot find any documentation of what the different otCoapCode enumerations really means in terms of the coap api implementations. What difference did this change make?