Understanding [TCP ACKed unseen segment] [TCP Previous segment not captured]

Question

We are doing some load testing on our servers and I'm using tshark to capture some data to a pcap file then using the wireshark GUI to see what errors or warnings are showing up by going to Analyze -> expert Info with my pcap loaded in..

I'm seeing various things that I'm not sure or do not completely understand yet..

Under Warnings I have: 779 Warnings for TCP: ACKed segment that wasn't captured (common at capture start) 446 TCP: Previous segment not captured (common at capture start)

An example is : 40292 0.000 xxx xxx TCP 90 [TCP ACKed unseen segment] [TCP Previous segment not captured] 11210 > 37586 [PSH, ACK] Seq=3812 Ack=28611 Win=768 Len=24 TSval=199317872 TSecr=4506547

We also ran the pcap file though a nice command that creates a command line column of data

command

tshark -i 1 -w file.pcap -c 500000

basically just saw a few things in the tcp.analysis.lost_segment column but not many..\

Anyone enlighten what might be going on? tshark not able to keep up with writing data, some other issue? False positive?

Dapple

Answer 1

That very well may be a false positive. Like the warning message says, it is common for a capture to start in the middle of a tcp session. In those cases it does not have that information. If you are really missing acks then it is time to start looking upstream from your host for where they are disappearing. It is possible that tshark can not keep up with the data and so it is dropping some metrics. At the end of your capture it will tell you if the "kernel dropped packet" and how many. By default tshark disables dns lookup, tcpdump does not. If you use tcpdump you need to pass in the "-n" switch. If you are having a disk IO issue then you can do something like write to memory /dev/shm. BUT be careful because if your captures get very large then you can cause your machine to start swapping.

My bet is that you have some very long running tcp sessions and when you start your capture you are simply missing some parts of the tcp session due to that. Having said that, here are some of the things that I have seen cause duplicate/missing acks.

1. Switches - (very unlikely but sometimes they get in a sick state)
2. Routers - more likely than switches, but not much
3. Firewall - More likely than routers. Things to look for here are resource exhaustion (license, cpu, etc)
4. Client side filtering software - antivirus, malware detection etc.

Mojica

Answer 2

Another cause of "TCP ACKed Unseen" is the number of packets that may get dropped in a capture. If I run an unfiltered capture for all traffic on a busy interface, I will sometimes see a large number of 'dropped' packets after stopping tshark.

On the last capture I did when I saw this, I had 2893204 packets captured, but once I hit Ctrl-C, I got a 87581 packets dropped message. Thats a 3% loss, so when wireshark opens the capture, its likely to be missing packets and report "unseen" packets.

As I mentioned, I captured a really busy interface with no capture filter, so tshark had to sort all packets, when I use a capture filter to remove some of the noise, I no longer get the error.

Panel

Answer 3

Acked Unseen sample

Hi guys! Just some observations from what I just found in my capture:

On many occasions, the packet capture reports “ACKed segment that wasn't captured” on the client side, which alerts of the condition that the client PC has sent a data packet, the server acknowledges receipt of that packet, but the packet capture made on the client does not include the packet sent by the client

Initially, I thought it indicates a failure of the PC to record into the capture a packet it sends because “e.g., machine which is running Wireshark is slow” (https://osqa-ask.wireshark.org/questions/25593/tcp-previous-segment-not-captured-is-that-a-connectivity-issue)
However, then I noticed every time I see this “ACKed segment that wasn't captured” alert I can see a record of an “invalid” packet sent by the client PC

• In the capture example above, frame 67795 sends an ACK for 10384

• Even though wireshark reports Bogus IP length (0), frame 67795 is reported to have length 13194

• Frame 67800 sends an ACK for 23524
• 10384+13194 = 23578
• 23578 – 23524 = 54
• 54 is in fact length of the Ethernet / IP / TCP headers (14 for Ethernt, 20 for IP, 20 for TCP)
• So in fact, the frame 67796 does represent a large TCP packets (13194 bytes) which operating system tried to put on the wore
  • NIC driver will fragment it into smaller 1500 bytes pieces in order to transmit over the network
  • But Wireshark running on my PC fails to understand it is a valid packet and parse it. I believe Wireshark running on 2012 Windows server reads these captures correctly
• So after all, these “Bogus IP length” and “ACKed segment that wasn't captured” alerts were in fact false positives in my case

Combs

Answer 4

I just came across this and would like to share my observation of TCP ACKed unseen segment. In my case the client was trying to initiate connection on same source port and destination port it used previously and thus the server was confused and replied with old TCP SEQ number saying I havent seen this new packet

Pish