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:
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 edited 26 Sep '16, 11:24 |
One Answer:
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. answered 20 Sep '16, 16:55  Jasper ♦♦ 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 |
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?
@Jasper Thanks for the reply. Added the CloudShark link