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

Find Delayed FIN packets in a large capture


Im trying to track down an issue where sometimes a FIN arrives 3-6 seconds after an HTTP connection with a Connection:close header very intermittently. Is there any way to filter a caputure based on total TCP session time, or perhaps long Delta time of any two packets in a tcp stream?

asked 25 Feb '17, 08:57

psilent's gravatar image

accept rate: 0%

2 Answers:


You can change the displayed time to delta between two displayed packets. Hint: Mark the two packets you want to compare and use the display filter frame.marked=true alt text

answered 25 Feb '17, 12:23

Christian_R's gravatar image

accept rate: 16%

Thank you for the response, but multiple tcp streams are occuring simultaneously. A display delta would show the next packet that arrived, not the next packet within the same tcp stream. I did find out how to do this though. Go to edit>preferences>protocol>tcp and check the calculate conversation timestamps box. You can then use the tcp.time_delay filter to find the delays between packeta in the same stream.

(25 Feb '17, 12:31) psilent

You are right! But your solution shows the delta between the first and the prev packet of a session. That is true. But the "Seconds since previous displayed packet" means the delta between the actually displayed frames. So it can be used for different kind of analysis and can also be used in a very variable way.

So if you mark two packets and use the display filter frame.marked=true it shows the delta between these packets.

(25 Feb '17, 13:10) Christian_R


You can enable "Calculate Conversation Timestamps" in the TCP protocol preferences. This will give you the two fields:

  • tcp.time_relative: Time since first frame in this TCP stream
  • tcp.time_delta: Time since previous frame in this TCP stream

You can then find (or filter) with "tcp.flags.fin==1 and tcp.time_delta>=3 and tcp.time_delta<=6". Of course it will not take into account whether or not there was a "Connection: close" header in the request, but since webserver timeouts are usually larger than 6 seconds (15 secs is seen often), you will get pretty close to what you try to accomplish.

If you want to make sure there was a "Connection: close" header first, you could either create a MATE script. Or use tshark with something like this:

tshark -r <file> -Y "tcp.flags.fin==1 and tcp.time_delta>=3 and in {`
    tshark -r <file> -T fields -e -Y "http.connection == close" | 
        sort | uniq | awk '{printf("%s ",$1)}'

(I split up this one-liner into multiple lines to make it more readable, but please just copy it all to one line)

Which will first make a list of tcp stream numbers of all tcp streams that contain a "Connection: close" header and then combines that with the filter for the long tcp delay before the FIN packet.

answered 27 Feb '17, 01:42

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%