Date: Thu, 20 Oct 2022 14:38:11 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 265588] [TCP] - tcp send a retransmission identical sequence number packet with different payload Message-ID: <bug-265588-7501-9yja0e8UMW@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-265588-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-265588-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265588 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.=20 Shortly speaking, https://reviews.freebsd.org/D36046 is fix for this bug. I= t's already committed to stable/13 and main.=20 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, b= ut 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=20 fetch -q http://192.168.20.12:8000/gcc11-11.3.0_1.pkg && md5 gcc11-11.3.0_1= .pkg=20 fetch -q http://192.168.20.12:8000/gcc11-11.3.0_1.pkg && md5 gcc11-11.3.0_1= .pkg=20 fetch -q http://192.168.20.12:8000/gcc11-11.3.0_1.pkg && md5 gcc11-11.3.0_1= .pkg=20 If all checksums are correct, kernel is good.=20 I've bisected it to commit: https://github.com/freebsd/freebsd-src/commit/c21b7b55bea2cc2bf3b420c70a901= 8e703ed6f00 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! --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-265588-7501-9yja0e8UMW>