Michał Szablowski

I can look at that also but, I can see that extended and doesn't match ./chip-tool networkcommissioning connect-network hex:**1161111128222222** 1 0 --Breadcrumb 2 - extended panid 1161111128222222 ./chip-tool networkcommissioning add-or-update-thread-network...

Hi, I was able to reproduce it. The Border Router 1 and Border Router 2 are within the same network (not Thread Network) and may discover its services by DNS....

Currently, the SRP Replication feature is not supported on the current Thread 1.3, hence the border routers from two separate Thread Networks can discover its services within a local network...

What is the issue? Please provide logs and steps how to reproduce

@bzbarsky-apple, currently (at least nrfconnect platform) transmits a response to the old network, and right after sending the response DUT, switches to the new network.

I test it right now, and the device without any issue connects to the second Thread Network and after the arm-fail-safe timeout, the device goes back to the first Thread...

If the device does not support CALFMT, the attributes should be removed from DUT.

I think that currently with the ICD using non-interactive chip-tool is no-go for LIT. if it is expected then implementation of chip-tool need to be updated to store in controller...

Can you share also the PR to the specification to familiarize with new Commissioning procedure

> > currently with the ICD using non-interactive chip-tool is no-go for LIT. > > You mean without passing `--skip-icd-registration` (because there's no queuing of interactions implemented)? Or in general?...