Open thread ACK

RE: Open thread ACK

victor zheng — Wed, 24 Apr 2024 07:21:07 GMT

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

RE: Open thread ACK

victor zheng — Thu, 01 Feb 2024 13:56:40 GMT

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

RE: Open thread ACK

Edvin — Thu, 01 Feb 2024 08:04:36 GMT

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

RE: Open thread ACK

victor zheng — Fri, 26 Jan 2024 06:54:48 GMT

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

RE: Open thread ACK

Edvin — Thu, 25 Jan 2024 13:35:20 GMT

Hello,

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

Best regards,

Edvin

RE: Open thread ACK

Edvin — Fri, 19 Jan 2024 11:47:04 GMT

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

RE: Open thread ACK

xht1987 — Thu, 18 Jan 2024 04:13:52 GMT

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.

RE: Open thread ACK

Edvin — Tue, 16 Jan 2024 13:55:06 GMT

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

RE: Open thread ACK

Edvin — Fri, 12 Jan 2024 09:06:21 GMT

Hello Victor,

Sorry for the late reply. I have been out of office since Monday.

I get this popup when I try to open the trace:

In addition, the file only has 1018837 lines. Finally, I am not able to decrypt the packets:

But I am not sure whether that is due to a different network key, or if it is because the file is corrupted.

Do you see the same if you download the file that you uploaded? And do you see the same if you open your original file?

Do you know anything about the placement of the node that drops out? Is it far from the other devices? Is it possible that it is not in range of the rest of the network?

Best regards,

Edvin

RE: Open thread ACK

victor zheng — Fri, 12 Jan 2024 00:52:49 GMT

Hi Edvin

Is there any update for this issue?

Regards

Victor

RE: Open thread ACK

victor zheng — Sat, 06 Jan 2024 01:42:18 GMT

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.

devzone.nordicsemi.com/.../2024_5F00_01_5F00_07.pcapng

Regards

Victor

RE: Open thread ACK

Edvin — Fri, 05 Jan 2024 12:57:03 GMT

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