chip-tool --storage-directory issue??

[bkoblenz]

Honestly, I suspect this is user error, but I am a bit confused. I want my commissioned matter fabric network to be persistent across reboots of my hub. I downloaded the snap chip-tool and tried to use the --storage-directory parameter to save the matter configuration in a place not rooted at /tmp. I get an error even though the directory specified does exist.

Am I correct in assuming that chip-tool keeps the network as it commissions devices? If not, should I be looking elsewhere.

Am I using (and thinking about) the --storage-directory parameter correctly? Here is my output:

pi@noble:/var/snap/chip-tool$ sudo chip-tool interactive start --storage-directory /home/pi/Irricloud/data/chip
[1734121002.203] [13662:13662] [CTL] Init Storage failure: src/controller/ExamplePersistentStorage.cpp:84: Error 0x000000AD
[1734121002.203] [13662:13662] [TOO] Run command failure: src/controller/ExamplePersistentStorage.cpp:84: Error 0x000000AD
pi@noble:/var/snap/chip-tool$ ls -l /home/pi/Irricloud/data/chip
total 0

[bkoblenz]

fwiw, here is the snap info chip-tool tail output

commands:

• chip-tool
  snap-id: 1BvbqgXx6wlTOGBaMogQxoKYhFBfHhrj
  tracking: latest/stable
  refresh-date: today at 10:07 PST
  channels:
  latest/stable: v1.4.0.0+snap 2024-12-13 (200) 34MB -
  latest/candidate: v1.4.0.0+snap 2024-12-12 (200) 34MB -
  latest/beta: 84fb78f8+snap 2024-12-09 (198) 35MB -
  latest/edge: 84fb78f8+snap 2024-12-09 (198) 35MB -
  installed: v1.4.0.0+snap (200) 34MB -

[farshidtz]

It shouldn't be writing the files to /tmp (which is a temp directory inside the snap, different from the same path on the host). Chip Tool is supposedly configured to use /var/snap/chip-tool/common for the storage. See

chip-tool-snap/snap/local/bin/set-tmp-dir.sh

Line 3 in 13d9331

export TMPDIR=$SNAP_USER_COMMON

Need to investigate further.

Regardless, what you are trying to do isn't working because Chip Tool doesn't have permission to access the home directory from the snap's confinement. This can of course be changed; please kindly make a feature request.

In the meantime, instead of /home/pi/Irricloud/data/chip, try setting the storage directory to a path under /var/snap/chip-tool/common, which Chip Tool does have access to by default.

[bkoblenz]

Thanks so much for your response. I mistakenly got the /tmp reference from some chip documentation but I see how you use TMPDIR.

Unfortunately, I still think I have a problem. I currently have an interactive chip-tool running but there are no files in the /var/snap//chip-tool/common. Might the root ownership of that directory be a problem?

pi@noble:/var/snap/chip-tool$ ls -l common
total 0
pi@noble:/var/snap/chip-tool$ ls -ld common/
drwxr-xr-x 2 root root 4096 Nov 23 13:05 common/

I did, however, find some configuration files in:
pi@noble:~$ sudo ls -l /tmp/snap-private-tmp/snap.chip-tool/tmp
total 12
-rw------- 1 root root 55 Dec 13 12:19 chip_config.ini
-rw------- 1 root root 66 Dec 13 12:19 chip_counters.ini
-rw------- 1 root root 71 Dec 13 12:19 chip_factory.ini

Also, in my example where I tried to use --storage-directory, I was using sudo which I believe should have given chip-tool permission to write that directory. I am not too familiar with snap so maybe there are deeper constraints of which I am unaware.

fwiw, I did $ which chip-tool and got: /snap/bin/chip-tool which is a link to /usr/bin/snap and all of those files are owned by root.

I certainly can add a feature request, but I still suspect something is wrong on my end. I have not found any documentation that describes how the fabric's commissioned devices are stored. Might you know? Where are all of the node-ids captured so they persist and any failures/reboots result in still being able to talk to the matter device without re-commissioning, right?

I still dont really see any fabric configuration in the 3 chip_*.ini files found above. I do have one device commissioned, but it has a different vendor-id and product-id than what is in the .ini file.

[DEFAULT]
location-capability=2
regulatory-location=0

[DEFAULT]
boot-reason=0
reboot-count=1
total-operational-hours=0

[DEFAULT]
product-id=32769
unique-id=4B2253B94C6FF306
vendor-id=65521

thanks,
-brian

[bkoblenz]

Maybe I have a little more insight.

First, I found configuration files at /root/snap/chip-tool/common/
I assume the /root is based on using sudo and these files change with time.

I also had an interactive session going with a device commissioned (nodeid==0x11) and I found the following line in the chip_config.ini file:
f/1/s/0000000000000011=FTADEOJc0D5d9gByYTCDagsqkEYwBCCPTQCSzXRypo1D0SFo3RAvivAl7rHI/iISdQ5JgoGILTAFDAAAAAAAAAAAAAAAABg=

When I stopped the interactive session and ran chip-tool again trying to access that device's basicinformation it failed and the chip_config.ini was smaller and the main thing missing was the above line. (A few later lines were different too but....) So, I think I have found the files, not where I expected them, and they do not seem to hold commissioned devices across invocations of chip-tool.

So, are these really bugs (hard to believe others would not have encountered them), or am I using/configuring the usage incorrectly.

thanks
-brian

[jpm-canonical]

Hi Brain. I'm trying to follow your steps to see if we are hitting a bug, or if this is intended behavior.

Some notes:

• The snap can not access any files outside of its sandbox, so using --storage-directory to point it outside won't work. This is perhaps something we need to document.
• By default the snap stores its database files in $SNAP_USER_COMMON which translates to /home/$USER/snap/chip-tool/common/ or /root/snap/chip-tool/common/ if it is run with sudo. It also stores some files, which do not need to be persisted, under the internal /tmp directory.
• The files under /tmp get the ownership of the user the snap is executed by. This means if you run the snap with sudo, these files will be owned by root. If you run the snap again without sudo, these files can't be accessed. This is documented here, and a workaround is provided.

In your case I would recommend that your start from scratch and run chip-tool without using sudo. To completely remove chip-tool and its data, run:

# Open a shell inside the chip-tool snap sandbox
sudo snap run --shell chip-tool.chip-tool
# Inside this shell, delete the temporary files
rm /tmp/chip_*
# Remove and purge chip-tool
sudo snap remove --purge chip-tool

Then reinstall chip-tool and see if it works. The devices should be persisted through reboots.

[jpm-canonical]

On my side, following the standard usage pattern, paired devices are persisted and I can still control the device after a system reboot.

Steps I followed:

• Use matter-all-clusters-app-snap as a device according to these steps.
• Pair and control device before and after a restart using chip-tool:

$ sudo snap remove --purge chip-tool
[sudo] password for jpm: 
snap "chip-tool" is not installed

$ sudo snap install chip-tool 
chip-tool v1.4.0.0+snap from Canonical IoT Labs installed

$ sudo snap remove --purge chip-tool
chip-tool removed

$ sudo snap install chip-tool 
chip-tool v1.4.0.0+snap from Canonical IoT Labs installed

$ sudo snap connections chip-tool 
Interface        Plug                       Slot            Notes
avahi-observe    chip-tool:avahi-observe    :avahi-observe  -
bluez            chip-tool:bluez            :bluez          -
network          chip-tool:network          :network        -
network-bind     chip-tool:network-bind     :network-bind   -
process-control  chip-tool:process-control  -               -

$ chip-tool pairing onnetwork 110 20202021

$ chip-tool onoff toggle 110 1

$ chip-tool onoff toggle 110 1

$ sudo reboot

$ chip-tool onoff toggle 110 1

$ chip-tool interactive start
...
>>
ctrl+c

$ chip-tool onoff toggle 110 1
...
# This still controlled matter-all-clusters-app