Wb55 - otThreadGetMeshLocalEid return value changing

[AndyCalderbank]

Hi,

I'm currently using a custom board containing a WB55 chipset. My application running on this uses the Thread (open thread) FTD firmware (v1.23.0.0)

My understanding is that given a fixed mesh local prefix calls to otThreadGetMeshLocalEid should return a consistent value through reboots.

This does not seem to happen as otThreadGetMeshLocalEid returns a different address each time. Note, thread starts and is usable I'm just not getting a stable address. I'm not using COAP - straight Thread (not Matter) and I can get communication across the network so my basic setup is ok.

Information on this subject is scarce and sometimes vague. Can you clarify - Should otThreadGetMeshLocalEid return a stable address across reboots. I'm not able to upload my source.

Cheers

Andy

[EPASZ.1]

Mesh-Local Endpoint Identifier (EID) is an IPv6 address derived from the Thread network's Mesh-Local Prefix combined with the device's RLOC16.

As explained here https://openthread.io/guides/thread-primer/ipv6-addressing, one part of the ML-EID is randomly chosen on commissioning. So not guaranteed to be stable across commissioning attempts. But if the device simply reboots and then attaches to the same network, the MLEID should stay the same.

My expectation would be that you are probably not saving the NVM data to Flash before rebooting / doing a power cycle? This would mean that the device needs to go through the commissioning again as a "new device" after power on and so receives a new MLEID. To solve this, you can check out the Thread_NVM example application which shows how to save the data to Flash and then load them on power on. Related to this is the function otInstanceErasePersistentInfo() which erases the info from RAM buffer - it is, by default, used at the start of most examples.

[AndyCalderbank]

I've implemented the changes from the NVM flash example but that has no impact - I still get a changing EID after each reboot.

I decided to ignore that for the moment and look at whether I could get the device to operate an SRP server for service discovery but that doesn't work either. Calls to otSrpServerGetState return error 126 which appears to be undocumented. 

I could of course just use broadcasting but that kind of defeats the point.