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

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 03 Aug 2022 06:29:54 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265588

            Bug ID: 265588
           Summary: [TCP] - tcp send a retransmission identical sequence
                    number packet with different payload
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: keyong.sun@smartx.com

Created attachment 235649
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235649&action=edit
packet capture with identical sequence

Recently I test the nas deployed on the freeBSD 13.1-RC6 os as server, use the
client try to read a lager data such as 13k.

The server try to split the 13k data as several segment, such as the following
tcpdump output:
[21 Reassembled TCP Segments (131180 bytes): #2(15928), #23(2896), #27(5792),
#29(7240), #31(2896), #33(7240), #35(5792), #37(5792), #39(10136), #41(7240),
#43(2896), #45(5792), #47(5792), #49(4344), #51(7240), #62(1448), #66(1448),
#55(724]
    [Frame: 2, payload: 0-15927 (15928 bytes)]
    [Frame: 23, payload: 15928-18823 (2896 bytes)]
    [Frame: 27, payload: 18824-24615 (5792 bytes)]
    [Frame: 29, payload: 24616-31855 (7240 bytes)]
    [Frame: 31, payload: 31856-34751 (2896 bytes)]
    [Frame: 33, payload: 34752-41991 (7240 bytes)]
    [Frame: 35, payload: 41992-47783 (5792 bytes)]
    [Frame: 37, payload: 47784-53575 (5792 bytes)]
    [Frame: 39, payload: 53576-63711 (10136 bytes)]
    [Frame: 41, payload: 63712-70951 (7240 bytes)]
    [Frame: 43, payload: 70952-73847 (2896 bytes)]
    [Frame: 45, payload: 73848-79639 (5792 bytes)]
    [Frame: 47, payload: 79640-85431 (5792 bytes)]
    [Frame: 49, payload: 85432-89775 (4344 bytes)]
    [Frame: 51, payload: 89776-97015 (7240 bytes)]
    [Frame: 62, payload: 94120-95567 (1448 bytes)]
    [Frame: 66, payload: 95568-97015 (1448 bytes)]
    [Frame: 55, payload: 97016-104255 (7240 bytes)]
    [Frame: 57, payload: 104256-121631 (17376 bytes)]
    [Frame: 67, payload: 121632-127423 (5792 bytes)]
    [Frame: 68, payload: 127424-131179 (3756 bytes)]
    [Segment count: 21]
    [Reassembled TCP length: 131180]
    [Reassembled TCP Data:
80020068bfece9f500000001000000000000000000000000000000000000000000000000…]

But the very strange thing is in the packet tcpdump, there are two identical
sequence segmentations with different payload, the packet Id #62 and #63, with
the same sequence #2302694791, but the content in the payload beginning is
different, the #63 is a retransmission packet:
#62:
Transmission Control Protocol, Src Port: 2049, Dst Port: 703, Seq: 129369, Ack:
229, Len: 1448
    Sequence Number: 129369    (relative sequence number)
    Sequence Number (raw): 2302694791
    [Next Sequence Number: 130817    (relative sequence number)]
    Acknowledgment Number: 229    (relative ack number)
    Acknowledgment number (raw): 3290470326
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x010 (ACK)
    Window: 29128
    [Calculated window size: 29128]
    TCP payload (1448 bytes)
    [Reassembled PDU in frame: 68]

#63:
Transmission Control Protocol, Src Port: 2049, Dst Port: 703, Seq: 129369, Ack:
229, Len: 27512
    Sequence Number: 129369    (relative sequence number)
    Sequence Number (raw): 2302694791
    [Next Sequence Number: 156881    (relative sequence number)]
    Acknowledgment Number: 229    (relative ack number)
    Acknowledgment number (raw): 3290470326
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x010 (ACK)
    Window: 29128
    Retransmitted TCP segment data (27512 bytes)

Because of the identical sequence segments with different payload, the client
side reassemble the total payload with wrong content.

Is this expect behavior or a bug in the network stack handle the
retransmission?

thx.

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