First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

Packet length is shrink in TCP retransmission

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?

ethan_chang's avatar
3
ethan_chang
asked 2023-09-06 10:45:38 +0000
edit flag offensive 0 remove flag close merge delete

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's avatar Chuckc (2023-09-06 14:34:14 +0000) edit
more
  • delete

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's avatar ethan_chang (2023-09-07 06:57:46 +0000) edit
more
  • delete
add a comment see more comments

1 Answer

0

Answers to your questions:

  1. 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
  2. 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.

SYN-bit's avatar
18.5k
SYN-bit
answered 2023-09-07 11:55:27 +0000
edit flag offensive 0 remove flag delete link
more

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's avatar ethan_chang (2023-09-13 05:52:54 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer