Date: Thu, 20 Oct 2022 09:47:12 +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-EgjmkjjdLm@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 #10 from Richard Scheffenegger <rscheff@freebsd.org> --- There seems to be a discrepancy in the TSO vs LRO payload bytes (maybe my script is broken?): Server:=20 2 10.234.1.9 35249 229 15928 11 72053392291 385714934591 419632206729 401031568921 41004322083= 9=20=20=20 398170924830 381008236919 388657879560 400554947764=20=20=20 390059647829 401051361480 Client: 2 10.234.1.9 35249 229 11584 8 72053392291 385714934591 419632206729 401031568921 41004322083= 9=20=20=20 398170924830 381008236919 388657879560 3 10.234.1.9 46833 229 4344 3 403699027891 383855600553 414816586574 The last 3 chunks from the server side trace, don't seem to be identical wi= th the three chunks received in a separate LRO aggregation (!). This is how I create these chunk-sums: tshark -r ClientIdenticalSeq.pcap -T fields -e frame.number -e ip.src -e tcp.seq -e tcp.ack -e tcp.len -e tcp.options.sack_le -e tcp.options.sack_re= -e tcp.payload | awk ' //{ fr=3Dint($5/1448); if ((fr*1448 =3D=3D $5) && (fr > 0)) { print $1" "$2" "$3" "$4" "$5" "fr; for (i=3D0;i<fr;i++) { s =3D 0; for (n=3D0;n<(1448/8);n++) { v =3D sprintf("%d ", "0x" substr($6,i*1448+n*8,8)); s =3D s + v; } f[s]++; if (f[s] > 1) { printf("#") }; printf("%d \t", s); } } printf("\n"); } My expectation would be that the sums calculated this way for the tcp paylo= ad is identical when TSO / LRO capture data... Note that this difference is visible before the SACK retransmissions. Was the capture created just before issuing the NFS read? Because the expectation there would be for the sender side to transmit all the data in sequence, and not skip over some data. It appears the captures were trimmed after taking, in the middle of a loss recovery episode from a prior NFS read IO... --=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-EgjmkjjdLm>