Failed to commission the Matter device using official credentials.

[SunHuang]

I have already written the factory data to the device, and commissioning via Apple TV is successful.

It also works when using the --bypass-attestation-verifier 1 parameter on a Raspberry Pi.

However, it fails when using the --paa-trust-store-path /home/ubuntu/FH parameter. Below is the log from my device.

PAA.zip

[AHaug]

Hi,

I will look into the logs, but in the meanwhile, could you let me know about what SDK version you're working with?

Kind regards,
Andreas

[SunHuang]

Hi,

My version is 2.9.0. According to the logs, the VendorID being used is 0xFFF1.
Is the "--paa-trust-store-path" parameter only supposed to include PAA.der, or does it also need CD.der?

[SunHuang]

Hi

Has there been any progress?

[AHaug]

Hello,

Apologies for the delayed response, we've been out of office due to Easter.

SunHuang said:

Is the "--paa-trust-store-path" parameter only supposed to include PAA.der, or does it also need CD.der?

This should be the path to the directory itself, i.e from the docs: https://docs.nordicsemi.com/bundle/ncs-latest/page/matter/chip_tool_guide.html#attestation-related_flags 

--paa-trust-store-path - Use to provide the path to the directory that contains the information about Product Attestation Authority (PAA) certificates. The path can be absolute or relative to the current working directory. With this flag, the CHIP Tool looks for the PAA certificate that matches the PAI and the DAC certificates programmed on the device. Without this flag, the CHIP Tool uses the built-in test PAA certificate.

SunHuang said:

Am I doing something wrong?

It could be that you're overwiting some certificate when you program the factory data, or that you're missing to program the CD to the device. Could you refer to https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/matter/end_product/configuring_cd.html?

Kind regards,
Andreas

[SunHuang]

Hi 

Yes, your assumption is correct. I did not write the CD into the device.

However, I discovered another issue: when I generate the factory data using "generate_nrfconnect_chip_factory_data.py", the resulting QR code(build.txt) is different from the UART log.

Only when I configure it through prj.conf(CONFIG_CHIP_DEVICE_VENDOR_ID,CONFIG_CHIP_DEVICE_PRODUCT_ID,CONFIG_CHIP_DEVICE_DISCRIMINATOR,CONFIG_CHIP_DEVICE_SPAKE2_PASSCODE) does the UART log match the build.txt.

[AHaug]

Hello,

Great, then we're progressing a bit.

W.r.t the second issue you see:

SunHuang said:

owever, I discovered another issue: when I generate the factory data using "generate_nrfconnect_chip_factory_data.py", the resulting QR code(build.txt) is different from the UART log.

Only when I configure it through prj.conf(CONFIG_CHIP_DEVICE_VENDOR_ID,CONFIG_CHIP_DEVICE_PRODUCT_ID,CONFIG_CHIP_DEVICE_DISCRIMINATOR,CONFIG_CHIP_DEVICE_SPAKE2_PASSCODE) does the UART log match the build.txt.

A colleague of mine had some thoughts w.r.t this and were able to reproduce the issue and find a solution that worked for them to generate matching QR codes.

If you dont have --include_passcode when generating the factory data, then the passcode won't be written to the device. Meaning that you either have to ommitt --passcode in the factory data (it is optional and you can use spake2_verifier instead), or you will have to build with --include_passcode instead. The latter should generate a qr code that matches the uart as well.

If that does not work, then you can also use 

./chip-tool payload generate-qrcode [--existing-payload] [--discriminator] [--setup-pin-code] [--version] [--vendor-id] [--product-id] [--commissioning-mode] [--allow-invalid-payload] [--rendezvous] [--tlvBytes], for instance as 

./chip-tool payload generate-qrcode --discriminator 1234 --setup-pin-code 13243546 --vendor-id 0x123 --product-id 0x123

and then attach the resulting QR code URL at the end of this url https://project-chip.github.io/connectedhomeip/qrcode.html?data=, which will result in https://project-chip.github.io/connectedhomeip/qrcode.html?data=MT:GWQS0POG02A48B1OA00.

The last suggestion requires some manual work, so I hope the first suggestion with --include_passcode works for you.

Kind regards,
Andreas

[SunHuang]

Hi

Do you mean setting the passcode in prj.conf, and then not using the --passcode option when generating the factory data with generate_nrfconnect_chip_factory_data.py?

[AHaug]

Hi,

AHaug said:

If you dont have --include_passcode when generating the factory data, then the passcode won't be written to the device. Meaning that you either have to ommitt --passcode in the factory data (it is optional and you can use spake2_verifier instead), or you will have to build with --include_passcode instead. The latter should generate a qr code that matches the uart as well.

The above section refers to the arguments you call the python script with

Kind regards,
Andreas