OpenThread provisioning response

RE: OpenThread provisioning response

Amadeus — Fri, 04 Sep 2020 06:42:02 GMT

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.

RE: OpenThread provisioning response

Edvin — Thu, 03 Sep 2020 14:33:30 GMT

Hello,

First of all, sorry for the late reply.

Have you checked out the CLI example? (NB: If you use the NCS one, you need to add "ot " before the CLI commands.

You can use commands like "ot cli router table" to see a table of all the routers, with some parameters like number of hops, extended MAC address, and RLOC address.

The RLOC address can be used to reach the node from within the network using a Mesh Local address.

I used the following cli commands to ping another device:

uart:~$ ot router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  9 | 0x2400 |       43 |         1 |     3 |      3 |   6 | b643fd5dc3a95b44 |
| 25 | 0x6400 |       63 |         0 |     0 |      0 |   0 | e6c92d2a39ea47b3 |
| 43 | 0xac00 |        9 |         1 |     3 |      3 |   5 | e6675f027885bdf7 |

Done
uart:~$ ot ping fdde:ad00:beef::ff:fe00:2400
Done
16 bytes from fdde:ad00:beef:0:0:ff:fe00:2400: icmp_seq=2 hlim=64 time=22ms
uart:~$

As you can see from Jørgen's answer here, the mesh local address will always be:

fdde:ad00:beef::ff:fe00:<RLOC>

You can access the openthread cli implementation from the openthread github. E.g. the router table command is implemented here:

https://github.com/openthread/openthread/blob/b940baf9b6cad48feaab60848f6e006bffe79d4e/src/cli/cli.cpp#L3425

You can use this api from your application.

Is this something you can use?

Best regards,

Edvin

RE: OpenThread provisioning response

Amadeus — Thu, 27 Aug 2020 09:28:39 GMT

Update: I temporary fixed the problem by, instead of sending an otCoapSendResponse() in provisioning_response_send(), I use the Zephyr Thread Api and call coap_send_request(). This way, the client who sent the provisioning request receives a message from both (currently) two servers. I tried first using the OpenThread API and otCoapSendRequest() instead of otCoapSendResponse(), but that does not work; the client does not receive any messages. Any takes on why?

However, I still think that the thread network IP addresses should be available somewhere without the need of this provisioning procedure.

Furthermore, coap_send_request() calls coap_init_request() in ncs/nrf/subsys/net/lib/coap_utils.c. This function takes a coap_msgtype argument but this is set to COAP_TYPE_NON_CON. Why is this? Why doesn't coap_send_request() take a coap_msgtype argument so that this could be specified at the application level without the need of changing the SDK? Is there any reason for this, i.e. that confirmable messages not are stable or anything like that?

RE: OpenThread provisioning response

Amadeus — Tue, 25 Aug 2020 18:42:11 GMT

Thank you for your answer.

The outlined procedure, however, only works with one server at a time. E.g. if I enable provisioning on two servers simultaneously, and send a multicast provisioning request with a client, both servers receive this message and sends a provisioning unicast response. However, the client only receives one of these responses, and I reckon this is due to how coap_set_response_callback() is defined; that the callback is cleared after the first call or something like that. Thus, only one server can be provisioned at a time. If possible, I want to be able to acquire the IPv6 addresses of several servers without needing to provision one by one like this.

Since the thread network already is established before this provisioning routine, shouldn't the IPv6 addresses be readily available for the thread routers somewhere? E.g. the link and mesh local addresses? I was of the impression that such information was exchanged during the thread network creation and that the routers could address any node in the network by its IPv6 address without the need of "extra" provisioning by making the servers reply with their address upon receiving a multicast provisioning request like in the sample. Is this possible?

Yes, I can observe any IPv6 address of any node by uart commands in the console, but I cannot find a way to observe all nodes and their corresponding IPv6 addresses from one particular (router) device. I.e. I need to call ot ipaddr on the separate nodes to see their addresses, but ideally I want to observe all addresses from one device.

For instance, in the OpenThread specification, it says "A Full Thread Device (FTD) always has its radio on, subscribes to the all-routers multicast address, and maintains IPv6 address mappings." Doesn't this mean that addresses of the network nodes should be available (for the FTD's) somewhere?

Thank you for the ML-EUD advice. I have also found a way to retrieve the EUI64 addresses of my devices, which I think is static and does not change, which is useful to me.

RE: OpenThread provisioning response

Edvin — Tue, 25 Aug 2020 14:30:26 GMT

Hello,

I spoke to our thread team regarding your ticket. Here is a summary of what they said:

Provisioning works like this in the coap server/client examples:
1. The Coap server enables provisioning, now it listens to the multicast message from coap clients.
2. The Coap client sends a multicast provisioning request.
3. The Coap server receives the request, and executes on provisioning_request():
https://github.com/nrfconnect/fw-nrfconnect-nrf/blob/master/samples/openthread/coap_server/src/ot_coap_utils.c#L184
4. In our case on provisioning_request() calls deactivate_provisioning():
https://github.com/nrfconnect /fw-nrfconnect-nrf/blob/master/samples/openthread/coap_server/src/coap_server.c#L62
5. The Coap server replies to the coap server with a unicast message.
6. The Coap client receives the unicast message, now it knows the unicast address of the coap server and sends light toggle requests directly to it.

So the functions that you need to change are in the files that are linked.

You say that you know "how to find them (the addresses) via uart and openthread commands". You can look at the implementation of the CLI commands in the openthread repo on github:

https://github.com/openthread/openthread/blob/8370395c47333a612e117b38c3b034e61e3b8597/src/cli/cli.cpp

For example the ipaddr command is found here:
https://github.com/openthread/openthread/blob/8370395c47333a612e117b38c3b034e61e3b8597/src/cli/cli.cpp#L1639

I assume you are using OpenThread in NCS. All the header files comes from this repo:

https://github.com/nrfconnect/sdk-nrfxlib/tree/master/openthread/include/openthread

So you can use this to check the OT API.

One extra note on addressing:

There is something called ML-EID, which you can use when communicating between the nodes. This is a randomly assigned address that is provided after provisioning. This address remains the same over power cycles and is never changed during the lifetime of the device, unlike the IP address, which may change if the device is powered off, and then reconnected to the network.

Hopefully there are some useful pointers here.

Best regards,

Edvin

RE: OpenThread provisioning response

Edvin — Thu, 20 Aug 2020 13:57:27 GMT

Hello,

I am sorry for the late reply (on your other ticket as well). Most of our Thread team is on vacation right now, but some are coming back on Monday. I was hoping to hand your tickets over to him when he returns. I am sorry for the delay. In the meantime, I will try to check with some different people and see if I can find someone who can answer your questions.

Best regards,

Edvin