Packet loss is normal UDP behavior (unless it is excessive).  If you use UDP, you application design must handle occasional packet loss gracefully.

In order to debug this further, you will need to enable network statistics.

349 config NET_STATISTICS
350         bool "Collect network statistics"
351         default n
352         ---help---
353                 Network layer statistics on or off

104 config NETDEV_STATISTICS
105         bool "Network device driver statistics"
106         depends on NET_STATISTICS && ARCH_HAVE_NETDEV_STATISTICS
107         ---help---
108                 Enable to collect statistics from the network drivers (if supported
109                 by the network driver).

You view the network statistcis using ifconfig under NSH.  This should pinpoint where the packet it lost in the software or driver.  It will not detect inherent network losses such as collisions.

On 8/4/2022 2:07 AM, Oleg wrote:
Hi all,

I'm working with a custom stm32f767 based board and px4 project fork with
nuttx-10.0.0+ and uploading data (~900KB) to the board using mavlink_ftp.

If mavlink is over serial port everything is fine and long transfer going
uninterruptedly, but if mavlink is over UDP link the ftp file transfer
sometimes stumbles: PC doesn't receive acknowledgment, wait for timeout,
retry request and continue to transfer normally some time until next
stumble.

According to mavlink_ftp debug, at that moment the board doesn't receive
the last ftp mavlink package, so it doesn't send ack. I've checked with
wireshark, a PC definitely sends a UDP packet out, but the board doesn't
receive this mavlink packet.
I can reproduce this issue easily, but didn't notice any regularity in the
size of data between losses.

When I've added DEBUG_FEATURES, DEBUG_ERROR, DEBUG_NET, DEBUG_NET_ERROR to
config I can't reproduce the issue, no loss in UDP transfer.

Mavlink FTP upload is quite simple: on each request there is the
acknowledgement, no burst sending, so, as I see it, the issue should not be
related to buffer overflow.

Any thoughts on how to debug this or maybe someone remember potentially
related fixes in UDP/Ethernet in recent NuttX? Thanks in advance for help!

---
With best regards, Oleg.


Reply via email to