Am 05.05.2019 um 15:47 schrieb Dave Nadler:
Hi all - Back to look at this delay issue. Update: I studied the driver and ST-provided FreeRTOS/LwIP/cmsis glue and all looks AOK, unlike the extremely buggy code ST provides for ST32F7xx series.Again, after a lost packet, the host (PC running Windows 10) issues a _*single*_ duplicate-ack and waits. LwIP receives the single duplicate ack and by design _*ignores it*_ (tcp_in.c lines 1207-1227). LwIP takes two passes through slow_tmr (.5 sec intervals) before retransmitting the lost packet. Hence nasty >1 second delay. I tried patching LwIP to _immediately_ retransmit on a duplicate ack (line 1215): if (pcb->dupacks >= 1 /* DRN kludge prevents 1+sec delays after lost packet, should be: 3 */) { /* Do fast retransmit (checked via TF_INFR, not via dupacks count) */ tcp_rexmit_fast(pcb); } Wireshark shows a TCP out-of-order packet, which it did not do unpatched (after the 1.5 sec delay): http://www.nadler.com/backups/20190503_Lwip_pause_kludgeFix.pcapng Is this OK? Or is there something wrong in tcp_rexmit_fast?
No, fast_rexmit is supposed to kick in after 3 dupacks, not at the first dupack. Regards, Simon _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
