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.
Thanks Simon, I can see that is the code's intent, except the PC
never sends more than one dupack.
Sorry if I wasn't clear, my precise question is:
Why is tcp_rexmit_fast resulting in an out-of-order packet as
reported by Wireshark?
Is something wrong in tcp_rexmit_fast?
Thanks again,
Best Regards, Dave
Regards,
Simon
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
--
Dave Nadler, USA East Coast voice (978) 263-0097, address@hidden, Skype
Dave.Nadler1
|