[Bug 265588] [TCP] - tcp send a retransmission identical sequence number packet with different payload

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265588

Michael Zhilin <mizhka@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mizhka@FreeBSD.org
           Severity|Affects Only Me             |Affects Some People

--- Comment #19 from Michael Zhilin <mizhka@FreeBSD.org> ---
Hi,

I've found same defect on 13.1-RELEASE with fetching of packages via HTTP
protocol. 

Shortly speaking, https://reviews.freebsd.org/D36046 is fix for this bug. It's
already committed to stable/13 and main. 

The issue is not reproduced on 14-current and stable/13.
My setup is following:
 - FreeBSD guest in data center in same town (with poudriere and HTTP nginx)
 - I use VPN & WiFi to access it

Sometimes packets are lost and server may start retransmission of several
packets with same payload but with different sequence numbers. Sometimes, but
not always. Then it sends same payload third time with correct payload. :/

For testing I download 500MiB file 4 times:

fetch -q http://192.168.20.12:8000/gcc11-11.3.0_1.pkg && md5 gcc11-11.3.0_1.pkg 
fetch -q http://192.168.20.12:8000/gcc11-11.3.0_1.pkg && md5 gcc11-11.3.0_1.pkg 
fetch -q http://192.168.20.12:8000/gcc11-11.3.0_1.pkg && md5 gcc11-11.3.0_1.pkg 
fetch -q http://192.168.20.12:8000/gcc11-11.3.0_1.pkg && md5 gcc11-11.3.0_1.pkg 

If all checksums are correct, kernel is good. 

I've bisected it to commit:
https://github.com/freebsd/freebsd-src/commit/c21b7b55bea2cc2bf3b420c70a9018e703ed6f00

commit c21b7b55bea2cc2bf3b420c70a9018e703ed6f00
Author: Richard Scheffenegger <rscheff@FreeBSD.org>
Date:   Wed Aug 31 14:49:25 2022 +0200

    tcp: finish SACK loss recovery on sudden lack of SACK blocks

    While a receiver should continue sending SACK blocks for the
    duration of a SACK loss recovery, if for some reason the
    TCP options no longer contain these SACK blocks, but we
    already started maintaining the Scoreboard, keep on handling
    incoming ACKs (without SACK) as belonging to the SACK recovery.

    Reported by:            thj
    Reviewed by:            tuexen, #transport
    MFC after:              2 weeks
    Sponsored by:           NetApp, Inc.
    Differential Revision:  https://reviews.freebsd.org/D36046

 sys/netinet/tcp_input.c | 39 ++++++++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 17 deletions(-)

Many thanks to Gleb and Richard!

-- 
You are receiving this mail because:
You are the assignee for the bug.