Open dnygren opened 2 years ago
From a discussion on the lwip-users mailing list: https://lists.nongnu.org/archive/html/lwip-users/2023-02/msg00008.html
My best guess is a low level driver bug that happen when packets are sent in a short timeframe, which big UDP packets do due to IP fragmentation taking place. Sending small packets at a low rate does not fix the problem, it just hides it.
So someone knowledgeable about lwIP thinks this is a Xilinx driver problem.
I’m using a very simple baremetal Zynq lwIP based UDP echo server https://github.com/dnygren/zynq_echo_servers_udp/tree/master/C%2B%2B/zynq_echo_server_udp_cpp/src to test lwIP's UDP functionality. It is built using Xilinx Vivado/SDK 2018.3, standalone 6.8, along with lwIP 2.11 v1.7 on a PicoZed board (I’ve also used earlier lwIP versions with the same result, and used a ZedBoard with the same result).
I see rather bizarre behavior in that messages of length 4385 and 4386 I send to the Zynq echo server are not received back.
udp_sendto()
appears to be getting called and completing successfully. Wireshark indicates there are "bogus, payload length" errors with these lengths.Create files of length 4384, 4385, 4386, & 4387:
Verify lengths
Point PC at Zynq board running echo server:
File length 4384 echos fine:File length 4384 echos fine:
File length 4384 echos fine: (No echo of file lengths 4385 & 4386) File length 4387 echos fine:I’ve tried the same experiment on a ZedBoard with the same result. Using wireshark with a filter of “src host 10.100.93.70” I get the following for the failing / no output 4386 case: Also failing / no output 4385 case: For a 4384 passing case I get: For a 4387 passing case **(note it is now frame 4)** I get : If you have a baremetal Zynq running an lwIP UDP echo server, can you check if it fails with message lengths of 4385 & 4386? Is there some sort of frame boundary bug in the UDP lwiP library? I haven't make extensive checks of which message lengths fail and which pass. Maybe there are more failing conditions.