Paired host's details in multi-hop scenarios

[kaushalyasat]

Hi,

I have multiple sensors (SEDs) and one or more Hosts (FTDs) in our application. Based on the distance or other similar issues, there is a possibility that a sensor may connect to it's paired host via another router/leader. I want to find out the details of the paired hosts RLOC16, ext address etc. I tried parent info from CLI, but that reports the immediate connection, not the last one. Is there a possibility to get this information?

Cheers,

Kaushalya

[Sigurd Hellesvik]

Hi,

Which protocol are you using?

Regards,
Sigurd Hellesvik

[kaushalyasat]

Hi Sigurd,

CoAP on OpenThread. My current SDK is 2.3.0.

Cheers,

Kaushalya

[Sigurd Hellesvik]

And you try to get the address of the CoAP Server from the CoAP Client?

[kaushalyasat]

Yeah. What I am trying to get is like RLOC and Ext address of the paired host, not the parent, in case of multi hop scenario.

[Sigurd Hellesvik]

Do you need this before or after the CoAP Server and CoAP client has communicated with each other?

I suspect we have an XY problem at our hands here.
What are you really trying to do?

[kaushalyasat]

Sigurd Hellesvik said:

I suspect we have an XY problem at our hands here.
What are you really trying to do?

What I am trying to do is to have a retained data section in my SED to have critical information stored  which could help us in our field issue debugging. What I need the RLOC and extended addr of the coap server is to trace the packets in a wireshirk log. In single hop scenarios, this is not an issue, just by looking at the RLOC of the SED, I can work out the RLOC of the CoAP server. But in multi-hop scenarios I don't have that luxury. It is not impossible I think but if I know the CoAP server's details like RLOC and ExtAddr, it is far more easier. So this is the requirement.

The requirement came from that we see some of our SEDs "seemingly" all stop sending data after a like couple of months time. We have not being able to recreate the issue in the lab, so still not possible to find the root cause. We have so far seen that the SEDs log says it is sending the packet but the CoAP server doesn't seem to get it. We still haven't been able to detect whether the packet in the air or not. So we are adding these info into a uninitialized RAM section of the SEDs, so that if we see this issue again, we can debug bit deeper.

Sigurd Hellesvik said:

Do you need this before or after the CoAP Server and CoAP client has communicated with each other?

I guess this doesnt matter for my purpose. Could be after, as the issue so far happens way after the first client server comms.

Cheers,

Kaushalya

[Sigurd Hellesvik]

That explains it well, thanks for taking the time.

In our CoAP Client and CoAP Server samples we have provisioning functionality.

If I build the CoAP Client sample with the logging snippet, I get the following log after provisioning the server and the client:

"coap_client_utils: Received peer address: fdde:ad00:beef:0:1d7b:c000:ca41:673d"

This would be the address you need, right?
This method should not care about number of hops.