Skip to main content
Patrick Chwalek
Patrick Chwalek
Associate III
October 13, 2019
Question

How to get Mesh Local EID (OpenThread)?

  • October 13, 2019
  • 6 replies
  • 1889 views

Hello Everyone,

I've been messing with the OpenThread API for the last few days and I have been scratching my head on trying to get the mesh local EID IPV6 address using the API. So when running CLI CMD example application, after connecting the nodes, you can clearly see all the IP values when entering "ipaddr" and that's essentially what I want in my program, specifically the mesh-local EID. However, I tried otThreadGetMeshLocalEid but the memory location returned is just empty. I also tried to look at the memory locations for the returns of otIp6GetUnicastAddresses and otIp6GetMulticastAddresses. I know my node is on my thread network because I am validating with other nodes running the CLI CMD example. My naive mental model is that if I can do it in the CLI CMD example, I should be able to do it with my own application using the given API for IPCC.

Anyone have any suggestions?

I am aware that the multiboard example for the STM32WB Nucelo board uses static IPs that are allocated by the application. I am not sure why its done that way, assuming for ease of implementation, but I wanted to rather use dynamic IPs since my application will have many nodes and trying to create a static IP for each will be a headache.

This topic has been closed for replies.

6 replies

Remi QUINTIN
Remi QUINTIN
Technical Moderator
October 17, 2019

The otThreadGetMeshLocalEid function returns a reference on the Mesh Local EID.

The Thread_Coap_Data_Transfer application, available in the CubeWB FW package, calls this API.

error = otMessageAppend(pOT_Message, otThreadGetMeshLocalEid(NULL), sizeof(otIp6Address));

Strange that you get a null value.

I would recommend you to look at  the example mentioned above in which this API is used to get the dynamical address to be sent to remote nodes  with a unicast transfer.

Patrick Chwalek
Patrick ChwalekAuthor
Associate III
November 20, 2019

Hi Remi,

So I just now had time to get back into it. It looks the pointers I get back from otIp6GetMulticastAddresses(NULL), otThreadGetMeshLocalEid(NULL), and otThreadGetLinkLocalIp6Address(NULL) all point to memory addresses that are NULL. Is there something I'm not understanding?

I referenced the example and don't immediately see what is being done different. I have trouble building the example files because of some missing dependencies (I think its a migration issue since I use TrueStudio).

Best,

Patrick

Patrick Chwalek
Patrick ChwalekAuthor
Associate III
November 21, 2019

Calls to myRloc16(NULL) and isEnabledIpv6(NULL) return fine but those are non-pointers.

Patrick Chwalek
Patrick ChwalekAuthor
Associate III
February 10, 2020

I want to update this post since I continue to experience issues with getting null returns. Recently, I attempted to transition my nodes from using global IPs to mesh-local IPs for unicast messaging. However, I quickly realized that if attempting to unicast with a mesh-local IP peer address, that message does not get received by any other nodes. After much debugging, I realized that the mSockAddr is being left blank when the following is called: 

memcpy(&OT_MessageInfo.mSockAddr, otThreadGetMeshLocalEid(NULL), sizeof(OT_MessageInfo.mSockAddr))

resulting in the receiving node to disregard the packet. As a sanity check, I replaced the above with a dummy peer IP:

otIp6AddressFromString("fd11:22::c34c:7994:cccc:4b82", &OT_MessageInfo.mSockAddr)

and now the other node was able to receive the packet. All the above was verified with wireshark on a node running the OpenThread Border Router stack.

Does anyone else have null pointer return issues and/or does anyone from ST have any idea if its something I am setting up incorrectly?

Remi QUINTIN
Remi QUINTIN
Technical Moderator
February 11, 2020

​We identified the issue and it will be corrected in the next CubeWB FW package V1.5.0 that is expected to be released next week.

Patrick Chwalek
Patrick ChwalekAuthor
Associate III
February 11, 2020

Much appreciated @Remi QUINTIN​ , thank you!

Terms & ConditionsAccessibility statement