openthread cli does not auto start and cannot use commissionner

[wass]

I'm trying to create an openthread network extension with nrf52840 dongle. For that, it needs to be Full Thtead Device so that it's capable of becoming a router and should be able to join automatically so auto start thread and joined config. I based it on the cli example

github.com/.../cli

witht the following west.yml

https://github.com/HomeSmartMesh/sdk-hsm-thingy53/blob/main/west.yml

which has nrfconnect v2.3.0 and sdk zephyr v3.2.99-ncs2

with the following additional overlay

github.com/.../overlay-joiner-rounter.conf

here the content for conevenience 

```

CONFIG_OPENTHREAD_NORDIC_LIBRARY_FTD=y
CONFIG_OPENTHREAD_FTD=y
CONFIG_OPENTHREAD_MTD=n
CONFIG_OPENTHREAD_MANUAL_START=n

# OpenThread joiner
CONFIG_OPENTHREAD_JOINER=y
CONFIG_OPENTHREAD_JOINER_AUTOSTART=y
CONFIG_OPENTHREAD_JOINER_PSKD="ABCDE2"
CONFIG_OPENTHREAD_SLAAC=y

CONFIG_OPENTHREAD_COMMISSIONER=y

```

Yet, by default the state is disabled and is not autostarting despite `CONFIG_OPENTHREAD_MANUAL_START=n`

plus the commissionner command does not exist, I get an error when I try to use it on the shell, despite `CONFIG_OPENTHREAD_COMMISSIONER=y` 

I built it as follows and checked in `build/zephyr/.conf` that the config flags are taken correctly. 

`west build -p always -b nrf52840dongle_nrf52840 -- "-DOVERLAY_CONFIG=overlay-usb.conf;overlay-joiner-rounter.conf" -DDTC_OVERLAY_FILE="usb.overlay"`

I also perform an `ot factoryreset` for every test and have a sniffer to check packets. Right after a factory rest, and after the dongle restarts and the serial attaches again, the `ot state` is disabled and not detached or other, so I have to manually run`ot thread start` which is a manual start and not automatic.

My end goal is to make MTD devices be able to join through a cli dongle as router, but for that I assumed the cli has to be capable of commissioning first, and failed in testing a simple cli leader that can commission from its shell.

[wass]

I answer part of my own issue, as I clarified the "commissioning" part. It was not clear to me when a dataset is needed and when not.
when testing a new fresh factoryreset cli and creating a dataset as described here, it works

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/thread/overview/commissioning.html#setting-up-the-commissioner

I'll still investigate why it does not autostart, and when it comes to other issues (joining from intermediate router, I'll test more and might open an issue in a different ticket).

[AHaug]

Hi,

Glad to hear that you've solved (atleast partially?) the issue you were observing. Could you verify if you've solved it or not?

If not, I'll continue supporting you with solving the case! 

Kind regards,
Andreas

[AHaug]

Hi,

From what I know it should autojoin. Could you have a look at this git issue from zephyr and check the logs to see if the issue is similar as the one reported in the issue and try the suggested fix: github.com/.../30433

It seems that you have not erased the OT settings area on flash (west flash --erase). Looking at the logs, your device already had a dataset stored and it simply formed a network. The startup code won't bother with the joining procedure if it has a valid dataset stored in flash.

If it does not solve the issue, could you check and see if it is reproducable in a somewhat minimal sample such as https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/openthread_samples/autojoin? 

Kind regards,
Andreas

[wass]

Hi,

thank you for the suggestions. I checked the github issue link, that is something I was aware of and is quite common for newly flashed devices in order to be in a factory reset state right after flashing. Flashing actually does not delete the openthread settings region, that's why, what actually deletes the openthread settings region is calling "ot factoryreset" which I included in my test as shown above.

I think the question could be answered by investigating the code or having a clear overview on what the cli does, which is a bit challenging to me. If the code proves that the behavior is expected then reproducing it will not justify if it is a bug or not, maybe the cli example was just not intended to be used like that.

In order to make reproduction easier, as requested here I put together in one directory all what is needed, the readme also includes the needed command which must include the test overlay

https://github.com/HomeSmartMesh/sdk-hsm-thingy53/tree/main/samples/30_usb_dongle_router

here the commands from the readme

```shell

west build -p always -b nrf52840dongle_nrf52840 -- "-DOVERLAY_CONFIG=overlay-usb.conf;overlay-joiner-rounter.conf" -DDTC_OVERLAY_FILE="usb.overlay"

nrfutil pkg generate --hw-version 52 --sd-req=0x00 --application build/zephyr/zephyr.hex --application-version 1 build/zephyr/zephyr.zip

nrfutil dfu usb-serial -pkg build/zephyr/zephyr.zip -p COM9

```

 

[AHaug]

Hi,

Thank you for providing me with a sample and steps to recreate the issue. This is just a heads up that it might take some time attempt to recreate the issue you're observing but I will try to prioritize it towards the end of the working week

Kind regards,
Andreas

[Sigurd Hellesvik]

Hi wass.

I will continue helping in this case.

wass said:

Flashing actually does not delete the openthread settings region

That is correct.

However, if you flash and erase, openthread settings will be erased.

wass said:

As you can see, the cli sample starts as disabled and does not attempt to join any network as per the expected `CONFIG_OPENTHREAD_JOINER_AUTOSTART=y`

From your description, your issue is that when you call "ot factoryreset", the device does not autojoin again, rigjt?

If I run my autojoin sample, the device automatically joins on "ot factoryreset".
See the video below for a sample

Regards,
Sigurd Hellesvik

[wass]

Thank you very much for your support, the "autojoin" sample is out of scope though, as the question was about the cli. I am capable of using join functions with a custom app. Therefore, I will not follow up this question we can close it as I will proceed by creating a different sample than the cli.
Thank you again for the help, I don't think it is worth it to follow up why exactly the cli sample did not work with a specific flag.