Hello, im currently running into the following problem: http://abload.de/image.php?img=60-er-jahre-russische2yxhd.jpg This shows the communication between a client and server application on Port 17001. The problem is that the Client will timeout / lose the connection to server and has to be restarted to be working properly again. This communcation is over an IPSEC-VPN. I've captured the traffic and i can see that the Client seends a whole lot of TCP DUP ACK followed by RST in answer to Retransmission. Could the cause of the aborts lie in the TCP DUP ACKS? asked 19 Jan '17, 13:11  doktorake |
One Answer:
The TCP DUP ACKs are not the problem, they are just an indicator for packet loss. The interesting thing in this case is that (looking at TCP stream #3, filter on it by using "tcp.stream==3") the connection is torn down before the data transfer is complete. There is in fact packet loss which is signaled by the receiver, and when the sender starts resolving it using retransmissions it looks like a normal recovery at first. But then the receiver suddenly sends a FIN in packet 3179 (even though it didn't yet receive all missing packets), which is technically not incorrect as it means "hey, I'm done sending" - but then it also sends a reset in 3181, which means "stop immediately, abort abort abort". Keep in mind that at this point in time, packets are still missing, as can be seen in the SACK option of the FIN packet. So it looks to me like the client giving up and aborting the connection here instead of patiently waiting for the missing packets to be retransmitted. answered 20 Jan '17, 02:16  Jasper ♦♦ Thank you for the INPUT. As the communication goes trough a VPN tunnel with the Server sides being an external DMZ IP and the client IP being internal, could it be possible that the VPN-Tunnel starts to rebuild (cause of expiring SA or smth other) causing a few packets being and the client starting to go via WAN ( as the port is reachable) and then RST the servers answer via the tunnel (once it starts working again). But im guessing its just inside the application how it reacts to packetloss.... (20 Jan '17, 07:01) doktorake 1 It's the clients fault here, because it doesn't show enough patience to receive the remaining retransmissions as far as I can tell. So I doubt its a tunnel problem. (20 Jan '17, 07:04) Jasper ♦♦ I've could reproduce the error with a different pcap outcome. This time the client answers with RST,ACK. Is this any different now? (23 Jan '17, 04:27) doktorake i didnt notice the huge timegap between data and RST. As there is a 30minute gap, i suppose its just a timeout on the application side. (23 Jan '17, 05:28) doktorake Yes, very likely... RST with an ACK is often a non-critical connection abort. Meaning: it's used instead of FIN/ACK FIN/ACK because its faster and needs less ressources. And with a long timeout like that, the connection is most likely just shut down due to inactivity. (23 Jan '17, 05:33) Jasper ♦♦ |
If possible, please provide a capture file. It's just no fun trying to figure things out from a messy screenshot.
Check out this blog post: https://blog.packet-foo.com/2016/11/the-wireshark-qa-trace-file-sharing-tutorial/
Thank for the input. I dont know where i should upload the pcap, so i uploaded it at: https://ufile.io/5b3ee
Hope that is ok.