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?
This question is related to
networking
tcp
This is because there is another process in the network sending RST to your TCP connection.
Normally RST would be sent in the following case
In your case, it sounds like a process is connecting your connection(IP + port) and keeps sending RST after establish the connection.
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.
This is because there is another process in the network sending RST to your TCP connection.
Normally RST would be sent in the following case
In your case, it sounds like a process is connecting your connection(IP + port) and keeps sending RST after establish the connection.
One thing to be aware of is that many Linux netfilter firewalls are misconfigured.
If you have something like:
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -j REJECT --reject-with tcp-reset
then packet reordering can result in the firewall considering the packets invalid and thus generating resets which will then break otherwise healthy connections.
Reordering is particularly likely with a wireless network.
This should instead be:
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -p tcp -j REJECT --reject-with tcp-reset
Basically anytime you have:
... -m state --state RELATED,ESTABLISHED -j ACCEPT
it should immediately be followed by:
... -m state --state INVALID -j DROP
It's better to drop a packet then to generate a potentially protocol disrupting tcp reset. Resets are better when they're provably the correct thing to send... since this eliminates timeouts. But if there's any chance they're invalid then they can cause this sort of pain.
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.
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.
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 tells the receiving station to (very ungracefully) close the connection. this is done to save resources.
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.
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.
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.
I've just spent quite some time troubleshooting this very problem. None of the proposed solutions worked. Turned out that our sysadmin by mistake assigned the same static IP to two unrelated servers belonging to different groups, but sitting on the same network. The end results were intermittently dropped vnc connections, browser that had to be refreshed several times to fetch the web page, and other strange things.
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.
One thing to be aware of is that many Linux netfilter firewalls are misconfigured.
If you have something like:
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -j REJECT --reject-with tcp-reset
then packet reordering can result in the firewall considering the packets invalid and thus generating resets which will then break otherwise healthy connections.
Reordering is particularly likely with a wireless network.
This should instead be:
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -p tcp -j REJECT --reject-with tcp-reset
Basically anytime you have:
... -m state --state RELATED,ESTABLISHED -j ACCEPT
it should immediately be followed by:
... -m state --state INVALID -j DROP
It's better to drop a packet then to generate a potentially protocol disrupting tcp reset. Resets are better when they're provably the correct thing to send... since this eliminates timeouts. But if there's any chance they're invalid then they can cause this sort of pain.
I've just spent quite some time troubleshooting this very problem. None of the proposed solutions worked. Turned out that our sysadmin by mistake assigned the same static IP to two unrelated servers belonging to different groups, but sitting on the same network. The end results were intermittently dropped vnc connections, browser that had to be refreshed several times to fetch the web page, and other strange things.
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.
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 tells the receiving station to (very ungracefully) close the connection. this is done to save resources.
Source: Stackoverflow.com