[BUG] matter 1.1 paring failed

[Leo2442926161]

Reproduction steps

do pairing ble-thread and paring failed at Commissioning stage next step: 'ThreadNetworkEnable' -> 'FindOperational'

Bug prevalence

everytime

GitHub hash of the SDK that was being used

7e69c66

Platform

efr32

Platform Version(s)

matter 1.1

Anything else?

I captured the log on efr32 and chiptool, please take a look, thanks.

chiptool matter 1.1 paring failed log.txt
efr32 matter 1.1 paring failed.TXT

[bzbarsky-apple]

So the server gets ConnectNetwork:

[00:00:16.441][detail][DMG] Received command for Endpoint=0 Cluster=0x0000_0031 Command=0x0000_0006

then it looks like it joins the Thread network:

[00:00:19.030][detail][DL] OpenThread State Changed (Flags: 0x200012a4)
[00:00:19.036][detail][DL]    Device Role: CHILD
[00:00:19.041][detail][DL]    Partition Id: 0x48D823F2

then it tries to start advertising and that fails

[00:00:19.205][info  ][DIS] Advertise operational node 93109EF7FF257EDC-00000000000004D2
[00:00:19.213][info  ][SVR] Operational advertising enabled
...
[11:30:49.394] ’°˚°Ù[00:00:21.073][error ][DL] SRP update error: operation refused for security reasons

that update error happens a bunch more times. Eventually the commissioner times out on the operational resolve and gives up.

@Damian-Nordic any idea what would lead to that "SRP update error: operation refused for security reasons" bit?

[bzbarsky-apple]

@Leo2442926161 what Thread border router are you using?

[bzbarsky-apple]

@Leo2442926161 And just to check, does the same configuration work with the 1.0 branch?

[msandstedt]

[11:30:49.394] ’°˚°Ù[00:00:21.073][error ][DL] SRP update error: operation refused for security reasons

I don't recognize that specific error string. But in the past we had seen that reuse of a node ID after a factory reset would cause attempted advertisement to be rejected by the SRP server because this would collide with an existing entry. The conclusion in that case was that this behavior of the SRP server was correct.

This had been discussed at some length here: #6539 (comment)

[Leo2442926161]

@Leo2442926161 And just to check, does the same configuration work with the 1.0 branch?

Thanks for you quick reply, I tried it with TH v2.6 chip-tool and obtr in VM.
The chip-tool HASH is 7e69c66

[Leo2442926161]

[11:30:49.394] ’°˚°Ù[00:00:21.073][error ][DL] SRP update error: operation refused for security reasons

I don't recognize that specific error string. But in the past we had seen that reuse of a node ID after a factory reset would cause attempted advertisement to be rejected by the SRP server because this would collide with an existing entry. The conclusion in that case was that this behavior of the SRP server was correct.

This had been discussed at some length here: #6539 (comment)

Hi msandstedt, thank you for your help, it seems not same situation, also I tried different NodeID and restarted chip-tool.

[fuxiaoming-lumi]

This problem may not be caused by register the same service(NodeID/FabricID). I can reproduce the same problem with efr32 platfrom today when I try use 7e69c66. I confirmed that in the same environment, it is normal to use 1.0 branch. After enable more log from device side and check the otbr log, it should be that the device can't send the srp update message(https://github.com/openthread/openthread/blob/main/src/core/net/srp_client.cpp#L797) and cause Matter commissioning failure.
efr32-Matter-Commissioning-failure-20230202.txt

Border Router: connectedhomeip/otbr:sve2 docker image (1813352247aa60fb8993773918f1e5b4af6f3b79)
There are the same problems in smartthing and apple ecosystem. (with homepod mini and smartthing hub v3).

00> [00:00:51.591][info  ][ot] [I] Settings------: Read SrpEcdsaKey
00> [00:00:51.600][info  ][ot] [I] SrpClient-----: Failed to send update: Security
00> [00:00:51.600][info  ][ot] [I] SrpClient-----: State ToUpdate -> ToRetry
00> [00:00:51.600][info  ][ot] [I] SrpClient-----: Quick retry 1 in 247 msec
00> [00:00:51.639][info  ][DL] Tx Confirmation received
00> [00:00:51.639][info  ][DL]  stop soft timer
00> [00:00:51.639][info  ][DL] _OnPlatformEvent kCHIPoBLEIndicateConfirm
00> [00:00:51.847][info  ][ot] [I] Settings------: Read SrpEcdsaKey
00> [00:00:51.856][info  ][ot] [I] SrpClient-----: Failed to send update: Security
00> [00:00:51.857][info  ][ot] [I] SrpClient-----: Quick retry 2 in 248 msec
00> [00:00:52.105][info  ][ot] [I] Settings------: Read SrpEcdsaKey
00> [00:00:52.114][info  ][ot] [I] SrpClient-----: Failed to send update: Security
00> [00:00:52.114][info  ][ot] [I] SrpClient-----: Quick retry 3 in 245 msec
00> [00:00:52.359][info  ][ot] [I] Settings------: Read SrpEcdsaKey
00> [00:00:52.369][info  ][ot] [I] SrpClient-----: Failed to send update: Security
00> [00:00:52.369][info  ][ot] [I] SrpClient-----: Quick retry 4 in 258 msec
00> [00:00:52.494][detail][ot] [D] Mle-----------: network id timeout = 0
00> [00:00:52.495][detail][ot] [D] DuaManager----: reregdelay 2, checkdelay 0
00> [00:00:52.495][info  ][ot] [I] MlrManager----: MLR Reregister!
00> [00:00:52.495][detail][ot] [D] MlrManager----: -------- Multicast Addresses --------
00> [00:00:52.495][detail][ot] [D] MlrManager----: MlrManager::UpdateReregistrationDelay: rereg=0, needSendMlr=1, ReregDelay=1954
00> [00:00:52.627][info  ][ot] [I] Settings------: Read SrpEcdsaKey
00> [00:00:52.636][info  ][ot] [I] SrpClient-----: Failed to send update: Security

[fuxiaoming-lumi]

What is the reason for removing sl_mbedtls_init(); from here.
d80211c#diff-2e03a69dfa30a03c3033260c21754f0d398aab897bbbc85e40963a5da5b1a536
https://github.com/project-chip/connectedhomeip/blob/TE_23_02/rc2/examples/platform/silabs/efr32/init_efrPlatform.cpp#L66
This will lead to failure here. https://github.com/SiliconLabs/openthread/blob/ad3e4f5a6cf1183786df38a082ed808fe3b3d7f1/src/core/net/srp_client.cpp#L1316

[fuxiaoming-lumi]

After init mbedtls module, everything works fine from my side. However, this problem may affect 1.1 test event. Because we mark TE_23_02/rc2 for this test event. Need hotfix here.

[jmartinez-silabs]

The removal of the sl_mbedtls_init was indeed a mistake.

#24764

This pr was merged yesterday to add it back

Can it be cherry picked to the RC?

[andy31415]

Can it be cherry picked to the RC?

@jmartinez-silabs

RCs are tags on master, there is currently no defined path for cherrypicks.
Thinking of ideas:

• we could create a branch too (preferably short lived) and cherrypick to it. Historically though CSG seemed to want unchanging code
• allow/recomend TE participands to apply specific patches for their own builds, while using unpatched CSG harness builds.

@cjandhyala - what could we do here? It seems silabs boards require a fix to be able to participate in the TE, and this is more fundamental than single test case failures - device pairing fails completely.

[cjandhyala]

@jmartinez-silabs since this fix is applicable specific to EFR32 platform and our TE is most recent, we dont want to spend time in creating a branch and do downstream work of updating TH ..etc. I recommend the second approach and then mention this change in the TEDS tool when uploading test results.