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]

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.

[kaushalyasat]

Thanks, we already use this, which is mesh local IPV6 of the coap host. Issue is I wireshark logs can show  IPV6 info only if it can decrypt the packet fully. Unfortunately this is not always possible.But I can always see RLOC/ext address in wireshark packets. Thats why I am trying to get the coap servers RLOC and ext address.

Cheers,

Kaushalya

[Sigurd Hellesvik]

The provisioning service is a custom one we make, so you can send whatever you want.

In the sample, this sends the output of otThreadGetMeshLocalEid(), but you could change this, or append, other stuff, such as otThreadGetRloc or whatever else you need.

[kaushalyasat]

Thanks that sounds like a plan.

Once a RLOC and ext address is allocated to a router/leader, when would it change again? I dont think power cycling changes this.

Would it change if we bring in more routers?

Would it change if we bring in more SEDs?

[Sigurd Hellesvik]

kaushalyasat said:

Once a RLOC and ext address is allocated to a router/leader, when would it change again?

I dont have direct experience with this. I suggest that you check the Thread Specification to see if that says something about if and when RLOC/ext addr may change.
Let me know if you are unable to find anything there, and I will dig a bit.

Oh wait, I see in  OpenThread IPv6 Addressing guide that
"However, because the RLOC is based on the location of the node in the topology, the RLOC of a node can change as the topology changes.",

so I guess the answer is that it may change.

I was not able to find the same for the Extended address, but I think Extended Address will stay the same. As above, check the Thread Spec to be sure.

kaushalyasat said:

Would it change if we bring in more routers?

See above.

kaushalyasat said:

Would it change if we bring in more SEDs?

I suspect not, but check the Thread Spec to be sure.