This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

tcp ack and retransmission

0

Hi,

I am seeing the following:

TCP ACK SEQ 2640421534 ACK 3886631705 tcp.len is 0 bytes, ACK FLAG
TCP DATA PACKET SEQ 2640421534 ACK 3886631705 tcp.len 19 bytes, PUSH and ACK flags, Wireshark expert analysis marks it has a RETRANSMISSION.

I confused why this is a RETRANSMISSION. The SEQ and ACK numbers are the same, but one packet is simple ACK and the subsequent is a data packet.

asked 15 Jan '15, 21:54

Dummycat's gravatar image

Dummycat
6●2●2●3
accept rate: 0%

edited 16 Jan '15, 00:29

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k●9●57●245

One Answer:

0

In order to be able to give an answer to your question, you would have to show a few more packets before the ACK packet, as there is most likely already data sent in this direction with a sequence number of 2640421534.

If you are able to upload the capture data to www.cloudshark.org, that would make it easier to analyze and help you.

answered 16 Jan '15, 01:35

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

SYN-bit,

Thanks for your response. I can't upload the file because it contains client data.

This is what I have done before I posted

  • Created columns for SEQ, NEXT SEQ and ACK numbers then sorted by SEQ number. This created two different behaviors:
  • If Wireshark analysis of the TCP ACK (tcp.len=0) packet has the message "TCP previous segment not capture" then the subsequent TCP DATA (tcp.len=19) packet is analyzed without any issues.

  • If the TCP ACK (tcp.len=0) packet does not have any issues then the TCP DATA (tcp.len=19) packet is classified as a retransmission

  • versions 1.10.12 and 1.12.2 (same issue)

  • exporting the stream to another file (this is the fix when intermittently out-of-order are classified as retransmissions)
(16 Jan '15, 04:35) Dummycat

Maybe use TraceWrangler (http://www.tracewrangler.com) to sanitize your file, and make sure you select the option to remove unknown payloads. You can also force cutting after layer 4, which leaves you with everything up to the TCP layer, which is probably good enough in this case. Together with IP address randomization you should do fine, but of course you should check the sanitized file before uploading.

(16 Jan '15, 06:49) Jasper ♦♦

Sounds like the packet before the ACK (tcp.len==0) has a length that should include (part of) the data from the DATA packet (tcp.len==19).

Could you either use TraceWrangler and post an anonimized version of the file (like Jasper suggested) or post the output of:

tshark -nr <file> -T fields -e frame.number -e tcp.srcport -e tcp.dstport -e tcp.seq -e tcp.len -e tcp.ack
(18 Jan '15, 09:02) SYN-bit ♦♦