Openthread: 'Thread Start' Reverting to Persisted Settings

[nibanks]

I'm not sure if this is new behavior, or exactly how I got into this state, but whenever I use the CLI (on device, not Windows related), it seems to reset any settings back to the persisted state. For example:

> masterkey 00112233445566778899001122334455
Done
> masterkey
00112233445566778899001122334455
Done
> thread start
Done
> masterkey
00112233445566778899aabbccddeeff
Done

[librasungirl]

@nibanks , I guess the device had been in a network with masterkey 00112233445566778899aabbccddeeff. The old network information would be stored in flash and the device would try to reattach to previous network firstly when bring up again.

To start a complete new attach process, please run cli 'factoryreset' which would help to clear the stored network information.

[nibanks]

@librasungirl , That can't be an acceptable design. If an application tries to change a particular setting and recreate the network, it shouldn't be required to reset everything.

[jwhui]

I've been thinking about this problem myself lately. Thread specifies a way to manage the network configurations over the air through Active and Pending Operational Datasets. The Active and Pending Operational Datasets are provided to the Leader and disseminated throughout the network. Thread also specifies rules for switching between the Active and Pending Operational Datasets when a device becomes orphaned in an attempt to regain connectivity.

OpenThread currently provides APIs to allow "out-of-band" configuration (e.g. setting the channel, PAN ID, master key, etc.).

The high-level question for me is whether the "out-of-band" configuration is:

1. To get the device on the network for the first time (i.e. to avoid Thread Commissioning) or,
2. To allow out-of-band changes to network configuration during operation.

I'm not quite sure how to support 2 properly. In particular, if a device can locally change its network parameters, how does it participate in the communication of Active and Pending Operational Datasets to neighboring devices? Does it accept and use new Operational Datasets received from neighboring devices?

[nibanks]

I'm not exactly sure how it should affect the datasets, but from an API stand point, we should support an application that allows for a user to 'play around with' the settings; creating and stopping the network multiple times, until they finalize on something. This shouldn't require the application to completely reset everything just to change one setting.

[jwhui]

One workable solution may be to prevent changes to network configuration parameters (e.g. PAN ID, channel, master key, etc.) via the API while Thread is enabled. When Thread is disabled, the client may change/update these values. However, if the client does update the values, then the existing Active and Pending Operational Datasets stored on the device are invalidated.

As I mentioned above, the challenge is Thread has its own mechanisms to manage and distribute network parameter configurations. Having the client change those value at runtime can cause conflicts with mechanisms. Of course, this also means that after Thread is enabled and the device has successfully joined a network, the device will adopt any Active and Pending Operational Datasets and potentially overwrite any changes that the client made prior to enabling Thread.

Thoughts?

[nibanks]

I'm perfectly fine with only allowing changes while Thread is disabled.