IEEE EUI64 resolution to IP (RLOC)

[Catalin I]

Hello,

Is there in Thread, the equivalent of ARP protocol, MAC address to IP resolution (and vice-versa)?

All Mesh nodes have their own hardware MAC address, IEEE EUI64, unique.
When the nodes are in a Mesh network, I would like to send messages to a certain MAC address, but I need RLOC IP address.

There is the IEEE 802.15.4 Extended MAC address(cli: extaddr command), but this is randomly assigned when Thread is started, right?

Could I force ExtAddr to be the real MAC address?

thanks,

Catalin

[Jonathan Hui]

The Thread 1.1.1 Section 3.2 requires the IEEE 802.15.4 Extended Address to be set to a randomly generated value after the device has been commissioned.

That said, the otLinkSetExtendedAddress() API allows overriding the specified behavior and setting the IEEE 802.15.4 Extended Address to a value specified by the user. Note that this API can only be called when Thread is in the disabled state.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/91540811-e786-42d0-8370-50e50f1eb547%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Catalin I]

OK, I confirm that using otLinkSetExtendedAddress() before otThreadSetEnabled() and I was able to force MAC hardware address to Extended Address.

I can't judge if this will bring a "security issue" or breaks Thread Specifications.

But definitely, helps in understanding what IPv6/role takes an actual device, known by MAC hardware address from factory.

Thanks,

[cabled]

This topic is of some interest... Just to make sure I'm understanding this correctly, otLinkSetExtendedAddress() before otThreadSetEnabled allows us to force the MAC hardware address as the extended address and the Thread network can subsequently be initialized (joiner etc) with the desired MAC hardware address? 

Theoretically, we could then maintain a full device table (in an NCP) by checking uniqueness against the mac address registered during commissioning and also allow for table updates when the IP addresses change?

[Jonathan Hui]

See responses below:

On Tue, Sep 11, 2018 at 8:11 AM cabled <st...@leading-edge-automation.com> wrote:

This topic is of some interest... Just to make sure I'm understanding this correctly, otLinkSetExtendedAddress() before otThreadSetEnabled allows us to force the MAC hardware address as the extended address and the Thread network can subsequently be initialized (joiner etc) with the desired MAC hardware address? 

Yes, that is correct. As mentioned, however, this behavior does not conform to the Thread 1.1.1 Specification.

Theoretically, we could then maintain a full device table (in an NCP) by checking uniqueness against the mac address registered during commissioning and also allow for table updates when the IP addresses change?

Thread Commissioning was designed explicitly not to maintain any persistent state about Thread devices joined to a Thread network. That said, you could implement your own custom logic to perform what you said. I'm not sure how you plan to update an IP to MAC address table mapping. The IEEE 802.15.4 Extended Address is typically only used in link-local scoped messages.

--

Jonathan Hui

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/74210739-55c0-48f0-a955-6953c804defb%40googlegroups.com.

[cabled]

I'd actually considered adding another IPv6 address using the mesh local prefix and the mac address but since that doesn't have any sort of exclusion or check, you could theoretically end up with duplicate addresses (one auto-assigned and the other user initialized) even if the chances are pretty low.

So far my thoughts are more along the lines of the following:

1) Initializing the NCP device as a the initial leader and allocating a known ipv6 address 

2) Having EDs coap post their mac address to the NCP right after commissioning. 

3) NCP now has a record of the mac address and corresponding IP address of the EDs and should be able to maintain a full device table via some third party service... Unless there is some way to achieve a full device table (including devices that are behind other routers) via wpantund/wpanctl that I have not noticed...  

4) In this way, it should be possible to maintain clarity over where subsequent coap data transmissions are coming from since I can reverse lookup the IP address to a known mac and thus an identified device. 

ultimately what I was trying to work through was 

a) how to get a complete picture of all EDs that might be on a mesh

b) and how to easily identify devices if necessary (say abnormal data readings or dead battery etc)