Sorry, I corrected the link in my first post over http://lwip.100.n7.nabble.com/lwip-users-f3.html Here is the correct link to the correct file: https://drive.google.com/file/d/1NXsqdz7LNC5vTqxyRgvJo_cXhRXczWav/view
OK, I will try to turn on LWIP_STATS, if this is what you are suggesting. Meanwhile I made several test and I can only see the problem when the transmission a of a second file takes place between the requesting a first file and ACK-ing a (last?) frame belonging to the first file. Description of Tx frames: ... PC: REQ file 1 STM32: PSH+ACK file 1 (part 1) /[ missing ACK from PC for this part - will come later down ]/ ------------------------------------here starts file 2 PC: REQ file 2 STM32: PSH+ACK + data file 2 (part1) PC: ACK file 2 (part1) ... (portions of file 2 including all needed frames) STM32: last frame of file 2 PC: FIN File2 SM32: ACK FIN file 2. -------------------------------- end of file 2. And then: /[ continue with ACK for file 1 --- ~40ms after FIN file 2]/ PC: ACK file 1 (part 1) /[ after 1.9 seconds ! ]/ STM32: last frame of file 1 PC: FIN file 1 SM32: ACk FIN file 1. Cannot happen that LwIP forgets about (or assigns low prio to) transmitting that last frameof file 1, and re-deal with it only after seconds? In your opinion the STM driver eventually does not (or delayedly) receive the ACK file 1 (part 1) after FIN file 2, right? How can I prove and trace that? -- Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
