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

TCP Retransmission after Reset RST flag


I have around 20 clients communicating together with a central server in the same LAN. The clients can make transaction simultaneously with the server. The server forward each transaction to external appliance in the network. Sometimes it works, sometimes my application shows a "time out" message in a client screen (randomly)

I mirrored all traffic and found TCP Retransmission after TCP Reset packets for the first TCP Sequence. I immediately thought about packet loss but all my cables/NIC are fine, and I do not see DUP ACK in the capture.

It seems that RST packets may have different significations.
What causes those TCP Reset?
Where should I focus my investigation: network or application design ?

I would appreciate any help. Thanks in advance.

asked 22 Jul '14, 01:08

Julien's gravatar image

accept rate: 0%

edited 01 Aug '14, 00:49

can you provide a capture file, e.g. on I doubt anyone will read/analyze that many packets in an ASCII dump.

(22 Jul '14, 01:22) Jasper ♦♦

Hi Jasper. Thanks for the suggestion. I've updated the post.

(22 Jul '14, 01:54) Julien

One Answer:


Your clients do connect to at port 2200. Those connections work fine, according to the data in the capture file. But then the clients do connect to the same server on ports 11007,11008,11012,11014 and 11015. Those are connection attempts that get a RESET. The client seems to either ignore the RESET, as it sends the SYN again, or the RESET does not reach the client.

To me it looks like those ports are dynamically negotiated in your application, similar to FTP, where a dynamic port is "negotiated" in the control channel on port 21.

Maybe the server did not open a socket (fast enough) for the 'announced' port (110xx) and thus the OS sends a RESET. Without an in-depth understanding of your application, it's impossible to explain why this happens.


answered 22 Jul '14, 02:22

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%

Thank you, Kurt! Could RESET be due to the network or physical layer? Ive updated my post with some info about the application (if it helps) If needed I can provide a capture from the server (more packets exchanges)

(22 Jul '14, 06:41) Julien

Could RESET be due to the network or physical layer?

Physical layer? Well..., no. How should send the RESET at the physical layer? The cable? I don't think so ;-))

Network layer? Well...., yes or maybe. There could be a device between the client and the server that blocks the connections, like a firewall. However, in your case it must be a transparent firewall, as the MAC addresses are all the same, so that does not sound very reasonable to me either.

More likely it's the server (firewall on the server) or your application (bug), and according to Occam's razor:

  • "among competing hypotheses, the one with the fewest assumptions should be selected" ;-)

Where should I focus my investigation: network or application design ?

If you capture on the server and if you see the RESET there as well, it's pretty clear that it's most likely an application problem, which I believe, based on you capture file.

So, I suggest to concentrate on the application!

(22 Jul '14, 08:33) Kurt Knochner ♦

any progress here?

(01 Aug '14, 01:39) Kurt Knochner ♦