Bug 1033352

Description of problem:

The connection table (nf_conntrack) can contain an entry for a stale connection which can prevent a new connection from the same remote host and using the same source port from being connected.

Version-Release number of selected component (if applicable):
kernel is 2.6.32-3458.23.2.el6.x86_64
iptables-1.4.7-9.el6.c86_64

How reproducible:
100% reproducible

Steps to Reproduce:
.
Test program on System A accepts a connection on port, say, 5001 and then writes to the socket once a second. From system B, configure an iptables rule to drop RST packets to system A "iptables -A OUTPUT --dst SYSTEMA-IPADDRESS --protocol tcp --tcp-flags RST RST -j DROP". Now from system B telnet to system A port 5001. Once the telnet client sees the data sent by the test program, close the telnet session (control-] followed by "close".

On System A
A trace shows the FIN packet sent from system B, it will show the ACK from system A and then the next data segment sent by the application. It will then show a set of retransmissions as the ACK-RSTs from system B are droped by system B before being sent. If you dump the nf_conntrack file it will show the connection in a CLOSE_WAIT state with a 60 second timer. During that time the trace will show multiple retransmissions. Also it appears that the 60 second timer resets every time there is a retransmission. The effect is that the connection stays in the CLOSE_WAIT state longer than just 60 seconds, it does eventually disappear when the retransmission timer becomes longer than 60 seconds. HOWEVER, the next time that TCP sends a retransmission the nf_conntract entry is back and this time it is flagged as ESTABLISHED UNREPLIED and the timer is counting down from 432000.

Actual results:


Expected results:
This is very similar to 629857 and it was expected that with the 2.6.32-358.23.2 kernel this problem would have been resolved but it still occurs. 

Additional info: