Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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: