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 4/5)
debug3: channel 0: close_fds r 4 w 5 e 6 Read from remote host 192.168.1.40: Connection reset by peer Connection to 192.168.1.40 closed. debug1: Transferred: stdin 0, stdout 0, stderr 98 bytes in 684.3 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1
So its getting killed from somewhere, maybe the machine he is connecting to. It just seems weird because it doesn't kill my connections...
Thanks, Jim
On Feb 3, 2005, at 11:46 AM, Jim Beard wrote:
Neat. The -vvv option seems like it might help shed some light on the situation, at least as long as he uses a client that allows it. He is working from a windows workstation.
There is no NAT between the server and client. It's a rather small LAN, I think there is a hub and two switches between the machines...
Jim
On Feb 3, 2005, at 10:43 AM, larry price wrote:
You can connect using ssh -vvv [EMAIL PROTECTED]
and see all the debug messages ssh will give you
If there is a NAT box between the two machines you will occasionally see connections terminating on idle, the solution for that is to make sure that both the client and the server are issuing keepalive packets more frequently than the NAT buffer expires.
If you were seeing some sort of network level issue the affected workstation would have other problems as well. (unable to see most of the network, etc.)
On Thu, 3 Feb 2005 10:24:30 -0800, Jim Beard <[EMAIL PROTECTED]> wrote:One person in our office is experiencing some mysterious SSH connection
problems. When they connect to a specific server their connection dies
frequently. No one else on the LAN has experienced this. Network
cables have been tested and changed, and there doesn't seem to be a
problem. Other users branching off of the closest hub to him do not
experience the problem. Anyone have any idea what might be going on?
Or how to determine what might be happening? Would an IP conflict
somewhere cause any of this?
Jim Beard counterclaim.com, Inc http://www.counterclaim.com http://openefm.sourceforge.net (800) 264-8145
_______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
-- http://Zoneverte.org -- information explained Do you know what your IT infrastructure does? _______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
Jim Beard counterclaim.com, Inc http://www.counterclaim.com http://openefm.sourceforge.net (800) 264-8145
_______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
Jim Beard counterclaim.com, Inc http://www.counterclaim.com http://openefm.sourceforge.net (800) 264-8145
_______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
