This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

OpenThread provisioning response

Hello,

I have a device which sends a provisioning request to two other devices in a Thread network. They both receive the request and both send a provisioning response, i.e. both devices receiving the provisioning requests calls provisioning_response_send(). However, the requester device only receives one response, not two as it is supposed to. I.e., on_provisioning_reply is only called one time at the requester side. Why is this? I am trying to append the IPv6 addresses received in the responses in a list to make it possible to send unicast messages to a particular device at a later time, but this is not possible with this issue occurring.

Update: I reckon this provisioning procedure is sample-specific and not part of the OpenThread specification, thus, only one server may be paired with a client at a time this way? In that case, where can I find the IPv6-addresses of the connected nodes on the thread network in the application code? I can find them via uart openthread commands, but not in the source code. Furthermore, I want to be able to address a specific device in the network, say device A, located at a specific physical position. Therefore, I need to use e.g. a MAC or EUI64 address or DEVICEID/FICR address or something similar to look up the device's IPv6 address before communicating. Where can I find such information?

  • Hello, 

    Since the IP addresses I want to acquire is supposed to be from child nodes, the router table probably won't help. From Jørgen's answer in the other ticket, it looks like the way of acquiring other devices IP addresses is the same as I am doing now, i.e. sending a multicast message and listen to the responses. This is a bit surprising to me, as I thought these addresses should be available after the mesh link discovery and network creation. In any case, thank you for your help. I will open another ticket regarding Coap confirmable/non-confirmable messages.

Related