Bug 131961

Summary: ssh client connections to the development box hang sporatically
Product: [Fedora] Fedora Reporter: Jef Spaleta <jspaleta>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dougm
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-10 03:17:05 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jef Spaleta 2004-09-07 10:20:44 EDT
Description of problem:
remotely connecting the development test box on my lan using ssh
client from fc2. eventually the ssh connection will appear to hang and
will not return back the command prompt.  The example I love doing as
a test is repeated use of rpm -qa because it has lots of output. The
remote session to the development box will hang, but i can't predict
exactly which iteration makes it hang so its somewhat sporatic and not
re-producible on demand. I run the same test locally from a terminal
on the development box and i can't produce a hang situation. 

Full disclosure time, my home network uses an fc2 based
firewall/port-forwarder so I can't naively rule out that its the
firewall/port-forwarder screwing up the client connection.
I do have another fc2 box on then lan, and i've repeated the same rpm
-qa  tests connecting to it remotely but I can not recreate the
problem. The only box behind the firewall/port-forwarder exhibiting
the problems is the development box. I've actually been seeing this
problem for a couple of weeks now, but I wanted to make sure the
problem was isolated to the development box before reporting it.

If you can point me to specific logging information to look at or turn
on so I can narrow down the problem.  I know the
firewall/port-forwarder box complicates the troubleshooting of this
problem, but i am loath to expose the development box to the public
network. If there are things I can try and examine without slapping
this box on the public network, I'd appreciate some pointers.


Version-Release number of selected component (if applicable):
openssh-3.9p1-3

How reproducible:
I see it at least once a day when remotely connected into the
development box. But I can not reproduce the problem on demand.
It seems to be related to commands that have lots of output to stdout.
a long file cat or rpm -qa   or using yum. 

Steps to Reproduce:
1. connect remotely via ssh
2. let the connection idle for an hour 
3. run a command a few times that scrolls lots of output
4. watch the output hang up. and notice that there are no related
active jobs in top on the remote machine
Comment 1 Doug Morton 2004-10-26 21:04:31 EDT
I have run into a very similar problem.  I have a "full install" FC2
x86_64 updated automatically by yum.  

My current softwareoftware:
kernel-2.6.8-1.521
openssh-3.9p1-1fc2 (it also happens with the standard FC2 version
installed via yum: openssh-3.6.1)

I connect to a remote server, type 'ls' a few times and ssh appears to
hang in the middle of output.  This occurrs when I connect with two
different server machines (one running RHL 7.2 kernel-2.4.7-10 with
openssh-2.9p2, the other running kernel-2.4.20-8 with openssh-3.7.1p1).

How reproducible?  It is random but not too hard to elicit.  Typing
'ls' a few times will usually trigger it.  Commands with lots of
output seem to make it more likely to happen.
Comment 2 Doug Morton 2004-10-26 22:10:18 EDT
After reading bug report 133884, I tried rolling back to
kernel-2.6.6-1.435 and the hang up problem vanished.
Comment 3 Tomas Mraz 2005-02-09 08:52:36 EST
Does it still happen with current kernel?
Comment 4 Jef Spaleta 2005-02-09 15:54:21 EST
running the fc3 updates-testing kernel 2.6.10-1.762_FC3smp
and I can't seem to produce this, been trying sporatically all day.

-jef
Comment 5 Tomas Mraz 2005-02-10 03:17:05 EST
Hmm... so let's say this fixed with current kernels.