Packet length is shrink in TCP retransmission

asked 2023-09-06 10:45:38 +0000

I captured a pcap for POST timeout issue. From the screenshoot it caused by a TCP retransmission looping: https://ibb.co/fQBVjKD

I have two question:

(1) From No.220509 and No.220564, why TCP segment length is shrink? TCP retransmission might re-construct the data so the length is possible to be larger but will it be smaller?

(2) From the server viewpoint, the client is sending something it has already received (the ACK sequence number 2008 < 2014), normally what will the server do? Will it be dropped by the server?

Comments

You might add a column for tcp.hdr_len then check to see if more TCP options are added in the retransmission frames.

Chuckc ( 2023-09-06 14:34:14 +0000 )edit

The TCP header length is not changed (20+12 options) in retransmission frames (220509 vs. 220564). Only TCP segment length decrease 6 bytes.

I also found the IP length (ip.len) is changed from 1422 to 1416, and my MTU setting is 1416. Would it be the reason?

ethan_chang ( 2023-09-07 06:57:46 +0000 )edit

add a comment

answered 2023-09-07 11:55:27 +0000

SYN-bit

18344 ●9 ●304 ●255 https://SYN-b.it

Answers to your questions:

From the shown packets, it is not clear why the retransmission has a smaller segment length than the original packet. However, when you mention that there are 12 bytes of TCP options used, then the first POST has an excess of 6 bytes to it's own MSS. This might be a bug. Somehow the retransmission does take the MSS into account properly
Depending on whether SACK is enabled and DSACK is supported, it will either just send a DUP-ACK or a DUP-ACK with DSACK option. Looking at the length of the packet, it looks like a DSACK block might be present in the DUP-ACKs. Generally, the retransmitted TCP segment will be ignored.

Most worrysome part of your packet capture is that the data of the server does not seem to be arriving at the client, at least it is not ACKed.

Like always, analyzing a screenshot is not our hobby, please supply a pcap file on any of the public file shares, anonymized with TraceWrangler if needed.

edit flag offensive delete link

Comments

Hi, Thank you so much for your answer!

And sorry for the late response. I'm a newbie for packet traceing and I was digging into the pcap based on your answer and how to erase PII by TraceWrangler.
The pcap is uploaded to my onedrive with the link: https://1drv.ms/u/s!Aj6t2KKTK65ugk8D5yEZth2NCv05?e=39Yp8X

More information based on your hints:
 - The TCP segmentation offload is enabled:
 - The SACK is enabled and DSACK is supported

tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: on
        tx-tcp-mangleid-segmentation: off

My inference is the following:
 - It's okay that No.10 ip length > MSS because it's TSO enabled
 - However, when it enters retransmission for congestion, the window shrinks and it can't send packet over MSS
 - Then the retransmitted DUP-ACK is dropped by the kernel

As you're mentioned, the server reply DUP-ACK with SACK(644-2008) so it did receive ...

(more)

ethan_chang ( 2023-09-13 05:52:54 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Packet length is shrink in TCP retransmission

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Packet length is shrink in TCP retransmission edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Packet length is shrink in TCP retransmission