Why does thread sed device Network Attaching always fail

[dengyuxin2]

hardware platform：EFR32MG21
openthread commit：2ce3d3bf0 silicon Gecko SDK 4.1.0
gecko_sdk 4.1.1/4.4.4 When using the chip tool commissioning matter over thread ssed device, it always fails. However, in the same situation, using the chip tool to debug matter over thread ftd device can succeed, and using Raspberry Pi's OTBR can successfully commissioning the same matter over thread sed device. What is the reason for this? This problem has been troubling us for a long time Please help analyze it. Thank you very much for your。Is it related to csl features？
thread info：
Active Timestamp: 1
Channel: 25
Channel Mask: 0x07fff800
Ext PAN ID: 7e49aca8d0695302
Mesh Local Prefix: fde2:5bf5:7ef9:cefc::/64
Network Key: 3dd94d9bfae02bf189b5f30827de967f
Network Name: OpenThread-b88b
PAN ID: 0xb88b
PSKc: 851a4a3d4fab46cf66d4983cb7d88a9e
Security Policy: 672 onrc

otbr log:
MobaXterm_root@OpenWrt_20240416_193523.txt
Packet capture：
thread设备入网_202404161939.zip

[suveshpratapa]

Hi, can you upgrade to a newer Silicon Labs SDK? We're currently on 4.4.2 as the latest stable release, and also we've made a lot of platform changes relating to CSL and SSEDs since 4.1.1.

To address your particular SDK question:

1. What baud rate is configured on the RCP / otbr-agent?
2. Can you describe the way you're setting up your SSED example, including CLI and CSL parameters?

I'll take a look at your packet trace but as I said we've fixed a lot of issues since 4.1.1 so your best bet is to upgrade to a newer release.

[dengyuxin2]

@suveshpratapa Thank you for your reply！
1、baud rate：115200
2、The sub device is a third-party commercial product purchased online, and I do not know these parameters
I used two sensor devices for testing:
One is Eve's human body sensor

One is a green meter door magnetic sensor

[suveshpratapa]

We recommend using a higher baud rate on OTBR for CSL operations if possible. Can you reconfigure your host and RCP to run at baud rate 460800? Please check the sections "3.2.2.1 UART Baud Rate Settings" and "3.2.4 OTBR Configuration for CSL" in our application note for OTBR.

[dengyuxin2]

@suveshpratapa hello We have upgraded to the Silicon latest SDK version 4.4.1 and 4.4.2 of and tested it using your development board，The test is still the same, but joining the thread network failed, What is the reason for this? Is it our compilation error
But if only the thread protocol is run, it can be successful in the same environment and device with a single thread protocol

otbr log + Packet capture：
otbr_log+Packet_capture.zip

the thread device demo：

[suveshpratapa]

@dengyuxin2

This OT_CHILD_SUPERVISION option has been canceled in the new version and is forced on by default.

I was suggesting it because I saw you turn it explicitly on in the CMake steps above. I'm surprised you didn't see a build error for the option that is no longer available.

We'll need to analyze this further, I'm concerned that a basic attach sequence fails with no Child ID response. That being said, it is interesting that the successful trace (first screenshot above) is also showing no child ID response for the successful SED attach...

[dengyuxin2]

@suveshpratapa
It is possible that the packet capture tool may have leaked packets.
After the sed device is powered off and powered on for a while, I can capture the child id response sent by the ftd device to the child device, but until now I have never captured the child id response packet sent by otbr.

[silabs-gregoire]

Hi @dengyuxin2, for this issue can you please post this on the Silabs community? We can offer more support there as Silabs engineers actively review posts: https://community.silabs.com/

[suveshpratapa]

@dengyuxin2 On the community post, please include information about the third-party devices you're using if you can.

[dengyuxin2]

@silabs-gregoire @suveshpratapa I have posted this on the Silabs community, here is the link to ask the question https://community.silabs.com/s/question/0D5Vm000009NGLSKA4/sed-device-always-fails-to-attach-to-otbr

[dengyuxin2]

@suveshpratapa @silabs-gregoire hi!
I tracked the code process of sending the child id response, and compared and analyzed the multi-protocol otbr logs of the official otbr and silabs on the Raspberry Pi. The response data of the low-power device will first be added to the child device information through this function IndirectSender::AddMessageForSleepyChild. , waiting for sending, waiting for the sub-device information to be received. The GetMac::Mac().RequestIndirectFrameTransmission() function will be called in the DataPollHandler::HandleDataPoll function to send, but your otbr has never been called because of the received frame. It always shows that no ack has been received for confirmation.
Why does the received frame RxFrame::IsAckedWithFramePending function always return zero?

silabs multi-protocol otbr log:
The log shows that received frames ack-fp always show zero ack-fp=0

Raspberry Pi runs official otbr log:
The log shows that ack-fd is sometimes 1, ack-fd=1, so the DataPollHandler::HandleDataPoll will call GetMac::Mac().RequestIndirectFrameTransmission() to send the data.