lkml.org 
[lkml]   [1998]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ssh: connect() stalls on RedHat 5.1 / kernel 2.0.34
On Thu, Jun 18, 1998 at 12:40:38AM +0200, Ragnar Hojland Espinosa wrote:
> > Ssh version 1.2.22, 1.2.23 and 1.2.25 occasionally stall in
> > connect().
> [snip]
>
> > Has anybody else experienced anything similar?
>
> Yep.. I found out that having two sshs (1.2.20) hanging, the third one
> would always succeed.

Do you run IP Masquerading? If so, it may be the same problem that I
was seeing for a while. I had increased the timeout values for tcpfin
to a day, then a bit later I lost my modem connection while ssh'ed
to another machine. When my connection was restored (with a different
IP address), I tried to re-connect. No luck, the connection never
negotiated. I tried again. It worked. The modem lost connection again
a short time later, and again I tried to connect. It wouldn't work until
the third try.

Here's what I figured out was happening:
I would secure shell to another machine, through my IP masquerading modem
server. I lost a connection without closing my session, so the IP
masquerading server didn't consider the connection closed. When the modem
server reconnected a short time later my IP was different. I tried to
secure shell to the same machine again.

Well, I had already killed the secure shell client that had been rudely
interrupted by my ISP, so the port that the client had chosen to come from
originally was free again. When I secure shelled again, the OS gave me
the same source port. The IP Masquerading server saw the tuple
(src IP, src PORT, dst IP, dst PORT) was already active (the session hadn't
timed out due to idleness because I hadn't waited long enough), so it assumed
that the new packet was another packet for the old connection. It sent the
packet along to the server that I was talking to originally. Unfortunately
that server didn't know about a connection from my modem server's new IP, so
it ignored it.

The end result it that my outgoing session appeared to never negotiate.

My solution works because of the timing of it all. I tried to secure
shell, it failed. I tried again shortly after that, and it succeeded
because the original host port hadn't been assigned to me again. (the
OS was still unallocating it). If I had waited for the port to become
available again, I wouldn't have been able to get through.

When I realized that this was a problem, I reduced the TCPFIN timeout
for my modem server.

Josh
--
-----------------------------Joshua E. Hill-----------------------------
| Swizzle Stick... Well put. |
------------------------jehill@w6bhz.calpoly.edu------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:1.158 / U:1.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site