How to identify two or more CoAP clients connected to the same Server

[kaushalyasat]

Hi, How can I get the RLOC16 or similar ID from the CoAP clients connected to my CoAP server? I need to get this information from the messages that the clients send. 

Cheers,

[Sigurd Hellesvik]

Hi,

See otThreadGetRloc(otInstance *aInstance)

Regards,
Sigurd Hellesvik

[kaushalyasat]

Hi Sigurd,

Thanks for your reply. Wouldn't this retrieve the RLOC of the server? 

I tried the otThreadGetRloc16 () function, but it only got the RLOC16 of the server.

In my instance more than one coap clients will be sending messages to the server. So server needs to get the RLOC16 of each client based on each message. 

My client handler in the server is like this 

static void temp_request_handler(void *context, otMessage *message, const otMessageInfo *message_info)

{

...

}

I tried looking at each of the variables passed into the handler, but I couldn't find any RLOC16 parameter anywhere. 

 Cheers,

[Sigurd Hellesvik]

Hi,

kaushalyasat said:

I tried the otThreadGetRloc16 () function, but it only got the RLOC16 of the server.

Ah right yes. I misunderstood the question.

For the child RLOC16:

On my OTBR I run "sudo ot-ctl child table" which gives me the following:

See child table.

This links to an API command that you should be able to call to get the RLOC value.

PS: You can also test these CLI commands using our OpenThread CLI sample.

Regards,
Sigurd Hellesvik

[kaushalyasat]

thanks, I am using the CLI commands to query the child table and other info. It is a great tool. I can trace that CLI uses 'otThreadGetChildInfoByIndex()' function to get 'childInfo.mRloc16'. But that does not help my case as I need to decode RLOC16 from the message itself to identify who send it. I can encode the client RLOC16 with the message itself, but that I feel like wasting radio bandwidth. I think definitely the senders RLOC16 (or some other address parameter) is available at app level based on the message. So what I am looking for is an API call to extract that from the message, inside the message handler.

[kaushalyasat]

Hi, Any reply to this? I think RLOC16 is not a static value which identifies the client accurately. So I am thinking of getting the extended MAC or something similar. Any idea?

[Sigurd Hellesvik]

Hi,

Sorry for the delay.
I were looking for a way to do this yesterday, but have not been able to do so yet.

I asked our developers about this, and this is what they said:

"
Notice that the RLOC16 is used by the child as MAC source address, by this is a Link Layer parameter, not propagated to the Application Layer (CoAP).
The customer should find better ways to identify the end point at an application level.
IPv6 are available at CoAP level, so that could be a way to identify, combined with network diagnostigs:
https://github.com/openthread/openthread/blob/main/src/cli/README.md#networkdiagnostic-get-addr-type-

"

So that at least gives us some pointers to where we could look.

I will keep digging for some way to do this.

Let me know if you find anything yourself as well.

Regards,
Sigurd Hellesvik

[kaushalyasat]

Hi Sigurd, Many thanks for your efforts, highly appreciated. So the suggested way is to use IP6 from client message? How can we retrieve this info from message itself? Any API calls? 

Thanks again,

[Sigurd Hellesvik]

Hi,

One step closer: I am able to print the server IP from the client I think.

From the provisioning coap command I were able to print the IP address as such:

diff --git a/samples/openthread/coap_client/src/coap_client_utils.c b/samples/openthread/coap_client/src/coap_client_utils.c
index 52772ace6..f86d0c725 100644
--- a/samples/openthread/coap_client/src/coap_client_utils.c
+++ b/samples/openthread/coap_client/src/coap_client_utils.c
@@ -110,6 +110,13 @@ static int on_provisioning_reply(const struct coap_packet *response,
 
        payload = coap_packet_get_payload(response, &payload_size);
 
+    char ipurd[40];
+
+    net_addr_ntop(AF_INET6, from, ipurd, sizeof(ipurd));
+
+    printk("AAAA %s AAA\n", ipurd);
+    
+
        if (payload == NULL ||
            payload_size != sizeof(unique_local_addr.sin6_addr)) {
                LOG_ERR("Received data is invalid");

Regards,
Sigurd Hellesvik

[kaushalyasat]

I am greatly appreciating your efforts in solving this, thank you.

This is done in the client isn't it? It looks like client is getting the server's IP? In my case I want to do the opposite. I need the server to figure out who sent the message. So looks like it should be initiated from the server, if possible. Now the servrer must be getting the clients address details, some for or the other. 

Worst case I can encode the clients address info (Extended MAC?) in the application level packet, where I put my data to be send to the server. Then server can see that the same way it gets my data. This will extend my packet size and also power consumption, but to how much I have to test it. For that I need an API call for the client to get its own address like extended MAC. Can you point me to some thing like that?

Thanks again,

[Sigurd Hellesvik]

Hi,

I think I solved it!

Now that I know the solution, I feel like I should have found it earlier, but as they say "better late then never".

I found the IP address in struct otMessageInfo.

Here is some code for the coap server sample

diff --git a/samples/openthread/coap_server/src/ot_coap_utils.c b/samples/openthread/coap_server/src/ot_coap_utils.c
index 65f1dad17..83ce14f7e 100644
--- a/samples/openthread/coap_server/src/ot_coap_utils.c
+++ b/samples/openthread/coap_server/src/ot_coap_utils.c
@@ -130,6 +130,11 @@ static void light_request_handler(void *context, otMessage *message,
        uint8_t command;
 
        ARG_UNUSED(context);
+    char ipurd[OT_IP6_ADDRESS_STRING_SIZE]; 
+    otIp6Address from = message_info->mPeerAddr;
+    otIp6AddressToString(&from, ipurd, sizeof(ipurd));
+
+    printk("Peer IP: %s\n",ipurd);
 
        if (otCoapMessageGetType(message) != OT_COAP_TYPE_NON_CONFIRMABLE) {
                LOG_ERR("Light handler - Unexpected type of message");

Regards,
Sigurd Hellesvik