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

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

--- 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: 

2 10.234.1.9 35249 229 15928 11
72053392291     385714934591    419632206729    401031568921    410043220839   
398170924830        381008236919    388657879560    400554947764   
390059647829    401051361480

Client:

2 10.234.1.9 35249 229 11584 8
72053392291     385714934591    419632206729    401031568921    410043220839   
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 with
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=int($5/1448);
        if ((fr*1448 == $5) && (fr > 0)) {
                print $1" "$2" "$3" "$4" "$5" "fr;
                for (i=0;i<fr;i++) {
                        s = 0;
                        for (n=0;n<(1448/8);n++) {
                                v = sprintf("%d ", "0x"
substr($6,i*1448+n*8,8));
                                s = 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 payload
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...

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