Attestation request times out during BLE commissioning of commercial devices

[p0fi]

Summary

Commissioning a commercial device over BLE fails with a context deadline exceeded error during the attestation request step. The device is discovered, PASE session is established, failsafe is armed, commissioning and basic info are read successfully, but the AttestationRequest invoke never receives a response within the 30-second timeout.

The device can be successfully commissioned with an actual commercial commissioner (Apple Home) as well as a chip tool. Additionally the device can successfully be commissioned with the matter-cli if first commissioned via Apple Home and then opening the commissioning window again from the Apple Home app.

Commissioning a ESP32-C6 with an example app over BLE works without any issues using matter-cli.

Error

● Requesting attestation
18:10:36 DEBUG  interaction: invoke  path=EP:0/CL:0x003E/CMD:0x0000
18:10:36 DEBUG  interaction: sendIMMessage  opcode=0x08  payloadLen=64  payloadHex=1528002801360215370024000024013e240200183501300020bf8c2d967cc14e03d2a89d5879092a4030f50424953afe6b0765cf10c4e32fb018181824ff0b18
18:10:36 DEBUG  controller: sending  bytes=94  to=9efab615-ee9e-e122-f157-8b1a190ecb59  opcode=0x08  exchangeID=4  hex=003bd200ad2e2ed29d1a69371aab0ffe0649df6ff267edf913f07a19b3c6a594153f408095dc7e73f4c25712b5a49d20b986cafb247441d3321d793ced21b0ed4f5e90ebf8e3275ffca54d2aeca3b2805546890257e00669ac420fe8fe1e
18:10:36 DEBUG  btp: segment()  msgLen=94  localSeq=7  txInflight=0  hasPendingAck=true  pendingAck=6
18:10:36 DEBUG  btp: TX segment  flags=0x0d  B=true  E=true  A=true  ackNum=6  seqNum=7  msgLen=94  payloadLen=94
18:10:36 DEBUG  ble: BTP TX segment  seg=1/1  len=99  hex=0d06075e00003bd200ad2e2ed29d1a69371aab0ffe0649df6ff267edf913f07a19b3c6a594153f408095dc7e73f4c25712b5a49d20b986cafb247441d3321d793ced21b0ed4f5e90ebf8e3275ffca54d2aeca3b2805546890257e00669ac420fe8fe1e
18:10:36 DEBUG  ble: C1 WriteWithResponse dispatched to bt_queue  bytes=99
✗ Commissioning failed: commissioning: requesting attestation: invoking AttestationRequest: interaction: receiving response: context deadline exceeded

Verbose log analysis

The verbose log shows the full BLE + BTP exchange is healthy up to the attestation request:

• BLE connection, BTP handshake, PASE key exchange all succeed normally
• Multiple Invoke and Read interactions complete in <200ms each (failsafe, commissioning info, basic info)
• The AttestationRequest is sent successfully (BTP segment transmitted, no errors)
• After the AttestationRequest is sent, no further C2 data is ever received — the device simply never responds

The device remains BLE-connected (no disconnect watcher trigger), but no response arrives within the 30s window.

Reproduction

# Device must be in commissioning mode
matter -v commission code 0449-450-5895

Setup code: 0449-450-5895 (manual pairing code)
Transport: BLE (device discovered via BLE advertisement)
Platform: macOS (Darwin), tinygo BLE stack

Environment

• macOS (Darwin 25.4.0)
• matter-cli built from main branch

[p0fi]

Investigation update (2026-04-15)

Issue 1: Read function never sends StatusResponse after ReportData, violating Matter spec §8.11.4.2.

What the spec requires

After receiving ReportData (opcode 0x05), the initiator SHALL send StatusResponse(Success) unless the device set SuppressResponse=true. CHIP SDK always sends this acknowledgment. We don't.

Why this blocks cluster 0x003E

Our commissioning flow does three reads before the first cluster 0x003E command:

1. ReadCommissioningInfo (cluster 0x0030, SupportsConcurrentConnection)
2. ReadBasicInfo (cluster 0x0028, DataModelRevision)
3. (Optional) NetworkCommissioning FeatureMap — this fails/errors so exchange is properly closed

Each successful read leaves a zombie exchange on the device waiting for StatusResponse. On constrained devices with small exchange tables (often 4 slots), this may exhaust capacity or stall the commissioning state machine before the first CertificateChainRequest on cluster 0x003E.

Fix applied

In internal/interaction/client.go Read(): send StatusResponse(Success) after the final ReportData chunk when SuppressResponse is absent or false. Non-fatal if the send fails (data already received).

Also confirmed current commissioning order matches CHIP SDK:

• SetRegulatoryConfig ✓ (already added)
• PAI → DAC → AttestationRequest order ✓

Status

Build passes, all tests pass. Tested on real device without success.