Mining hop count

[brian-level]

The mHopLimit field in otMessageInfo seems to decrement for each multicast hop taken (using realm or greater scope addresses and MPL). Unicast messages don't seem to do this. Is this on purpose? I'd like to be able to get hop-count information for unicast messages to mesh-local addresses and I'd assume the underlying packets are keeping track of hop-limit / ttl ? Is there a reason that mHopLimit isn't updated in this case?

[jwhui]

Thread forwards unicast IPv6 datagrams using the RFC 4944 Mesh Addressing header, which occurs at a layer below the IP layer. Note that the Mesh Addressing header does include its own Hops Left field, which Thread does decrement:

openthread/src/core/thread/mesh_forwarder_ftd.cpp

Line 697 in 6e975c5

meshHeader.DecrementHopsLeft();

In contrast, Thread forwards using multicast IPv6 datagrams using MPL, which is a part of the IP layer.

[brian-level]

Thanks. I don't see anywhere the Hops-Left field is accessible to the user (or the mesh header itself even). Maybe the mHopLimit field in the message info passed to the receive-udp callback could reflect HopsLeft, and that would match the multicast behavior and not need any new API? I could work on that or some other idea?

[jwhui]

If we want to expose this value to the application layer, I would say better to define a new field rather than overloading the existing field used to communicate the IPv6 Hop Limit.

Note that a given IPv6 datagram may be composed of multiple 6LoWPAN fragments. So we should think about what value to present in such situations.