Messages in this thread | | | Date | Thu, 18 Jun 1998 18:12:42 -0700 | From | Joshua Hill <> | Subject | Re: 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
| |