Error on commissioning step 'FindOperational' while pairing matter sample over ble-thread

[filipmrazek]

Hi,

I'm following this tutorial https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/nrf/ug_matter.html - I use the nrf52840 dongle as a co-processor connected to a raspberry pi running OTBR, nrf52840 DK flashed with matter door lock sample and I downloaded chip tool (release version 2.0.0) on my laptop with Linux. I want to connect the door lock sample to OTBR as described here. Unfortunately, step 6 causes the problem. When I execute this command:

./chip-tool-release pairing ble-thread 1000 hex:0e080000000000010000000300000f35060004001fffe0020811111111222222220708fd05128ef262a22b051000112233445566778899aabbccddeeff030e4f70656e54687265616444656d6f010212340410445f2b5ca6f2a93a55ce570a70efeecb0c0402a0f7f8 20202021 3840

I get the following error:

 

CHIP:DIS: Operational discovery failed for 0x00000000000003E8: ../../src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:174: CHIP Error 0x00000032: Timeout

and I have no idea what should be wrong. (Does it mean there is something wrong with OTBR? But if I execute `service otbr-agent status` on raspberry pi I get otbr-agent is running and for command  `ot-ctl state` the response is Leader.  

Can anybody help me figure it out? Thank you.

If you want to see full output from the command, you can find it here.

[Charlie]

Hi Filipmrazek,

I got some explanation from our development team about your observation:

If the customer does not recommission the device after rebooting the PC which runs the chip-tool, it will not work. The default chip-tool caches all network data in `/tmp`which works like volatile memory and is cleaned with each reboot. There is not an out-of-the-box solution which would allow changing the storage type in chip-tool, and it's not possible to change the storage or the system path without altering the chip-tool source code. But note that chip-tool is more like a testing tool. In a real scenario, the ecosystem controller will most likely still be able to talk to the Matter device after it is rebooted.

Best regards,

Charlie

[filipmrazek]

Hi Charlie,

thank you for your answer. If I understand your answer correctly, do I have to factory reset the nrf52840 dk and pair it again after reboot?
I understand that chip-tool is only a testing tool, but it would be nice if I could change the cache location. It's really annoying if developers want to test their network for a few days.

BTW: Is it possible to run chip-tool inside docker container with mounted volume (like -v /path/to/chache/:/tmp)? Then OS will not remove the cache. I can try it later and post the result if it's working. 

[Varun2103]

No

[Varun2103]

Hi charlie, any solution for my problem ?

[Charlie]

Hi Varun,

Are you able to test with any options mentioned here:

https://devzone.nordicsemi.com/support-private/support/294750#permalink=874313

Best regards,

Charlie

[Varun2103]

Means I didn't understood your uestion exactly

[Varun2103]

Also charlie, I want you to know that my OTBR interface is wpan0 and my laptop Wi-Fi interface is wlp3s0 but when I'm giving command ifconfig in my PC, I'm getting like the below mentioned log

ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:acff:fecc:a2f3  prefixlen 64  scopeid 0x20<link>
        ether 02:42:ac:cc:a2:f3  txqueuelen 0  (Ethernet)
        RX packets 1653  bytes 1938148 (1.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 931  bytes 72609 (72.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.72.208.176  netmask 255.255.254.0  broadcast 10.72.209.255
        inet6 fe80::6812:dc5e:679d:ced6  prefixlen 64  scopeid 0x20<link>
        ether c0:3e:ba:3a:00:5b  txqueuelen 1000  (Ethernet)
        RX packets 86153  bytes 76838415 (76.8 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 45548  bytes 7520260 (7.5 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 339719  bytes 37653563 (37.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 339719  bytes 37653563 (37.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

otbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.18.0.1  netmask 255.255.0.0  broadcast 172.18.255.255
        inet6 fd11:db8:1::1  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::42:53ff:fe16:e76b  prefixlen 64  scopeid 0x20<link>
        inet6 fe80::1  prefixlen 64  scopeid 0x20<link>
        ether 02:42:53:16:e7:6b  txqueuelen 0  (Ethernet)
        RX packets 13331  bytes 12291175 (12.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5645  bytes 432361 (432.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.219.214  netmask 255.255.255.0  broadcast 192.168.219.255
        inet6 fe80::8c72:bdf9:c67:5b53  prefixlen 64  scopeid 0x20<link>
        inet6 2409:40f2:101f:78e1:a1ca:b687:ed88:2b8b  prefixlen 64  scopeid 0x0<global>
        inet6 2409:40f2:101f:78e1:65fd:d681:2090:1810  prefixlen 64  scopeid 0x0<global>
        ether 28:cd:c4:c3:27:33  txqueuelen 1000  (Ethernet)
        RX packets 519676  bytes 545654304 (545.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 233204  bytes 61071612 (61.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I'm not understanding why there is no wpan0 interface in this and what is otbr0 exactly