Date: Thu, 20 Oct 2022 11:47:47 +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-CakarcQsyB@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 --- Comment #17 from Richard Scheffenegger <rscheff@freebsd.org> --- 1448 byte chunks between server and client align perfectly until server fra= me #51 (5 chunks: 0xb23ee730dd 0xc2fd29b2eb 0xbe27bbf1be 0xb829e51fdc= =20=20=20 0xbc5b20682b) and client frame #48 (3 chunks 0xb23ee730dd 0xc2fd29b2eb= =20=20=20 0xbe27bbf1be). The last two chunks of the TSO get dropped. server #62 is the lost 4th chunk of #51. And server #63 starts with chunk 5 of #51 but doesn't have the correct sequ= ence number! Frame 66 repeats chunk 5 of #51, with the correct sequence number. TSO frame 63 seems to send everything from snd.una for an entire window, but the seq number is off by one segment (1448) to the left. However, 19 packets during SACK loss recovery is unexpected too! (In short, I feel like the TSO frame #63 shouldn't be there at all). I wonder if this may be the issue https://reviews.freebsd.org/D36637 althou= gh that's dealing with the traffic burst, not the erraneous sequence number... --=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-CakarcQsyB>