I am investigating an issue on a network at the moment and although I have found the issue, it has highlighted a behavior in Wireshark that I hope someone can explain to me. I can't post the pcap as its quite large and contains sensitive data, but the sttached screenshot of the TCP information should help. On this, we are looking at treams with index 0 & 1. As these 'bad clients' have caused issues with the server by not ACKing the [FIN, ACK] packet in the past, I am trying to script the detection of these occurances using tshark. However if I run the same file through tshark like this:
it doesn't find any of these retransmissions. Is this a bug in Tshark, or an expected difference in behavior, or just something I am doing wrong int he first place? asked 04 Feb '14, 01:04  Boidy |
You can see that the TCP handshake sets up correctly, and a small amount of data is sent and ACKed in both directions. Then the server sends a [FIN, ACK], but gets no response. Wireshark correctly detects the retransmission of the [FIN, ACK] packets as shown in the screenshot.
One Answer:
Please try to run tshark with option -2 (two pass analysis) and
Regards answered 04 Feb '14, 01:58  Kurt Knochner ♦ edited 04 Feb '14, 02:02 Thanks for your response. The version of Tshark I had installed on the box doesn't support '-2', and its not a trivial job to upgrade it. I put the test pcap file on another platform with the latest Tshark, and your suggestion worked. Surprisingly, running it without -2 and with a -Y option set instead of -R, also found the packets. So I'm guessing that there is bug in the version of TShark I have on my server. (04 Feb '14, 03:15) Boidy |
I appreciate this isn't a support forum for Cascade Pilot, but I can't get that to detect these retransmissions either.