OTBR and FTD lost on-mesh prefix fd11:22:: address

[yinzhou tao]

I want to make a thread protocol based luminaire product, there will be 300+ luminaires and 10+ OTBRs, and then control them through the cloud platform.
Now I need to verify if so many devices can run stably, I got 100+ 833 modules to do the test and the THREAD are set to FTD.
Then I found some problems during the test.
When I used only one OTBR during the test, if the number of modules was around 40, the network would run relatively stable, even if the OTBR rebooted or 40 modules rebooted at the same time, the connection could be restored normally and seen online in the cloud platform.
However, when the number of modules exceeds 60, there is a high probability that the modules and OTBR will lose the fd11:22 address and cannot recover it, which will cause the modules to be unable to connect to the Internet. OTBR has a way to retrieve the fd11:22 address, the module can't retrieve the fd11:22 address even if it is rebooted. But as soon as I reduce the number of modules to about 40, the module will automatically restore the fd11:22 address.

Attached is my captured packet.

Thanks in advance.

Best,

tao

[Jonathan Hui]

How are you configuring the fd11:22:: prefix? Note that OpenThread does not store prefix information in non-volatile storage. If the OpenThread process exits for whatever reason, the prefix information will need to be configured again.

Can you provide more detail on your setup? What OpenThread commit are you using? Also, can you provide the OpenThread logs from OTBR with a timespan that includes before and after the fd11:22:: prefix is lost?

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/ac007886-e809-4c2e-9ca0-a6a119ab67c7n%40googlegroups.com.

[yinzhou tao]

I used this command to add the fd11:22:: address when I created the thread network in OTBR: ot-ctl prefix add fd11:22::/64 pasor. And there will be a monitor program to monitor this address and use this command again to add it when it is not there.

The fd11:22 address of the EndDevice is obtained automatically after connecting to the thread network and is not set in advance.
The SDK I am using is ORBR: NCSv1.8.0, otbr-posix commit: f0bd2166467464c3fac23b28f7669179ee9ba33 . The EndDevice is also using NCSv1.8.0.

I read the OTBR logs, and there is indeed a reset log, so I can understand losing addresses. I mainly want to know the reason why the EndDevice will lose the address.
A few more questions: Are all the addresses in fd11:22 provided by OTBR?
Since the EndDevice are all FTDs, the network may be chained. Are all the fd11:22 addresses on the FTDs provided by the OTBR, or are they assigned by the router that the child is connected to?

Then I observed that when the OTBR is running, sometimes it will be child and sometimes it will be router, but at this time the Internet access of the EndDevice is still normal, I wonder if losing addresses has anything to do with this?

[Jonathan Hui]

On Tue, Mar 1, 2022 at 3:01 AM yinzhou tao <taoyi...@gmail.com> wrote:

I used this command to add the fd11:22:: address when I created the thread network in OTBR: ot-ctl prefix add fd11:22::/64 pasor. And there will be a monitor program to monitor this address and use this command again to add it when it is not there.

The fd11:22 address of the EndDevice is obtained automatically after connecting to the thread network and is not set in advance.
The SDK I am using is ORBR: NCSv1.8.0, otbr-posix commit: f0bd2166467464c3fac23b28f7669179ee9ba33 . The EndDevice is also using NCSv1.8.0.

I read the OTBR logs, and there is indeed a reset log, so I can understand losing addresses. I mainly want to know the reason why the EndDevice will lose the address.

If the OpenThread process on OTBR restarts, then all configurations stored in volatile memory will be lost, including the prefix information. Thread Border Routers advertise the prefix information in Thread Network Data and Thread devices propagate the Thread Network Data throughout the Thread Network. When OTBR resets, the prefix will be removed from the Thread Network Data and Thread devices will remove any IPv6 addresses configured from the removed prefix.

 

A few more questions: Are all the addresses in fd11:22 provided by OTBR?
Since the EndDevice are all FTDs, the network may be chained. Are all the fd11:22 addresses on the FTDs provided by the OTBR, or are they assigned by the router that the child is connected to?

Thread devices typically use IPv6 Stateless Address Autoconfiguration (SLAAC) to assign an address from a prefix. OTBR only provides the prefix as described above. Each Thread device configures an IPv6 address from the prefix using SLAAC.

Then I observed that when the OTBR is running, sometimes it will be child and sometimes it will be router, but at this time the Internet access of the EndDevice is still normal, I wonder if losing addresses has anything to do with this?

Thread devices will retain their IPv6 address when transitioning from child to router as long as the prefix remains in the Thread Network Data.

--

Jonathan Hui

[yinzhou tao]

    When OTBR resets, the prefix will be removed from the Thread Network Data and Thread devices will remove any IPv6 addresses configured from the removed prefix.   

When I tested multiple OTBrs, I also had problems with  EndDevices  losing FD11:22 addresses.

If there are multiple OTBR and one of them is reset, the address of FD11:22 is temporarily lost,all the other OTBRs are working properly, will the fd11:22 prefix in Thread Network Data configured be  removed  ?  

If there is only one OTBR and IPv6 addresses are removed after reset, my monitor program adds the fd11:22 prefix  back later. Why sometimes the fd11:22 address of the EndDevices is still not recovered ?

[Jonathan Hui]

If only one OTBR is publishing the on-mesh prefix and that OTBR resets, then the on-mesh prefix will be removed from the Thread Network Data.

If you have an automatic process to re-add the on-mesh prefix after reset, then it should be added back to the Thread Network Data. You can use the netdata show CLI command to view the contents of the Thread Network Data on both OTBR and end devices.

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/22879690-138c-496f-8306-be8f9d2f8629n%40googlegroups.com.