project-chip / connectedhomeip

Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.
https://buildwithmatter.com
Apache License 2.0
7.49k stars 2.01k forks source link

[CHIPTool] Can't Not Read Information from Paired Device #35758

Closed skyFzz closed 1 month ago

skyFzz commented 1 month ago

Test issue(s)

After successfully commissioned the light bulb to CHIPTool server and obtained EndpointId, ClusterId, and CommandId, , I tested to read its vendor information and on/off toggle function. All of them failed. It seems after commissioning the light bulb is disconnected again. My Matter light bulb is a Wi-Fi device without Thread support. I don't understand why reading device information will fail as well. I have attached the full output running these commands: ./chip-tool pairing code-wifi 1 [SSID] [Pass] 04090312526; ./chip-tool basicinformation read vendor-name 1 0; ./chip-tool onoff toggle 1 0x0.

These are the outputs respectively: bulb_pairing_output.txt failed_read_vendor-name.txt failed_onoff_toggle.txt

My CHIPTool Server is built on: Linux 6.8.0-1010-raspi #11-Ubuntu aarch64

Platform

No response

Anything else?

No response

bzbarsky-apple commented 1 month ago

After successfully commissioned the light bulb to CHIPTool server

The bulb_pairing_output.txt log does not show successful commissioning. It shows failed commmissioning:

[1727209506.141] [1463:1465] [CTL] Failed in verifying 'Attestation Information' command received from the device: err 101. Look at AttestationVerificationResult enum to understand the errors

which means that your chip-tool does not recognize the PAA the device is using.

You might want to use --paa-trust-store-path credentials/production/paa-root-certs with your pairing code-wifi command, if this is a production device.

skyFzz commented 1 month ago

--paa-trust-store-path credentials/production/paa-root-certs works and the output did not create any error messages! May I ask why this option is important in this case?

Also, are there any documentation explaining how to modify an unsupported cluster? Now I can actually modify them.

This is the error line I got from ./chip-tool onoff toggle 1 0:

[1727292332.792] [15194:15194] [TOO] Run command failure: IM Error 0x000005C3: General error: 0xc3 (UNSUPPORTED_CLUSTER)

Thank you so much.

bzbarsky-apple commented 1 month ago

May I ask why this option is important in this case?

By default, chip-tool uses only the test PAA (which is a root certificate that the device attestation certificate of the device chains up to). If you want it to know about some other set of PAAs, you have to tell it about them. The ones in credentials/production/paa-root-certs are periodically scraped from the Matter DCL....

Also, are there any documentation explaining how to modify an unsupported cluster

On a device whose code you can't control? What would that even mean?

This is the error line I got from ./chip-tool onoff toggle 1 0:

It would be very odd for the On/Off cluster to exist on endpoint 0. You should figure out which endpoints on the device actually have the functionality you care about: read the PartsList from Descriptor on endpoint 0, and then for each endpoint check its DeviceTypeList and whatnot.