Announce messages can cause instability in neighbouring but distinct networks #12908
Replies: 1 comment 4 replies
-
|
Reviewing the behavior described, it appears the instability is a result of the two overlapping Thread networks sharing the same Thread Network Key. In OpenThread (and per the Thread specification), MLE Announce messages are secured using the MLE encryption key, which is derived from the Thread Network Key. When a node receives an Announce message:
To ensure that two overlapping Thread networks remain completely separate and do not process each other's Announce messages, they must be configured with different Thread Network Keys. This ensures that cross-network MLE traffic is filtered at the security layer, preventing the instability you've observed. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Bug description
This might be not an OpenThread bug, but more a limitation in the Thread specs.
When an Announce message is received, in case:
the device receiving the Announce message will attempt to attach to the announced partition by using the new channel and PAN-ID (
kAnnounceAttachAfterDelay). This is correct when the device was previously part of the same partition and shares the same network-key as the one used by the announcing device.However, in case the receiving device was part of a Thread network that was intended to remain separated from the other, this causes the device to continuously disconnect from its original partition, and attempt to join the announced one, and most likely this procedure will fail and the device will join back the previous partition. This introduces instability on a mesh network, especially if the affected device is a Router.
How to reproduce
Expected behavior
A device actively part of a mesh network shall not attempt to connect to a different partition whenever an announce message is received just because it's got a bigger Active TimeStamp.
I am not sure how to prevent this from affecting devices part of distinct but overlapping mesh networks. I can only think of:
timestampCompare < 0)Beta Was this translation helpful? Give feedback.
All reactions