I have a HTTP webservice where sometimes the connection setup fails in a strange way:

  • client sends a SYN packet
  • server sends a SYN,ACK reply
  • client responds with RST

In which situations could a client system decide to reply with RST packet? I could imagine this happens when the SYN,ACK contains eg. incorrect sequence numbers (but this doesn't seem to apply in my case - the sequence numbers look fine). So I'm interested in an exhaustive :-) list of cases where a client would send a RST packet after receiving the SYN,ACK packet.

In particular, is it possible for the client application code (using normal BSD-style socket API under Linux) to cause this RST packet, eg. by calling close() while 3-way handshake is still in progress?

  • 1
    Are you sure it's the client sending it, not something in between?
    – NickW
    Feb 14, 2014 at 15:42
  • Good point! The packet dump indicates that the RST comes from client IP and correct port; but maybe it is actually faked by some firewall or the like... I can't check this now, but this is a good lead.
    – oliver
    Feb 14, 2014 at 15:52
  • But if this is caused by some firewall in between, why would the handshake have been allowed to start in the first place?
    – Massimo
    Feb 14, 2014 at 16:01
  • Not all firewalls intervene immediately, a similar trick is used to disrupt PtP traffic.. or maybe it's falling afoul of some other type of content filter?
    – NickW
    Feb 14, 2014 at 16:18
  • just a minor update: the packet dump from client side also shows that the RST packet is sent out. So it's at least not spoofed by some firewall inbetween, and AFAIK there's no firewall-like software set up on the client system itself. So I'm still wondering: is it possible for a socket client to cause a RST reply to a SYN-ACK packet?
    – oliver
    Feb 20, 2014 at 17:02

2 Answers 2


For closure: the problem was a stupid bug in my code (in the client).

The client in this case uses nonblocking sockets, so the connect() call will return immediately while the kernel keeps waiting for the SYN,ACK packet from server. Unfortunately the client code was very impatient: if the connection wasn't established after a few hundred milliseconds, the client would call close() on the socket.

In some rare cases the SYN,ACK packets from the server would be delayed by several hundred milliseconds on their way through the network. When the delayed reply finally arrived at the client host, the kernel would see the socket was already closed, and would treat the SYN,ACK reply as belonging to an invalid socket. That's why it would reply with a RST packet to the server.

So yes, it is possible for the application code (using normal BSD-style socket API under Linux) to cause this RST packet: by using a nonblocking socket and closing the connection while the three-way handshake is still in progress.


I used pwru and got the reason:

0xffff8bf389d5e600      1        [<empty>] kfree_skb_reason(SKB_DROP_REASON_NO_SOCKET)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .