When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

RE: When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

Jørgen Holmefjord — Thu, 01 Sep 2022 12:15:21 GMT

Did you try the instructions in the documentation? It mentions aarch64, so I would assume it would build for this architecture if you build it on the Raspberry Pi.

RE: When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

classic037 — Thu, 01 Sep 2022 03:50:51 GMT

hi Jørgen Holmefjord

Do you know how to build in aarch64 format when building CHIP TOOL?

RE: When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

classic037 — Wed, 31 Aug 2022 23:59:16 GMT

hi Jørgen Holmefjord

I try edit the chip tool source and test it. I will share the results soon

RE: When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

Jørgen Holmefjord — Wed, 31 Aug 2022 15:18:21 GMT

As far as I can see, the lines linked in my previous reply is the only place where the configs are stored in /tmp. Did you try to change these lines and rebuild chip-tool from the modified sources?

RE: When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

classic037 — Tue, 30 Aug 2022 00:20:26 GMT

Thank you very much!

Changing the tmp settings according to your guide solved the problem.

I agree with you. I think it's right to modify the chip-tool not to save the settings to tmp.

Can you guide me to save to a different path in chip-tool?

Thank you!

RE: When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

Jørgen Holmefjord — Fri, 26 Aug 2022 16:06:39 GMT

Hi,

This might be caused by the CHIP-tool config files being stored in /tmp. Some platform like Ubuntu 20.04 on Raspberry Pi removes content in /tmp on reboot.

A quick solution could to modify the setting of /tmp:

sudo vim /usr/lib/tmpfiles.d/tmp.conf
Change the line "D /tmp 1777 root root -" to "d /tmp 1777 root root -"
Then the content of /tmp will not be removed on every reboot.

A better solution is making chip-tool not store information in /tmp, but that will require a re-compilation.

Can you check if this resolves your issue?

Best regards,
Jørgen

RE: When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

classic037 — Fri, 26 Aug 2022 05:37:02 GMT

1. Successful commissioning of endevice and otbr for the first time (node id is 300)
./chip-tool-release onoff on 300 1 When sending command, node id 300 Fabric id 0x1A1EF49FC643541D

[1661490979.941199][1352:1352] CHIP:DIS: Verifying the received credentials
[1661490979.948676][1352:1352] CHIP:DIS: Added new fabric at index: 0x3, Initialized: 1
[1661490979.948805][1352:1352] CHIP:DIS: Assigned compressed fabric ID: 0x783E482064712CE1, node ID: 0x000000000001B669
[1661490979.972146][1352:1352] CHIP:DIS: Fabric (3) persisted to storage. Calling OnFabricPersistedToStorage
[1661490979.972271][1352:1352] CHIP:CTL: Joined the fabric at index 3. Compressed fabric ID is: 0x783E482064712CE1
[1661490980.130537][1352:1357] CHIP:TOO: Sending command to node 0x12c
[1661490980.131397][1352:1357] CHIP:DIS: Resolving 1A1EF49FC643541D:000000000000012C ...
[1661490980.137856][1352:1357] CHIP:DL: Avahi resolve found
[1661490980.138696][1352:1357] CHIP:DIS: Node ID resolved for 1A1EF49FC643541D:000000000000012C
[1661490980.140833][1352:1357] CHIP:DIS: UDP:[fd99:bf05:bbe9:1:1ed7:af3:6efd:a15c%wlan0]:5540: new best score: 6
[1661490980.140986][1352:1357] CHIP:DIS: Checking node lookup status after 10 ms
[1661490980.141612][1352:1357] CHIP:DIS: Keeping DNSSD lookup active
[1661490980.331406][1352:1357] CHIP:DIS: Checking node lookup status after 200 ms
[1661490980.332571][1352:1357] CHIP:SC: Initiating session on local FabricIndex 1 from 0x000000000001B669 -> 0x000000000000012C
[1661490980.335867][1352:1357] CHIP:IN: Prepared unauthenticated message 0x5585e74768 to 0x0000000000000000 (0) of type 0x30 and protocolId (0, 0) on exchange 4525i with MessageCounter:2314344470.
[1661490980.336651][1352:1357] CHIP:IN: Sending unauthenticated msg 0x5585e74768 with MessageCounter:2314344470 to 0x0000000000000000 at monotonic time: 00000000003D4264 msec
[1661490980.337620][1352:1357] CHIP:SC: Sent Sigma1 msg

2. Retransmit the following command after OTBT reboot
./chip-tool-release onoff on 300 1

Fabric id is different from fabric id before otbr reboot.

[1661491207.821921][789:789] CHIP:DIS: Added new fabric at index: 0x2, Initialized: 1
[1661491207.822056][789:789] CHIP:DIS: Assigned compressed fabric ID: 0x46C385D8286F4C18, node ID: 0x000000000001B669
[1661491207.845347][789:789] CHIP:DIS: Fabric (2) persisted to storage. Calling OnFabricPersistedToStorage
[1661491207.847646][789:789] CHIP:CTL: Joined the fabric at index 2. Compressed fabric ID is: 0x46C385D8286F4C18
[1661491207.848014][789:789] CHIP:CTL: Setting attestation nonce to random value
[1661491207.848207][789:789] CHIP:CTL: Setting CSR nonce to random value
[1661491207.852583][789:789] CHIP:CTL: Generating NOC
[1661491207.855649][789:789] CHIP:DIS: Verifying the received credentials
[1661491207.863075][789:789] CHIP:DIS: Added new fabric at index: 0x3, Initialized: 1
[1661491207.863209][789:789] CHIP:DIS: Assigned compressed fabric ID: 0x55F242389EDE75B3, node ID: 0x000000000001B669
[1661491207.874940][789:789] CHIP:DIS: Fabric (3) persisted to storage. Calling OnFabricPersistedToStorage
[1661491207.877534][789:789] CHIP:CTL: Joined the fabric at index 3. Compressed fabric ID is: 0x55F242389EDE75B3
[1661491208.155696][789:794] CHIP:TOO: Sending command to node 0x12c
[1661491208.155948][789:794] CHIP:DIS: Resolving D6D4D6EF92695544:000000000000012C ...
[1661491208.356344][789:794] CHIP:DIS: Checking node lookup status after 200 ms
[1661491213.160018][789:794] CHIP:DL: Re-trying resolve
[1661491218.156018][789:789] CHIP:DIS: Cancelling incomplete address resolution as device is being deleted.
[1661491218.156171][789:789] CHIP:DIS: Discovery does not require any more timeouts
[1661491218.158868][789:789] CHIP:BLE: BleConnectionDelegate::CancelConnection is not implemented.

However, as a result of checking whether the Fabric ID exists before otbr boot, it exists.
./chip-tool-release discover resolve 300 0x1A1EF49FC643541D

coway@raspberrypi:~/Matter-aws-iot-device-sdk-python-v2/samples $ ./chip-tool-release discover resolve 300 0x1A1EF49FC643541D
[1661491291.639196][800:800] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-tTJHpF)
[1661491291.641279][800:800] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1661491291.641601][800:800] CHIP:DL: NVS set: chip-counters/reboot-count = 2 (0x2)
[1661491295.155690][800:800] CHIP:DL: Got Ethernet interface: eth0
[1661491295.156464][800:800] CHIP:DL: Found the primary Ethernet interface:eth0
[1661491295.157121][800:800] CHIP:DL: Got WiFi interface: wlan0
[1661491295.162824][800:800] CHIP:DL: Found the primary WiFi interface:wlan0
[1661491295.163624][800:800] CHIP:IN: Loading from storage for fabric index 0x1
[1661491295.168682][800:800] CHIP:IN: Loading from storage for fabric index 0x2
[1661491295.170002][800:800] CHIP:IN: Loading from storage for fabric index 0x3
[1661491295.176423][800:800] CHIP:ZCL: Using ZAP configuration...
[1661491295.182938][800:800] CHIP:DL: Avahi client registered
[1661491295.184990][800:800] CHIP:CTL: Setting attestation nonce to random value
[1661491295.185101][800:800] CHIP:CTL: Setting CSR nonce to random value
[1661491295.185264][800:800] CHIP:CTL: Setting attestation nonce to random value
[1661491295.185368][800:800] CHIP:CTL: Setting CSR nonce to random value
[1661491295.187229][800:800] CHIP:CTL: Generating NOC
[1661491295.188771][800:800] CHIP:DIS: Verifying the received credentials
[1661491295.192756][800:800] CHIP:DIS: Added new fabric at index: 0x1, Initialized: 1
[1661491295.192863][800:800] CHIP:DIS: Assigned compressed fabric ID: 0xD6D4D6EF92695544, node ID: 0x000000000001B669
[1661491295.203104][800:800] CHIP:DIS: Fabric (1) persisted to storage. Calling OnFabricPersistedToStorage
[1661491295.203187][800:800] CHIP:CTL: Joined the fabric at index 1. Compressed fabric ID is: 0xD6D4D6EF92695544
[1661491295.203372][800:800] CHIP:CTL: Setting attestation nonce to random value
[1661491295.203527][800:800] CHIP:CTL: Setting CSR nonce to random value
[1661491295.205319][800:800] CHIP:CTL: Generating NOC
[1661491295.206827][800:800] CHIP:DIS: Verifying the received credentials
[1661491295.210647][800:800] CHIP:DIS: Added new fabric at index: 0x2, Initialized: 1
[1661491295.210730][800:800] CHIP:DIS: Assigned compressed fabric ID: 0x46C385D8286F4C18, node ID: 0x000000000001B669
[1661491295.228607][800:800] CHIP:DIS: Fabric (2) persisted to storage. Calling OnFabricPersistedToStorage
[1661491295.228688][800:800] CHIP:CTL: Joined the fabric at index 2. Compressed fabric ID is: 0x46C385D8286F4C18
[1661491295.228877][800:800] CHIP:CTL: Setting attestation nonce to random value
[1661491295.228986][800:800] CHIP:CTL: Setting CSR nonce to random value
[1661491295.230832][800:800] CHIP:CTL: Generating NOC
[1661491295.232539][800:800] CHIP:DIS: Verifying the received credentials
[1661491295.237266][800:800] CHIP:DIS: Added new fabric at index: 0x3, Initialized: 1
[1661491295.237401][800:800] CHIP:DIS: Assigned compressed fabric ID: 0x55F242389EDE75B3, node ID: 0x000000000001B669
[1661491295.259592][800:800] CHIP:DIS: Fabric (3) persisted to storage. Calling OnFabricPersistedToStorage
[1661491295.259727][800:800] CHIP:CTL: Joined the fabric at index 3. Compressed fabric ID is: 0x55F242389EDE75B3
[1661491295.447558][800:805] CHIP:DIS: Resolving 1A1EF49FC643541D:000000000000012C ...
[1661491295.556267][800:805] CHIP:DL: Avahi resolve found
[1661491295.556467][800:805] CHIP:DIS: Node ID resolved for 1A1EF49FC643541D:000000000000012C
[1661491295.558047][800:805] CHIP:DIS: UDP:[fd99:bf05:bbe9:1:1ed7:af3:6efd:a15c%wlan0]:5540: new best score: 6
[1661491295.558151][800:805] CHIP:DIS: Checking node lookup status after 110 ms
[1661491295.558220][800:805] CHIP:DIS: Keeping DNSSD lookup active
[1661491295.648033][800:805] CHIP:DIS: Checking node lookup status after 200 ms
[1661491295.648186][800:805] CHIP:TOO: NodeId Resolution: 300 at UDP:[fd99:bf05:bbe9:1:1ed7:af3:6efd:a15c]:5540
[1661491295.648255][800:805] CHIP:TOO: MRP retry interval (idle): 5000ms
[1661491295.648320][800:805] CHIP:TOO: MRP retry interval (active): 300ms
[1661491295.648382][800:805] CHIP:TOO: Supports TCP: no
[1661491295.648600][800:805] CHIP:DIS: Discovery does not require any more timeouts
[1661491295.653085][800:800] CHIP:BLE: BleConnectionDelegate::CancelConnection is not implemented.
[1661491295.653735][800:800] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-suUJsH)
[1661491295.656470][800:800] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1661491295.656650][800:800] CHIP:DL: NVS set: chip-counters/total-operational-hours = 0 (0x0)
[1661491295.656772][800:800] CHIP:DL: Inet Layer shutdown
[1661491295.656840][800:800] CHIP:DL: BLE shutdown
[1661491295.656920][800:800] CHIP:DL: System Layer shutdown

I think Enddevice and otbr can send and receive cluster commands successfully even if Otbr is rebooted if Fabric ID does not change after Otbr reboots

Please guide.

Thank you

RE: When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

classic037 — Fri, 26 Aug 2022 00:00:40 GMT

Hi Jørgen Holmefjord

Looking at the Enddevcie log when the OTBR is rebooted, it doesn't seem to be newly commissioned.

I think enddevice is still commissioned in the network and join successfully

D: 4171091 [DL]OpenThread State Changed (Flags: 0x00000200)

I: 4171101 [DL]SRP Client was stopped, because current server is no longer detected.

D: 4171109 [DL]OpenThread State Changed (Flags: 0x00000200)

D: 4171116 [DL]OpenThread State Changed (Flags: 0x00000002)

D: 4171121 [DL] Thread Unicast Addresses:

D: 4171125 [DL] fd15:f73b:9669:466a:0:ff:fe00:0/64 valid rloc

D: 4171131 [DL] fd15:f73b:9669:466a:5d79:1733:146f:bf/64 valid

D: 4171138 [DL] fe80::90b7:f629:a2c8:a8a9/64 valid preferred

D: 4171733 [DL]OpenThread State Changed (Flags: 0x00000200)

D: 4171740 [DL]OpenThread State Changed (Flags: 0x00000001)

D: 4171745 [DL] Thread Unicast Addresses:

D: 4171749 [DL] fdfa:abe6:eb46:1:bbd8:7c9:d4cd:5521/64 valid preferred

D: 4171756 [DL] fd15:f73b:9669:466a:0:ff:fe00:0/64 valid rloc

D: 4171763 [DL] fd15:f73b:9669:466a:5d79:1733:146f:bf/64 valid

D: 4171769 [DL] fe80::90b7:f629:a2c8:a8a9/64 valid preferred

D: 4172039 [DL]OpenThread State Changed (Flags: 0x00000200)

I: 4172062 [DL]SRP Client was started, detected server: fd15:f73b:9669:466a:34a3:c700:bb6a:851f

D: 4172071 [DL]OpenThread State Changed (Flags: 0x00000200)

D: 4172383 [DL]OpenThread State Changed (Flags: 0x00000200)

D: 4173224 [DL]OnSrpClientNotification: Last requested operation completed successfully

D: 4174363 [DL]OpenThread State Changed (Flags: 0x00000200)

RE: When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

Jørgen Holmefjord — Thu, 25 Aug 2022 12:36:57 GMT

Hi,

I checked with out Matter developers. They responded that "If the OTBR reboot means some power cycling without changing datasets across reboots (so without starting new network) it should be working fine." You write "if I check the enddevice side log, it is normally commissioned to Otbr again.", does this mean you are performing a new commissioning operation after the reboot, or do you mean that the device is still commissioned in the network and joined successfully?

RE: When the OTBR is rebooted after the Matter enddevice is paired with the OTBR, the chip tool command is not transmitted.

classic037 — Thu, 25 Aug 2022 07:29:50 GMT

After rebooting Otbr and restarting the otbr-agent

After pairing with Enddevice for the first time, "chip-tool onoff on 321 1" command transmission success log

[1661392926.978297][1166:1171] CHIP:TOO: Sending command to node 0x141

[1661392926.979154][1166:1171] CHIP:DIS: Resolving FB57F08594165D02:0000000000000141 ...

[1661392927.087708][1166:1171] CHIP:DL: Avahi resolve found

[1661392927.087923][1166:1171] CHIP:DIS: Node ID resolved for FB57F08594165D02:0000000000000141

[1661392927.089379][1166:1171] CHIP:DIS: UDP:[fdfa:abe6:eb46:1:e149:81d0:46ed:fdbb%wlan0]:5540: new best score: 6

[1661392927.089481][1166:1171] CHIP:DIS: Checking node lookup status after 110 ms

[1661392927.089550][1166:1171] CHIP:DIS: Keeping DNSSD lookup active

[1661392927.179326][1166:1171] CHIP:DIS: Checking node lookup status after 200 ms

[1661392927.179871][1166:1171] CHIP:SC: Initiating session on local FabricIndex 1 from 0x000000000001B669 -> 0x0000000000000141

[1661392927.182944][1166:1171] CHIP:IN: Prepared unauthenticated message 0x5585783bc8 to 0x0000000000000000 (0) of type 0x30 and protocolId (0, 0) on exchange 54176i with MessageCounter:2986941992.

[1661392927.183108][1166:1171] CHIP:IN: Sending unauthenticated msg 0x5585783bc8 with MessageCounter:2986941992 to 0x0000000000000000 at monotonic time: 0000000000160A55 msec

[1661392927.184576][1166:1171] CHIP:SC: Sent Sigma1 msg

[1661392927.184719][1166:1171] CHIP:DIS: Discovery does not require any more timeouts

[1661392927.675619][1166:1171] CHIP:EM: Received message of type 0x31 with protocolId (0, 0) and MessageCounter:2007637130 on exchange 54176i

[1661392927.675879][1166:1171] CHIP:SC: Received Sigma2 msg

[1661392927.689246][1166:1171] CHIP:IN: Prepared unauthenticated message 0x5585783bc8 to 0x0000000000000000 (0) of type 0x32 and protocolId (0, 0) on exchange 54176i with MessageCounter:2986941993.

[1661392927.689442][1166:1171] CHIP:IN: Sending unauthenticated msg 0x5585783bc8 with MessageCounter:2986941993 to 0x0000000000000000 at monotonic time: 0000000000160C4F msec

[1661392927.691256][1166:1171] CHIP:SC: Sent Sigma3 msg

After successful pairing with enddevice, after rebooting otbr, fail log when sending "chip-tool onoff on 321 1" command

[1661393240.078732][820:820] CHIP:DIS: Assigned compressed fabric ID: 0x15CCF5A2D56D62BF, node ID: 0x000000000001B669

[1661393240.094654][820:820] CHIP:DIS: Fabric (3) persisted to storage. Calling OnFabricPersistedToStorage

[1661393240.097075][820:820] CHIP:CTL: Joined the fabric at index 3. Compressed fabric ID is: 0x15CCF5A2D56D62BF

[1661393240.356630][820:825] CHIP:TOO: Sending command to node 0x141

[1661393240.356861][820:825] CHIP:DIS: Resolving 670DA458A9B464EF:0000000000000141 ...

[1661393240.557607][820:825] CHIP:DIS: Checking node lookup status after 201 ms

[1661393245.362918][820:825] CHIP:DL: Re-trying resolve

[1661393250.356879][820:820] CHIP:DIS: Cancelling incomplete address resolution as device is being deleted.

[1661393250.357065][820:820] CHIP:DIS: Discovery does not require any more timeouts

[1661393250.360209][820:820] CHIP:BLE: BleConnectionDelegate::CancelConnection is not implemented.

[1661393250.361353][820:820] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-f3qcie)

[1661393250.363607][820:820] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)

[1661393250.363795][820:820] CHIP:DL: NVS set: chip-counters/total-operational-hours = 0 (0x0)

After rebooting the Raspberry Pi, the otbr-agent service runs again, and if I check the enddevice side log, it is normally commissioned to Otbr again. However, the Fabric id has changed.