[1.1] Error on commissioning step 'FindOperational', CHIP Error 0x000000C9: No shared trusted root

[gokul-2000]

Reproduction steps

Hi all,

I am trying to commission nxp's matter end-device(lighting-app) using chip-tool as matter controller.

I followed the steps in this link to make nxp's k32w dongle as end-device. And I took v1.0-branch, compiled chip-tool example, and used it to commission nxp's matter end-device.

I copied all the paa-root-certs and cd-certs from connectedhomeip GitHub repository and put them at my preferred path and passed the preferred path to chip-tool as an argument.

After that, I connected nxp's matter end-device(lighting-app) and matter controller in the same thread network using ot-ctl and then tried to commission nxp's matter end-device using chip-tool as matter controller using the below command:

./chip-tool pairing onnetwork-long 0x17 20202021 3840 --paa-trust-store-path /usr/local/etc/matter-certs/paa-root-certs --cd-trust-store-path /usr/local/etc/matter-certs/cd-certs

I got the below error in commissioning:

Error on commissioning step 'FindOperational', CHIP Error 0x000000C9: No shared trusted root

I have attached the full logs herewith. no_shared_trusted_root.txt

Let me know in case more information is required.

Thanks in advance for any help/support.

Bug prevalence

consistent

GitHub hash of the SDK that was being used

v1.0-branch

Platform

k32w

Platform Version(s)

No response

Type

Platform Issue

Anything else?

No response

[gokul-2000]

Thanks for the great support in the past @bzbarsky-apple

Please help/guide me on the above issue. It will be very helpful to me.

Thank you so much for your attention and participation.

[bzbarsky-apple]

No idea, sorry. Normally that sort of thing would mean mismatched root certs or IPK, but here chip-tool is doing the commissioning and the operational setup...

The only thing I can think of is that there is already another device on the operational network with the same node id for the same fabric, but using a different IPK.

But looking at the IPs, when commissioning the device we were sending packets to fd7f:a9ce:b5bf:1:325b:f31b:7c5f:a47e.

And the operational Sigma1 is being sent to fd7f:a9ce:b5bf:1:325b:f31b:7c5f:a47e

So that looks lke the same device...

[gokul-2000]

Thank you very much for the response @bzbarsky-apple

The only thing I can think of is that there is already another device on the operational network with the same node id for the same fabric, but using a different IPK.

I factory reset the device and then did commissioning with an unused node id, but the error persists.

I connected the matter controller and matter end-device over the same thread network and then I tried to commission the matter end-device using the onnetwork-long method.

---

This matter end-device has BLE and DNS-SD advertisement enabled [advertisementMode == chip::CommissioningWindowAdvertisement::kAllSupported] and I do commissioning using onnetwork-long method. Will this cause the above problem?

---

Normally that sort of thing would mean mismatched root certs or IPK

How can I validate this?

Any help/support is much appreciated!!

[bzbarsky-apple]

How can I validate this?

If you have access to the code of the device, step through or add logging to see exactly where the CASE bits fail.... The device is claiming there is no trusted root. The question is why.

[gokul-2000]

Thanks for the great support always @bzbarsky-apple

For Matter Controller: Now I am using v1.1-branch of the connectedhomeip GitHub repository.

For Matter End-Device: Now I am using v1.1.0.1.1 of the NXP matter GitHub repository.

I connected nxp's matter end-device(lighting-app) and matter controller in the same OpenThread network using OpenThread-CLI and then tried to commission nxp's matter end-device using chip-tool as matter controller with onnetwork commissioning method using the below command:

./chip-tool pairing onnetwork-long 0x17 20202021 3840 --paa-trust-store-path /usr/local/etc/matter-certs/paa-root-certs --cd-trust-store-path /usr/local/etc/matter-certs/cd-certs

I got the below error in commissioning:

Error on commissioning step 'FindOperational', CHIP Error 0x000000C9: No shared trusted root

I have attached the full logs herewith for matter controller and matter end-device. controller_no_shared_trusted_root.txt end_device_no_shared_trusted_root.txt

---

bzbarsky-apple commented Oct 19, 2023 How can I validate this? If you have access to the code of the device, step through or add logging to see exactly where the CASE bits fail.... The device is claiming there is no trusted root. The question is why.

I observed the end-device logs and came to know that "No shared trusted root" event has been generated from end-device. At Controller side: CASESession::SendSigma1() ----> GenerateCaseDestinationId() At End-device side: CASESession::HandleSigma1() ----> FindLocalNodeFromDestinationId() ----> GenerateCaseDestinationId() returned "No shared trusted root" error status and send this error status to the controller.

UPDATE: I observed the same error while doing commissioning of the default code of NXP K32W061 end-device lighting-app application using ble-thread commissioning method also.

Further help/support is much appreciated!!

[bzbarsky-apple]

GenerateCaseDestinationId does not return a "no shared trusted root" status.... Where did GenerateCaseDestinationId() actually fail, if it failed?

[gokul-bhalodiya]

Thanks for helping me debug the issue @bzbarsky-apple

Root Cause Analysis for the above error: I have flashed the lighting-app example to NXP K32W061 and commissioned it into the matter network using the matter controller.

After that, I erased and re-flashed the binary to NXP K32W061, but NXP 's programmer(DK6Programmer.exe) did not erase the persistent data stored previously in external flash. After this, I started to commission the same device into the matter network using the matter controller but it failed due to the previously stored persistent data in external flash.

Solution: "Doing the Factory Reset" NXP K32W061 resolves the "No shared trusted root" as it will erase the previously stored persistent data.

Is this the expected behavior when we didn't factory reset the device or it shouldn't happen?

@bzbarsky-apple you can close the ticket and mark it as resolved.

[bzbarsky-apple]

Is this the expected behavior when we didn't factory reset the device or it shouldn't happen?

@doru91 can you take a look at this part?