Bug 448328
| Summary: | ssh connection hangs when running command producing large text output after running "service iptables restart" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Nick Christenson <npc> | ||||||
| Component: | kernel | Assignee: | Anton Arapov <anton> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Martin Jenner <mjenner> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 5.2 | CC: | dzickus, gavindscott, igeorgex, k.georgiou, nobody, rlerch | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-01-20 20:21:03 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Nick Christenson
2008-05-25 23:09:59 UTC
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 |