Hello, im currently running into the following problem:
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
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