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?
A. The 'TCP Previous segment not captured' message in frame 20 means that one or more packets from the Database server were not written to the pcap file, even though the application server received them properly.
TCP ACKed unseen segment Means that this packet acknowledges data that wasn't captured. It was transferred okay, and the receiver acknowledges it, but Wireshark can't find the packet in the capture. This usually happens when the capture device wasn't fast enough.
To view only TCP traffic related to the web server connection, type tcp. port == 80 (lower case) in the Filter box and press Enter. Select the first TCP packet, labeled http [SYN]. Observe the packet details in the middle Wireshark packet details pane.
The TCP flags shows what the sending TCP entity wants the receiving TCP entity to do. In this case SYNchronize with the sender, using the other data listed.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With