Mangled incoming TCP packets confuse outgoing ACK processing
 

Has anyone seen or know of a problem with the handling of mangled incoming TCP packets in Linux 2.4.21 or 2.6.16 during "bulk delivery" -- like FTP? Essentially, one of incoming packets has a bad TCP checksum, mangled by some intervening switch no doubt. This apparently causes the TCP stack to NOT respond with duplicate ACKs for all subsequent packets, but it knows the mangled packet is bad and drops it. The sender waits 0.4 seconds and resends the missing packet. The receiver responds immedeiately with an ACK for all remaining packets. Below is an trace of such an incident from the sender side:

No. Time Source Destination Protocol Info
519 0.890490057 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [ACK] Seq=359165 Ack=0 Win=32942 Len=881 TSV=2997354060 TSER=274491797
520 0.890508126 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [ACK] Seq=360046 Ack=0 Win=32942 Len=881 TSV=2997354060 TSER=274491797
521 0.890526195 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [ACK] Seq=360927 Ack=0 Win=32942 Len=881 TSV=2997354060 TSER=274491797
522 0.890544264 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [ACK] Seq=361808 Ack=0 Win=32942 Len=881 TSV=2997354060 TSER=274491797
523 0.890562333 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [ACK] Seq=362689 Ack=0 Win=32942 Len=881 TSV=2997354060 TSER=274491797
524 0.890580402 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [ACK] Seq=363570 Ack=0 Win=32942 Len=881 TSV=2997354060 TSER=274491797
525 0.890599801 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [ACK] Seq=364451 Ack=0 Win=32942 Len=881 TSV=2997354060 TSER=274491797
526 0.890640694 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=365332 Ack=0 Win=32942 Len=881 TSV=2997354060 TSER=274491797
527 0.891022601 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=366213 Ack=0 Win=32942 Len=555 TSV=2997354061 TSER=274491797
528 0.891111503 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=366768 Ack=0 Win=32942 Len=326 TSV=2997354061 TSER=274491797
529 0.891784979 172.23.11.45 172.17.133.10 TCP 32002 > 56394 [ACK] Seq=0 Ack=360927 Win=48455 Len=0 TSV=274491797 TSER=2997354060
530 0.892018410 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=367094 Ack=0 Win=32942 Len=881 TSV=2997354062 TSER=274491797
531 0.892249940 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=367975 Ack=0 Win=32942 Len=881 TSV=2997354062 TSER=274491797
532 0.892899659 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=368856 Ack=0 Win=32942 Len=881 TSV=2997354062 TSER=274491797
533 0.893148821 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=369737 Ack=0 Win=32942 Len=881 TSV=2997354063 TSER=274491797
534 0.893542315 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=370618 Ack=0 Win=32942 Len=246 TSV=2997354063 TSER=274491797
535 0.893588683 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=370864 Ack=0 Win=32942 Len=635 TSV=2997354063 TSER=274491797
536 0.894447856 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=371499 Ack=0 Win=32942 Len=881 TSV=2997354064 TSER=274491797
537 0.895108942 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [PSH, ACK] Seq=372380 Ack=0 Win=32942 Len=881 TSV=2997354064 TSER=274491797
538 1.309210769 172.17.133.10 172.23.11.45 TCP [TCP Retransmission] 56394 > 32002 [ACK] Seq=360927 Ack=0 Win=32942 Len=1448 TSV=2997354480 TSER=2
74491797
539 1.309213063 172.23.11.45 172.17.133.10 TCP 32002 > 56394 [ACK] Seq=0 Ack=373261 Win=48675 Len=0 TSV=274491839 TSER=2997354060
540 1.309214071 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [ACK] Seq=373261 Ack=0 Win=32942 Len=869 TSV=2997354481 TSER=274491839
541 1.309215023 172.17.133.10 172.23.11.45 TCP 56394 > 32002 [ACK] Seq=374130 Ack=0 Win=32942 Len=881 TSV=2997354481 TSER=27449183

Pkt#521 is mangled (bad TCP checksum). The rcver ACKs in Pkt#529 up to and including Pkt#520. At Pkt#538, the sender has waited 0.4 seconds and resends Pkt#521 as Pkt#538. The rcver immediately responds with Pkt#539, which ACKs up to and including Pkt#537. NOTICE that Linux is NOT sending any duplicate ACKs for Pkts 522 thru 537!!!!

Does anyone have any clues about this?

Thanks,
Neil B.