Reattach behavior after router channel change

[nealsj...@gmail.com]

I am working with a small network of one border router, and one sleepy end device. Both the RCP and sleepy end device are based on nRF52840 and compiled off of openthread commit 397e94d.

The border router is not configured with a channel, so it selects one on startup. The border router is also using the channel monitor/manager features, and the "auto" channel manager selection is enabled.

My sleepy end device is commissioned with a network name, PANID, and master key. On reset or startup, my sleepy end device searches for a network on successive channels and eventually finds the network supported by the border router.

However, I have noticed that whenever my border router resets (manual or due to watchdog), and doesn't select the same channel as it was on before, my sleepy end device does not rejoin the network, and instead remains detached.

I would like to ensure that a device can find and rejoin the network regardless of channel.

I have several questions:

1. Is this intended behavior?
2. How does the attach process differ from the reattach process?
3. Is there a standard openthread mechanism to ensure a sleepy end device can rejoin a network even if the network channel changes and it does not receive a new dataset?

Thanks for all your help!

[Jonathan Hui]

Thread manages network configurations using Operational Datasets. The Operational Datasets include an Active Timestamp that is used to determine which Operational Dataset is the "newest" - the one with the largest Active Timestamp.

In your setup, I assume that the Active Timestamp is always the same value. As a result, the SED does not notice that the channel has changed and cannot attach successfully. Try setting the Active Timestamp to a larger value whenever you change any network configuration parameters.

When a SED is orphaned, it will start sending MLE Announce messages on other channels. However, the SED will not observe that a new Active Dataset exists unless there is a newer Active Timestamp than the one it has (see src/core/thread/mle.cpp#L3816).

The Border Router should be persisting its Active Operational Dataset, rather than creating a new one on each startup.

--

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/16ae81ad-df35-4c21-b668-3f41ae7d78ebn%40googlegroups.com.

[nealsj...@gmail.com]

Hi Jonathan,

Thanks for the information. Setting the active timestamp to a higher value does result in detached SEDs discovering and rejoining the network. However, it seems somewhat difficult to try to autonomously predict a timestamp that is larger than the one in the SEDs active datasets without some clunky method like saving the timestamp to a file and reading it back in and incrementing it.

You mention that a border router should have its operational dataset persist across restart, but this is not what I am experiencing. On every restart my border router discards its previous active dataset and randomly selects network details, including the master key. The only way I have been able to ensure it has the same credentials is to run the below commands at startup. I recognize that the new dataset initialization and not setting the timestamp to a larger value is an issue.

ot-ctl ifconfig down

ot-ctl thread stop

ot-ctl dataset init new 

ot-ctl dataset panid 0xface

ot-ctl dataset extpanid 1111111122222222

ot-ctl dataset networkname OpenThread

ot-ctl dataset masterkey 00112233445566778899aabbccddeeff

ot-ctl dataset commit active

ot-ctl prefix add fd11:22::/64 pasor

ot-ctl ifconfig up

ot-ctl thread start

sleep 2

ot-ctl netdata register

ot-ctl state leader

I am using the otbr docker container with a custom docker-compose script and entrypoint if that is helpful.

[Jonathan Hui]

OpenThread stores non-volatile state in a file specified by the build-time config OPENTHREAD_CONFIG_POSIX_SETTINGS_PATH - see ot-br-posix/third_party/openthread/CMakeLists.txt#L62.

If you are starting a new container each time, you should make sure that the settings file persists across container instances.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/158b9472-aa0a-48b8-8f5b-d52ec18e9c98n%40googlegroups.com.

[nealsj...@gmail.com]

Great, thanks for the pointer.

I was able to resolve this by defining another volume in my docker-compose script:

    volumes:

        - /dev/ttyACM0:/dev/ttyACM0

        - ./docker_entrypoint.sh:/app/docker_entrypoint.sh

        - /var/lib/thread:/var/lib/thread

[Jonathan Hui]

Great to hear, glad you were able to resolve the issue. Thanks.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/39b58082-b2e1-455c-856b-628c5a479776n%40googlegroups.com.