What causes a TCP/IP reset (RST) flag to be sent?

Question

I'm trying to figure out why my app's TCP/IP connection keeps hiccuping every 10 minutes (exactly, within 1-2 seconds). I ran Wireshark and discovered that after 10 minutes of inactivity the other end is sending a packet with the reset (RST) flag set. A google search tells me "the RESET flag signifies that the receiver has become confused and so wants to abort the connection" but that is a little short of the detail I need. What could be causing this? And is it possible that some router along the way is responsible for it or would this always come from the other endpoint?

Edit: There is a router (specifically a Linksys WRT-54G) sitting between my computer and the other endpoint -- is there anything I should look for in the router settings?

Answer 1

Some firewalls do that if a connection is idle for x number of minutes. Some ISPs set their routers to do that for various reasons as well.

In this day and age, you'll need to gracefully handle (re-establish as needed) that condition.

Answer 2

A 'router' could be doing anything - particularly NAT, which might involve any amount of bug-ridden messing with traffic...

One reason a device will send a RST is in response to receiving a packet for a closed socket.

It's hard to give a firm but general answer, because every possible perversion has been visited on TCP since its inception, and all sorts of people might be inserting RSTs in an attempt to block traffic. (Some 'national firewalls' work like this, for example.)

Answer 3

In short, the listener that's sending the RST packet does so because it wants to keep the connection open (not abort it), but have your end resend the last packet of data. This can happen if, for example, it receives an ACKnowledgement with the wrong sequence number.

You're correct that it isn't necessarily the endpoint - it could be a firewall or the like. If you suspect that this may be the case, run two instances of Wireshark (or tcpdump, or whatever) - one at each end - and compare them; if you see a RST in one that isn't in the other, then you'll need to dig into the intermediate points.

Answer 4

Run a packet sniffer (e.g., Wireshark) also on the peer to see whether it's the peer who's sending the RST or someone in the middle.

Answer 5

If there is a router doing nat, especially a low end router with few resources it will age the oldest tcp sessions first. To do this it sets the rst flag in the packet that effectively tell the receiving station to very ungracefully close to connection. this is done to reserver sesources.

Answer 6

RST is sent by the side doing the active close because it is the side which sends the last ACK. So if it receives FIN from the side doing the passive close in a wrong state, it sends a RST packet which indicates other side that an error has occured.

Answer 7

Did you ever get this figured out? I can't comment because I don't have enough points, but I have the same exact problem you were having and I am looking for a fix.