Open thread ACK

[victor zheng]

Hi Team

Some times our nRF52 can't received the ACK from border router. But we can see that the border router send the ACK from sniffer data.  

• which Kconfig can set the Rssi filter in open thread like otLinkFilterSetDefaultRssIn
• CONFIG_OPENTHREAD_MAC_SOFTWARE_ACK_TIMEOUT_ENABLE  if I set this to N, the ACK time out is genetated by hardware?
• Can I modify the kAckTimeout value in line 650 v2.5.0\modules\lib\openthread\src\core\mac\sub_mac.hpp?
• Is there any other thing which I can check for this issue.

Regards

Victor

[Edvin]

Hello,

Can you please send the sniffer trace that your screenshot is from?

What is the root issue? Are you not seeing the ACK in your application (sometimes)? 

Best regards,

Edvin

[victor zheng]

Hi Edvin

Customer lost their orignal trace data. They send me a new one. There is also same issue in this trace data. The device drop from the thread network sometimes. 

• In trace data, From the line 2760446, the device 5a:3f:82:d6:7d:60:fd:87 become abnormal. It seems can't receiceve the ACK from router 62:5f:87:d6:91:00:d5:e4.
• The device  drop from thread network, and try to re-connect. It still can't recieved the data from router sometimes.
• The device re-connect to thread network in line 2762993.

• It took a total of one minute from the device becoming abnormal to the device returning to normal.

It seems that the device suddenly lost its RX capability. Could you help to analyze this issue. Thank you.

2024_01_07.pcapng

Regards

Victor

[Edvin]

Hello Victor,

I still can't decrypt the packets. Do you know what network key they are using?

I am looking at your trace (from Teams) now. I see (filtering on the wpan.src16 == 0x6035) that the node has a lot of retransmissions between packet ~2753543 and ~2779915. 

I see that this is not limited to the 0x6035 device. Does it occur particularly often on this device? Or is it evenly distributed?

How about the range of the devices. Are they close to one another, or are they widely spread out? Are any of the nodes physically moving, or are they stationary?

I see that there is quite a lot of traffic on the network. Did the issue occur more frequently as more nodes were added, or does it also happen if you take away e.g. half of the nodes?

A lot of questions here, but we need to start somewhere.

Best regards,

Edvin

[xht1987]

The nettwork key is 6b:f4:7b:e6:42:54:4c:cc:f1:ea:e9:2f:16:c2:fb:52,  set the right network,still see the "no extened source address".

This phenomenon is very random. When there are 20 devices in the network, one or two devices will randomly appear to have problems every day.These SED devices are relatively concentrated, spaced 10 cm apart。 they are stationary devices。I think that as the number of networking equipment increases, this problem will become more common. Reducing equipment will indeed reduce the probability of problems.

[Edvin]

I will have to run this by our Thread team. I have not received any replies yet, but I will keep you posted when I do.

Best regards,

Edvin

[Edvin]

Hello,

I just wanted to say that this ticket is not forgotten. Our Thread team will look into the matter.

Best regards,

Edvin

[victor zheng]

Hi Edvin

Both customer and I is trying to re-produce this issue on our DK and example code now. If It can be re-produced, we will have more oppotunity to debug and further investigate. In the past few days, I went on a business trip to support other urgent case. So I am sorry to late response. Thank you for your support.

Regards

Victor

[Edvin]

Hello Victor,

Our Thread team would like to know whether it is possible to reproduce on some DKs as well. Did you succeed on reproducing it? They also want to know whether it is reproducible using nodes programmed with the CLI sample, and configured as SED devices, just to make sure that it isn't some application issue (stuck in some higher priority interrupt/thread.

Best regards,

Edvin

[victor zheng]

Hi Edvin

OK. That is exactly what I am doing. But this test has not been completed yet. I will continue to work on it. if I can re-produce it, I will update more infromation. Thank you.

 

Regards

Victor

[victor zheng]

Hi Edvin

• With the customer's help. I build a test environment in our office which have 20 pcs nRF52840dongle. The respberry PI OTBR send udp data to every nodes per minute.
• We don't observed any issue in long timer test. The longest test lasted for 3 days.
• I report the test result to customer. 
• after check, customer locate this issue to their own hardware.

After they modify their hardware design, they test them for 1 month. Finally customer confirm that this issue was fixed. Thank you for your help

Regards

Victor