lkml.org 
[lkml]   [1998]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: IPv4: ssh failure, local port 1023


    On Tue, 1 Dec 1998, Geert Uytterhoeven wrote:

    > Date: Tue, 1 Dec 1998 19:20:03 +0100 (CET)
    > From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
    > To: Linux kernel <linux-kernel@vger.rutgers.edu>
    > Subject: IPv4: ssh failure, local port 1023
    >
    >
    > Sometimes I have problems using ssh to log in. The ssh connection just doesn't
    > seem to succeed. Using the `-v' option, the last line it prints is
    >
    > Allocated local port 1023
    >
    > If I CTRL-C and retry, it fails again (reproducible). However, if I retry
    > without breaking the first attempt, ssh gets allocated a different local port
    > number and the connection succeeds.
    >
    > The sshd runs on a Pentium with 2.0.35, ssh client runs on a 68040 with
    > 2.1.130.
    >
    I have also had this problem quite a few times.
    I cannot explain exactly how this happens, but the patterns seems to be as
    follows:
    netstat -a on a destination host (where sshd is run) shows that
    there is a connection from client machine with port number, say 1023,
    which is not quite finished (on FreeBSD mchine netstat reports it as
    having state of TIME_WAIT)
    On the client machine netstat -a shows a connection from the same 1023
    port in state SYN_SENT;
    Unfortunately I cannot find an easy way to produce this on purpose.

    > But I've been seeing this on different types of machines, running both
    > Linux/m68k and Linux/ia32, with both 2.0.x and 2.1.x kernels, since more than a
    > year. There seems to be one common thing in the failures: the allocation of
    > the local port 1023. It doesn't always fail if the local port is 1023, but if
    > it fails, it's always 1023.
    >
    This would depend on number of ssh sessions you are running on your
    machine? Strange ...

    > Needless to say, this is hard to track. Just when I wanted to start using
    > tcpdump, I couldn't reproduce the problem anymore :-(
    >
    What about disconnecting network cable (or modifying routing tables)
    while some output is going from remote machine and then killing
    ssh session on client and starting another one?

    > Could this be related to a (possible) bug in the m68k IPv4 checksum code?
    > But then, the first time I saw the problem, it was between two ia32 boxes
    > running 2.0.x, more than one year ago.
    >
    > Anyone with a clue? Thanks!
    >
    > Greetings,
    >
    > Geert
    >
    > --
    > Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
    > Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
    > Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
    >
    It was perhaps not much help,

    just wanted to share my experiences.

    Best regards,

    Wojtek
    Wojtek.Pilorz@bdk.pl


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:0.021 / U:149.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site