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

What could cause packets to be ACKed before they are transmitted?

1

Hi

I captured info from dumpcap installed on a computer with windows 7 x64 installed. The computer has the IP address: 172.16.6.96. Throughout the file packets are ACKed before they are transmitted. The ACKs are marked as TCP ACKed unseen segment. Any ideas what could cause this? Attached are two images from the capture with examples of the issue.

There are no retransmissions, etc. there are several keep alive messages not show in the image of the capture.

[2] http://www.tiikoni.com/tis/view/?id=879459f

asked 08 Jan '15, 11:14

Mark%20Nassy's gravatar image

Mark Nassy
26225
accept rate: 0%

(08 Jan '15, 11:17) Mark Nassy

2 Answers:

1

Packets are not--and cannot--be ACKed before they are sent. "TCP ACKed unseen segment" means that the ACK is present in your Wireshark trace file, but the data packet that is being acknowledged is not present in the trace. The data packet did make it all the way from the sender to the receiver, otherwise there would not be an ACK, but the data packet is not in the trace file. This means that your file is incomplete, and you need to use caution in using it for analysis.

There are two common causes of this problem:

First, there is asymmetric routing, so not all packets take the same path, and you captured somewhere along the path where Wireshark did not see all packets.

Second, Wireshark was simply not able to keep up and not all packets were written into the trace file.

answered 08 Jan '15, 15:09

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

The ACK's do seem to be received before the corresponding TCP segment. However I don't recognise the output format. Can the OP post a pcap of the data rather than a screenshot interpretation of the data.

(08 Jan '15, 15:31) grahamb ♦

Thanks. 1.I captured the network traffic using dumpcap.exe installed on the client with the issue. The client has only one network adapter. 2.The network adapter is 100 Mbps, and dumpcap.exe said the kernel did not drop any packets. The network adapter is not heavily utilized, as well as the CPU at the time of the issue. This always happens on the 4 packet for HTTP, and TNS traffic. SYN, SYN-ACK, ACK, then unseen ACK.

I tried to turn on TCP time stamping in the hope I would be able to determine if there was any missing packets by using the echo value but was unsuccessful.

I was able to turn on Errors in the LAN connection status window and it shows 0 errors.

I plan to capture traffic on Monday using a switch connected right next to the client and see if I get anything different.

For my knowledge: if I capture at the client and dumpcap drops (in this case) an outgoing packet, and it receives an ACK for the packet (by ACK number) that was dropped, why does it show that the packet was transmitted later on in the trace file?

(08 Jan '15, 16:04) Mark Nassy

I will work on getting a better capture on Monday and update the post at that time.

(08 Jan '15, 16:08) Mark Nassy

FYI: Some of the output columns are from the TRANSSUM lua plugin.

(08 Jan '15, 16:21) Mark Nassy

0

I ran a capture from another computer connected to a switch with a SPAN port and did not see any unseen segments ACKed. The end result was the same as in the previous capture. The same SQL query showed a delay in the time it took for the server to send its response. I don't know why capturing on the client computer that issued the sql query resulted in unseen segments.

answered 14 Jan '15, 17:42

Mark%20Nassy's gravatar image

Mark Nassy
26225
accept rate: 0%