Ask Your Question

Receive RST which is not found on the other side of the communication

asked 2019-01-09 09:58:52 +0000

BeatH gravatar image

updated 2019-01-10 08:04:37 +0000

I have communication between a Linux and windows system. Don't have info about rooters/switches/firewall between.

The communication runs perfect, but out of the blue it send a RST. I trace both sides at the same time and try to understand why I receive a RST, which is not found in the trace file of the other side:

I receive on a Linux system [RST] Seq=xxx which is not in the trace of the windows system. Under Acknowledgment number yyy I have the ExpertInfo: The acknowledgment number filed is nonzero while the ACK flag is not set.

Would be great if somebody can give some advice how to proceed.




  • Everything is running normal
  • Then server-socket (Linux) sends client-socket (Windows) PSH, ACK <==is expected
  • 8ms later client-socket (windows) sends RST --> server-socket (Linux)
  • This RST can be found only in the Linux trace. Not in the windows trace
edit retag flag offensive close merge delete


The easiest answer to the question "try to understand why I receive a RST" is "because an intermediate node inserts it". Since you have no information on any intermediate node this is what you should seek. Easiest starting point there is probably the Windows machine firewall, virus protection, etc, etc.

Also, try installing npcap to replace WinPcap for the Windows capture and see if that exposes something extra.

Jaap gravatar imageJaap ( 2019-01-09 10:31:54 +0000 )edit

Hi Jaap I added an example. Do I understand you correct: A router/switch/firewall modifies messages? I would say this is spoofing.

BeatH gravatar imageBeatH ( 2019-01-10 08:07:19 +0000 )edit

Router or switch not so much, but firewall or IDS could modify/insert packets to reach their objective.

Jaap gravatar imageJaap ( 2019-01-10 20:27:36 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2019-01-15 20:26:40 +0000

SYN-bit gravatar image

On the Linux side, have a look at the value of IP TTL of the packets received from the Windows host. They are probably all the same. Now have a look at the value of the IP TTL of the received RST packet. Is the TTL the same or different? If it is different, there is a big chance that an intermediate device closed the connection. There can be several reasons:

  • The intermediate device is an IPS and saw data that triggered a rule to close the connection
  • The intermediate device is a firewall or loadbalancer that closed the connection due to a session timeout (what is the delta time between the RST and the previous packet in the TCP stream?
edit flag offensive delete link more


Hi SYN-bit

IP TTL is the same for PSH, ACK and the RST (127ms) I can find delta between previous PSH and RST from 1ms up to 3.5 secs. The application protocol allows a max of 10secs until an application line-check is send.

In the meantime we figured out that we had an ip-conflict. Since this is fixed. it seems to run. To learn something I filtered the conflict ip-address and checked the MAC in Ethernet II. But to my surprise they are all the same. So I'm still puzzled.

BeatH gravatar imageBeatH ( 2019-01-16 17:37:12 +0000 )edit

If the TTL of the packets from the windows system is TTL when they arrive at the linux system, then there was most likely 1 routing hop in between them. This means the mac-address of the windows host is stripped by that router and replaced with its own mac-address. So even when there are two different systems using the same IP address (with different MAC addresses), after being routed, their packets will have the IP and MAC address.

SYN-bit gravatar imageSYN-bit ( 2019-01-16 23:52:29 +0000 )edit

Thanks for the explanations. Now it makes sense.

BeatH gravatar imageBeatH ( 2019-01-17 07:32:55 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-01-09 09:58:52 +0000

Seen: 418 times

Last updated: Jan 15 '19