From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Description of problem: This is a completely up-to-date RHEL 5.2 server. Producing a great deal of text output after restarting the iptables service will hang an ssh connection in which the command is run and the text output is generated. Version-Release number of selected component (if applicable): iptables-1.3.5-4.el5, kernel-2.6.18-92.el5 How reproducible: Always Steps to Reproduce: 1. ssh to the affected machines 2. su or sudo -s to root 3. run "service iptables restart" 4. within a few seconds or so (no realy hurry), run a program that produces a great deal of text output. E.g., "dmesg". 5. The ssh session will hang until the TCP connection finally times out. Actual Results: The ssh connection into the machine hangs before the "dmesg" output completes. Eventually the TCP connection times out, the ssh process goes away, and you're dropped to the shell prompt on the connecting machine. Expected Results: dmesg should finish and the ssh connection should not hang. Additional info: We can reproduce this on servers running RHEL 5.1 and RHEL 4 but not RHEL 3. We cannot reproduce this on a server running Ubuntu 8.04. It sounds like it's a 2.6 kernel issue, and something introduced by RedHat. That should help narrow things down. If your "dmesg" is short, it may not produce enough output for this bug to manifest, if so, try resetting ip tables again and running "dmesg;dmesg;dmesg" or a continual loop or cat a huge file or some such to cause the problem to manifest itself. It's *possible* but unlikely there is some overlap between this and bug 165744. Let me know if you want/need more information.
Do I understand this correct: Your ssh connection only dies if you output lots of text, and if you do not, it is still up and working?
I see this problem as well. Yes, the connection continues to function fine until such time as you run a command that produces a sufficient amount of output. Something like cat /usr/share/dict/words will work as well. Note that the problem affects any other ssh conections that were underway at the time of the iptables restart. Also, I have some evidence that it affects all active tcp/ip connections (i.e. not just ssh) that were allowed by the iptables rules and were open at the time of the restart.
A firewall restart resets the firewall, unloads all netfilter modules and configures the firewall again. But this should affect the applications immediately. Therefore it seems to be a kernel problem. Assigning to kernel.
Since the status is in "NEEDINFO" from me, I'll answer Comment #1. Yes, that supposition is correct. I'll also point out that the comments by Gavin Scott are exactly on point, and that his comments should be considered interchangeable with my own.
has been successfully reproduced, investigating... nice workaround for default iptables rules, for ssh: --A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT +-A RH-Firewall-1-INPUT -p tcp --dport 22 -j ACCEPT
just a notice: vanilla 2.6.18.4, used as a base for RHEL5 kernels has the issue as well. So that the problem was not introduced by any of Red Hat's patches. /me investigating...
Created attachment 309201 [details] proposed patch upstream commit #a09113c2c8ec59a5cc228efa5869aade2b8f13f7 solves this issue.
Created attachment 309218 [details] proposed patch for RHEL5 backport of upstream patch
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
in kernel-2.6.18-103.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-0225.html