otbr-agent.service exiting due to HandleRcpTimeout()

[OlivierGre]

I have a RPi connected to a RCP and configured to create a Thread network.
I can see a new problem on my RPi: The otbr-agent is crashing all the time due to HandleRcpTimeout():

Nov 25 09:02:22 raspberrypi otbr-agent[1818]: 00:00:13.101 [I] BorderRouter--: Start evaluating routing policy, scheduled in 2483 milliseconds
Nov 25 09:02:22 raspberrypi otbr-agent[1818]: 00:00:13.338 [W] Platform------: radio tx timeout
Nov 25 09:02:22 raspberrypi otbr-agent[1818]: 00:00:13.338 [C] Platform------: HandleRcpTimeout() at radio_spinel_impl.hpp:2243: RadioSpinelNoResponse
Nov 25 09:02:22 raspberrypi systemd[1]: otbr-agent.service: Main process exited, code=exited, status=6/NOTCONFIGURED
Nov 25 09:02:22 raspberrypi systemd[1]: otbr-agent.service: Failed with result 'exit-code'.
Nov 25 09:02:27 raspberrypi systemd[1]: otbr-agent.service: Scheduled restart job, restart counter is at 5.

I'm attaching the full syslog.
25_11_2022_syslog.log

I have had this problem when I was working on the commissioning of Thread device. The commissioning was successful. I then switched off the commissioned device. After some time, I saw that the otbr-agent was crashing (there were no more device connected to the thread network).

During some tests, I have replaced the RCP by another one and the problem disappeared. However, the problem happened again later so it is not related to the board. I suspect that it is related to the device that is commissioned but not present.

Would you have some advices to help me to find which RCP command is timing out?

Thank you

[jwhui]

The log indicates that the the timeout is occurring on a radio transmit attempt.

Can you provide more detail about your setup? In particular:

1. Hardware platform of RCP.
2. How you built the RCP image.
3. Serial bus settings (e.g. UART / SPI, datarate, etc.).

[OlivierGrenoble]

The RCP is a p-nucleo-wb55 (I'm working for STMicroelectronics). It is not built from command line like other RCPs.
It is connected to the raspberry through a FTDI cable. I don't know the data rate but I will search.

Thanks for the information about the timeout on radio transmit attempt.

[jwhui]

Thanks for the additional information.

The TX timeout value is currently 5 seconds, which is pretty long. The issue you are seeing could be due to one or more of the following:

1. RCP is not completing the transmit attempt within the TX timeout.
2. Spinel frames to/from the RCP are being dropped. This could be due to bit errors or running out of buffers.

[OlivierGrenoble]

Thanks, I will check that

[OlivierGre]

Hi Jonathan,
Here is the RCP log.
25_11_2022_rcp.log

There is a recurrent error :
␛[0m[0000113676]␛[0;92m [REGION UNDEF] [I] LinkRaw-------: Frame tx failed, error:NoAck, retries:0/15, len:116, seqnum:62, type:Data, src:da27460e73e395e5, dst:2681cc5687d25832, sec:no, ac

It is probably related to the crash of the otbr-agent because it occures at the same frequency.

Do you know the purpose of such "LinkRaw" command? How can I determine if this command has been sent by the Raspberry Pi?

FYI, the IP Address "fe80:0:0:0:2481:cc56:87d2:5832" was the IP address of the Thread device that I had commissioned the day before. This Thread device is off so it is normal that no Ack is received. However it is not expected that it leads to a crash of the otbr-agent.

Thank you

[jwhui]

The LinkRaw component simply provides an interface for sending/receiving raw IEEE 802.15.4 frames. The RCP's primary function is to send/receive raw IEEE 802.15.4 frames, so it depends on the LinkRaw component.

Log errors indicating NoAck failures are common - they simply indicate that a packet transmission attempt did not receive the expected acknowledgment, which is common in normal wireless environments.