openssh unix dev - Mar 2008 - ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768"

Dear openssh developers,

Sorry to bother you with this, but I am stumped!

ssh client version:
OpenSSH_3.9p1 NCSA_GSSAPI_3.5 GSI, OpenSSL 0.9.7d 17 Mar 2004

sshd server version:
OpenSSH_4.6p1-hpn12v17 NCSA_GSSAPI_GPT_4.0 GSI, OpenSSL 0.9.7d 17 Mar 2004

The client/server interaction hangs just at the very end, after 
authentication is complete.  Here are a few lines of ssh -v -v -v output:

------------------------------------------------------------
...
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

[HANGS HERE FOR A COUPLE OF MINUTES! Then after an agonizing wait...]

debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
   #0 client-session (t4 r0 i0/0 o0/0 fd 5/7 cfd -1)

debug3: channel 0: close_fds r 5 w 7 e 8 c -1
Read from remote host XXX.XXX.uwm.edu: Operation timed out
------------------------------------------------------------


This bug has appeared on a stable set of systems that have worked well for 
quite some time. The only thing that has changed is that I am in a hotel 
room with some new ISP (in a few hours I'll try from a different 
location). We have a number of hosts set up the same way, and I can not 
log into any of them, so it's probably not machine misconfiguration on the 
server side.  And the client works fine with a different set of hosts! 
So it's probably not machine misconfiguration on the client side either.

Only thing I have checked is that I've dropped my MTU to 576 thinking that 
there might be some packet fragmentation issues with the hotel's NAT box 
but that didn't help.

PS: Thanks for openssh.  We wouldn't be able to work without it!

Cheers,
 	Bruce Allen

On Sat, Mar 15, 2008 at 04:27:09AM -0600, Bruce Allen
wrote:
> So it's probably not machine misconfiguration on the client side
either.
Do you know if your own hosts require correct reverse DNS records?

Maybe the hotel ISP doesn't have names set up and you're not being
let in because of that - while other hosts with less strict
requirements allow you access.


//Peter