Behaviour of functions in the cord_ep module

Help
1

Hello everyone,

I am a beginner in RIOT and currently I’m working on a project consisting of two node types: one serving as a Resource Directory (according to RFC 9176 - Constrained RESTful Environments (CoRE) Resource Directory) and the other one as an endpoint, trying to register its resources to the RD. The RD is firstly initialized as a normal UDP server, receiving various requests from the endpoints using ‘sock_udp_recv’. In order for the endpoint to discover the registration interface resource of a RD, multicasting is used to sent GET requests to all possible nodes in the scope. For testing purposes, both nodes are actually running on native cpu using tap interfaces to communicate with each-other. The communication between them when using ‘sock_udp_recv’ and ‘sock_udp_send’ works fine. The problem is, when I call ‘cord_ep_discover_regif’ in the endpoint to send GET /.well-known/core?rt=core.rd* through multicasting to all the other nodes, in order to discover the RD, the RD receives the request, but fails to send the response back. The server sends a response back, as it returns the number of bytes that were succesfully sent, but the endpoint stays for a long time at the function cord_ep_discover_regif apparently waiting for the response. After a particular time this function returns ‘timeout’, then the rest part of the endpoint code is carried out where ‘sock_udp_recv’ is called (for testing). At that moment the response from the server is received and saved in the endpoint buffer. This makes me think the problem lies in the function ‘cord_ep_discover_regif’. In that case I would have two main questions:

  1. When the request from the endpoint is received (using ‘cord_ep_discover_regif’), it is not correctly decoded or formatted. Instead of GET /.well-known/core?rt=core.rd* something like Bѣ>�.well-knowncoreJrt=core.rd is printed in the pyterm using printf with %s. I’ve tried various formating types but nothing seems to work. Is there any specific configuration or something else that should be carried out to the methods like cord_ep_discover_regif, or this behaviour is expected to be normal?

  2. Regarding the functions like ‘cord_ep_discover_regif’ do they expect a particular response syntax in order to receive the message and stop the waiting? I’ve tried to send messages back like this:

coap_pkt_t pdu;
coap_parse(&pdu, server_buffer, res); // Parse the received CoAP message const char *response = “;rt="core.rd";ct=40,” “</rd-lookup/ep>;rt="core.rd-lookup-ep";ct=40,” “</rd-lookup/res>;rt="core.rd-lookup-res";ct=40”;

gcoap_resp_init(&pdu, server_buffer, res, COAP_CODE_CONTENT); // 2.05 Content response coap_opt_add_format(&pdu, COAP_FORMAT_LINK); // Set content format to Link Format (ct=40) memcpy(pdu.payload, response, strlen(response)); // Copy the payload pdu.payload_len = strlen(response); // Set payload length

res = sock_udp_send(&sock, pdu.hdr, pdu.options_len + pdu.payload_len, &remote);

so the function would not stop waiting in that case, but sock_udp_send would receive the message correctly. I was just wondering if there is maybe a particular data structure expected for the function or a stricter syntax, which I may be doing wrong. Any help would be apprecited.

Thank you for any help you can offer!

2

Formated code snippet from the second point below:

coap_pkt_t pdu;
coap_parse(&pdu, server_buffer, res); // Parse the received CoAP message
const char *response = "</rd>;rt=\"core.rd\";ct=40,"
                    "</rd-lookup/ep>;rt=\"core.rd-lookup-ep\";ct=40,"
                    "</rd-lookup/res>;rt=\"core.rd-lookup-res\";ct=40";

gcoap_resp_init(&pdu, server_buffer, res, COAP_CODE_CONTENT); // 2.05 Content response 
coap_opt_add_format(&pdu, COAP_FORMAT_LINK); // Set content format to Link Format (ct=40) 
memcpy(pdu.payload, response, strlen(response)); // Copy the payload 
pdu.payload_len = strlen(response); // Set payload length

res = sock_udp_send(&sock, pdu.hdr, pdu.options_len + pdu.payload_len, &remote);
4

Problem solved: and the solution was relativ simple. The way the messages were received was not appropriate. Instead of using sock_udp_recv and sock_udp_send for message exchange between the nodes, gcoap is used for the whole message handling in the RD node. cord_ep_discover_regif for instance discovers the registering resource interface of the Resource Directory by accessing the coap_resource_t with the URI /.well-known/core, which triggers the respective handler. The reason behind the wrong message formatting is apparently the fact, that through sock_udp_recv a whole CoAP packet comming from the functions of the cord module was saved as a byte stream in the buffer without extracting important components (like header, payload, options etc) so that any attempt to print it led to misinterpretation or wrong formatting.