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

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

Jt8786
11114
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 https://www.tracewrangler.com) 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 10.186.131.236) doesn't seem to get through, which is why we see the packets from 10.22.193.39 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 10.22.193.39.

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 10.22.193.39. 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 ♦♦
23.8k551284
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

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "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:

×32

question asked: 20 Sep '16, 16:29

question was seen: 3,601 times

last updated: 14 Feb '17, 15:36

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