Channel manager does not change channels if node is down?

[Peugot206]

Hi friends,

Since the channel quality depends on which channel you are in (11-26) it's nice to have features as Channel Monitor and Channel Manager. The Channel Manager is able to Monitor the channels and auto switch to the best one.

As a test I have the following scenario:

• 3x OpenThread devices in the same Thread network (leader, router and router), with current channel being 23.
• I kill 1x router node.
• I manually issue the command: channel manager change 20 to the remaining router node.
• After the default ~2 mins both the leader and router have switched their channels to 20.
• I power the killed router node again, it stays on its last channel 23, becomes leader and creates its own partition in the network. It does not change to 20 like the others. It is no longer able to communicate with the other nodes in the network.

Why doesn't the network heal itself, and also make the node that was down while switching channels, also switch to 20? If this is not actually the case, and a node is down, while the network decides to change channels, there can still be a single point of failure in the network, right? Or am I misundersting things?

Thanks for any help!

[jwhui]

Changing the channel should result in updating the Active Operational Dataset with a later timestamp. You can validate this using the dataset active CLI command.

A node that misses the Operational Dataset update needs to periodically search on other channels. The Announce Sender feature implements this functionality. Verify that this is enabled in your build.

[Peugot206]

Thanks a lot for your reply! So OpenThread has (obviously) thought about this. Nice feature that seems to be enabled by default, also in my case. I ran the test again, waited for more than an hour, and the killed node did not update it's channel (operational dataset) as I've noticed previously too.

I tested again as following:
Thread topology: 1x leader, 3x routers. Current channel 23.

• Router 1: gets killed (powered down).
• Router 2: run channel manager change 20.
• All active nodes: dataset pending, I can see the new pending dataset. I wait until it becomes active.
• All active nodes: channel, I observe all active nodes have changed to channel 20.
• Router 1: gets powered back up.
• Router 1: channel remains 23, device becomes leader, no pending dataset.
• Wait 1 hour (even though 11m and 28s should be sufficient according to the config file).
• Router 1: channel still remains 23, no pending dataset, device is still leader in a partitioned Thread network.

What could be causing this? As extra information I run the Silicon Labs OT-CLI FTD example on Router 1. The other 2x routers also run the OT-CLI FTD example from Silabs, but have a different processor and I've added some code and extra prints to it (functionally it's the same). The leader in my setup is a Raspberry Pi 4 with a nRF52840 dongle. Running versions:

• SL-OPENTHREAD/2.3.2.0_GitHub-e6df00dd6; EFR32; Nov 24 2023 13:39:41 (router 1)
• SL-OPENTHREAD/2.3.2.0_GitHub-e6df00dd6; EFR32; Nov 27 2023 16:11:48 (other routers)
• OPENTHREAD/thread-reference-20230119-506-ge6df00dd6; POSIX; Jul 24 2023 18:45:18 (Raspberry Pi 4)

[abtink]

@Peugot206, I expect that the AnnounceSender mechanism to trigger channel recovery. We have a test case, test-603-channel-announce-recovery.py, that covers a similar scenario involving an orphaned MTD/child device.

I just submitted a PR that enhances this test case to validate the behavior when the "orphan" device is an FTD/router, similar to the situation you described:

• [test] update channel-announce-recovery test to check router recovery #9670

The test appears to pass successfully when executed on my local machine and on GitHub action CI.

[Peugot206]

@abtink thank you for this! The test seems to indeed describe my case, however with 'real world' Thread devices, it does not seem to work.

See video attached, which showcases what I described in my previous post (note that I only waited ~120s at the end of this video, but I waited for more than an hour after the recording and the node still did not change channels). Please watch the whole video to not miss any details, as I skipped waiting parts out of the video (as much as possible).

What could be causing this? What else should I look into?

OpenThread_Announce_Recovery.mp4

[jwhui]

It appears that your Operational Dataset is incomplete. For example, it is missing the Channel Mask configuration, among others.

Take a look at src/cli/README_DATASET.md to see how to properly configure the Operational Dataset when creating a new network.

[Peugot206]

Thanks, you are completely right! This resolved my problem. I made the assumption that non-given parameters would automatically be set to the default params, but that's not the case then.

I have now set the channel mask (11-26), security policy (672 onrc 0) and a PSKc for all the nodes. I generated a PSKc dataset pskc -p 123456. About the Mesh Local Prefix, I read that it is best to have this randomly generated (Google Groups), is there a way using the OT API to do this, because dataset meshlocalprefix returns nothing (most likely because I have not set it).

[jwhui]

As mentioned in the Quick Start section of src/cli/README_DATASET.md#quick-start, the preferred way is to use OpenThread's method for creating a new Operational Dataset, which will generate random values as necessary.

• When using the CLI, see dataset init new
• When using the API, see otDatasetCreateNewNetwork()