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

Hi guys,

I've done some homework, but am coming up a bit short. I've searched but haven't been able to identify what might cause something like this.

I've been working on a problem where my client application never receives the last packet of an HTTP response, which leads to timeout errors.

Looking at the packet capture, I see that the server has successfully sent all of it's data, and sends a FIN ACK. The client receives all of this data, ACKs the FIN ACK, but never FIN ACKs or resets the connection. From the client side capture:

WireShark Image

In packet 67, the server sends a FIN ACK, but the client never responds with a FIN ACK or a reset. The server, then expecting an FIN ACK, resends it's FIN ACK, the client then ACKS again and this repeats until the server closes the connection.

I guess my question is, what are things that can cause a client to not respond to a FIN ACK?

Edit: Here is the CloudShark Link for when it fails Here is the CloudShark Link for when it works Here is the CloutShark Link server side

asked 20 Sep '16, 16:29

Jt8786's gravatar image

accept rate: 0%

edited 26 Sep '16, 11:24

What needs to be done here is tracking TCP sequence numbers, but that's impossible with a screenshot like this. Can you sanitize your pcap (e.g. with TraceWrangler, see and upload the sanitized file somewhere, e.g. Cloudshark?

(20 Sep '16, 16:34) Jasper ♦♦

@Jasper Thanks for the reply. Added the CloudShark link

(20 Sep '16, 16:44) Jt8786

Okay, to answer the question first: nothing should cause a client to not respond to a FIN ACK, unless it's the last packet in the conversation (meaning, the teardown FIN/ACK/FIN/ACK sequence is complete).

In your capture file, the ACK in 68 (and any following ACK from doesn't seem to get through, which is why we see the packets from marked as "TCP Spurious Retransmission": Wireshark has seen that the FIN/ACK packets were in fact acknowledged, but that packet was lost on the way to

What you should do (if possible at all) is to check if there is any kind of ACL/Firewall blocking those outgoing ACK packets. I can't think of any valid reason right now, but something is preventing the ACKs from getting through to Normally I would now start capturing packets along the path to see where the ACK isn't seen anymore, to pinpoint the device that blocks the ACK. But that may not be possible, depending on the network architecture and your access to it.

permanent link

answered 20 Sep '16, 16:55

Jasper's gravatar image

Jasper ♦♦
accept rate: 18%

Good enough for me!

Thank you so much for looking at this.

(20 Sep '16, 17:00) Jt8786

Just to close the loop on this incase anybody else ever runs across something similar. Trend Micro Officescan's Web Reputation was the cause of the problem.

Thanks again to @Jasper for the sanity check.

(14 Feb '17, 15:36) Jt8786
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 20 Sep '16, 16:29

question was seen: 4,102 times

last updated: 14 Feb '17, 15:36

p​o​w​e​r​e​d by O​S​Q​A