Cannot commission multiple Matter instances in a single Linux node

[selissia]

Problem

Cannot commission multiple Matter instances in a single Linux node. Once the first node (a Linux process) is commissioned the subsequent chip-tool pairing command does not attempt to communicate with the second node (another Linux process in the same node). If one issues rm -r /tmp/chip_* before starting the second node then the second commissioning works -- but this results in two nodes being commissioned to different fabrics.

This scenario used to work on Linux in December 2021. This scenario seems to still be working correctly on Darwin.

Steps to reproduce:

scripts/examples/gn_build_example.sh examples/chip-tool out/ && scripts/examples/gn_build_example.sh examples/ota-provider-app/linux out/debug chip_config_network_layer_ble=false  && scripts/examples/gn_build_example.sh examples/ota-requestor-app/linux out/debug

./out/debug/chip-ota-provider-app -f /tmp/ota.txt
./out/chip-tool pairing onnetwork 1 20202021
./out/debug/chip-ota-requestor-app -u 5560 -d 42 
./out/chip-tool pairing onnetwork-long 2 20202021 42

Proposed Solution

[selissia]

Functionality broken by this commit: 360252c

Reverting the change in src/app/server/Server.cpp makes the issue go away.

[selissia]

The logic introduced in the above commit is not correct: It assumes that from GetFabricTable().FabricCount() != 0 it follows that the device is commissioned. This isn't the case: fabric count would be non-zero if the device simply loads the fabric table from storage upon init -- this does not guarantee that the device is commissioned.

The reason that the Darwin platform is working is most likely that it does not implement storage and FabricCount() is always zero upon init; Linux does implement storage.

[selissia]

The statement in above comment is false, FabricCount() != 0 should indeed imply that that the device is commissioned. See this discussion: https://csamembers.slack.com/archives/G014G30SVV0/p1641823048057800

[selissia]

The underlying issue is that multiple Matter devices running within a single Linux instance share the same Key Value Store ( the /tmp/chip_kvs file) . There doesn't seem to be a straightforward way of addressing this without modifying the platform layer for Linux which isn't an option this late in the release.

The workaround is to issue the following command before starting the second Matter node (chip-ota-requestor-app in this scenario):

rm /tmp/chip_kvs

[selissia]

This change might allow the OTA apps to be built on Linux with separate KVS files: #14832