How to trouble-shoot a hanging scp? - SSH

This is a discussion on How to trouble-shoot a hanging scp? - SSH ; I'm trying to use scp for copying files from SuSE 9.1 (running under VMware Workstation on Windows) to a remote host, also running SuSE 9.1. Both installations are at 4.1p1-11.16 (the remote host started out at 3.8p1-37.17, with the same ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: How to trouble-shoot a hanging scp?

  1. How to trouble-shoot a hanging scp?

    I'm trying to use scp for copying files from SuSE 9.1 (running under
    VMware Workstation on Windows) to a remote host, also running SuSE 9.1.
    Both installations are at 4.1p1-11.16 (the remote host started out at
    3.8p1-37.17, with the same problems).

    To avoid ssh disconnects due to inactivity, I set

    ClientAliveInterval 60

    in sshd_config; everything else is default. At this point I'm going from
    root to root, using public key authorization.

    ssh works just fine, both from the command line as well as via Midnight
    Commander's shell link. Either way I can copy files from remote to
    local, but when I try to copy from local to remote, then scp and mc's
    fish usually hang and time out after a few minutes. Every now and then a
    small file may go through, but usually not.

    BTW, with Putty PSCP on the local Windows computer everything works just
    fine both ways.

    I've spent all day today to try to find a solution, and now I'm becoming
    desperate... Here are the outputs from scp -vvv and from sshd
    (LogLevel DEBUG3), first last part of the scp log of successfully
    sending a short 32-bit file:

    debug1: Sending command: scp -v -t 32-byte-file
    debug2: channel 0: request exec confirm 0
    debug2: callback done
    debug2: channel 0: open confirm rwindow 0 rmax 32768
    debug2: channel 0: rcvd adjust 131072
    Sending file modes: C0755 32 32-byte-file
    debug2: channel 0: rcvd ext data 23
    Sink: C0755 32 32-byte-file
    debug2: channel 0: written 23 to efd 11
    debug2: channel 0: read<=0 rfd 8 len 0
    debug2: channel 0: read failed
    debug2: channel 0: close_read
    debug2: channel 0: input open -> drain
    debug2: channel 0: ibuf empty
    debug2: channel 0: send eof
    debug2: channel 0: input drain -> closed
    debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
    debug2: channel 0: rcvd eof
    debug2: channel 0: output open -> drain
    debug2: channel 0: obuf empty
    debug2: channel 0: close_write
    debug2: channel 0: output drain -> closed
    debug2: channel 0: rcvd close
    debug3: channel 0: will not send data after close
    debug2: channel 0: almost dead
    debug2: channel 0: gc: notify user
    debug2: channel 0: gc: user detached
    debug2: channel 0: send close
    debug2: channel 0: is dead
    debug2: channel 0: garbage collecting
    debug1: channel 0: free: client-session, nchannels 1
    debug3: channel 0: status: The following connections are open:
    #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
    debug3: channel 0: close_fds r -1 w -1 e 11 c -1
    debug1: fd 0 clearing O_NONBLOCK
    debug1: fd 1 clearing O_NONBLOCK
    debug1: fd 2 clearing O_NONBLOCK
    debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.6 seconds
    debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
    debug1: Exit status 0


    Here's the failed attempt to send a ~20K-byte file:

    debug1: Sending command: scp -v -t 20K-byte-file
    debug2: channel 0: request exec confirm 0
    debug2: callback done
    debug2: channel 0: open confirm rwindow 0 rmax 32768
    debug2: channel 0: rcvd adjust 131072
    Sending file modes: C0644 22479 20K-byte-file
    debug2: channel 0: rcvd ext data 28
    Sink: C0644 22479 20K-byte-file
    debug2: channel 0: written 28 to efd 11
    debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com
    reply 1
    debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com
    reply 1
    debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com
    reply 1
    Received disconnect from <>: 2: Timeout, your session not
    responding.
    lost connection

    The three client_input_channel_req lines correspond to the
    ClientActiveInterval 60 setting, coming in at 1 minute intervals.


    From the sshd side, there's a similar picture: the initial setup is the
    same, and here's where it starts to differ -- first the successful
    transfer with the tiny file:

    20:50:16: debug2: channel 0: read 23 from efd 9
    20:50:16: debug2: channel 0: rwin 131070 elen 23 euse 1
    20:50:16: debug2: channel 0: sent ext data 23
    20:50:16: debug2: channel 0: rcvd eof
    20:50:16: debug2: channel 0: output open -> drain
    20:50:16: debug2: channel 0: obuf empty
    20:50:16: debug2: channel 0: close_write
    20:50:16: debug2: channel 0: output drain -> closed
    20:50:16: debug1: Received SIGCHLD.
    20:50:16: debug1: session_by_pid: pid 14381
    20:50:16: debug1: session_exit_message: session 0 channel 0 pid 14381
    20:50:16: debug2: channel 0: request exit-status confirm 0
    20:50:16: debug1: session_exit_message: release channel 0
    20:50:16: debug1: session_close: session 0 pid 14381
    20:50:16: debug2: channel 0: read<=0 rfd 7 len 0
    20:50:16: debug2: channel 0: read failed
    20:50:16: debug2: channel 0: close_read
    20:50:16: debug2: channel 0: input open -> drain
    20:50:16: debug2: channel 0: read 0 from efd 9
    20:50:16: debug2: channel 0: closing read-efd 9
    20:50:16: debug2: channel 0: ibuf empty
    20:50:16: debug2: channel 0: send eof
    20:50:16: debug2: channel 0: input drain -> closed
    20:50:16: debug2: channel 0: send close
    20:50:16: debug2: notify_done: reading
    20:50:16: debug3: channel 0: will not send data after close
    20:50:16: debug2: channel 0: rcvd close
    20:50:16: debug3: channel 0: will not send data after close
    20:50:16: debug2: channel 0: is dead
    20:50:16: debug2: channel 0: garbage collecting
    20:50:16: debug1: channel 0: free: server-session, nchannels 1
    20:50:16: debug3: channel 0: status: The following connections are
    open:\r\n #0 server-session (t4 r0 i3/0 o3/0 fd 7/7 cfd -1)\r\n
    20:50:16: debug3: channel 0: close_fds r 7 w 7 e -1 c -1
    20:50:16: Connection closed by 83.78.50.109
    20:50:16: debug1: do_cleanup
    20:50:16: debug1: PAM: cleanup
    20:50:16: debug3: PAM: sshpam_thread_cleanup entering
    20:50:16: Closing connection to 83.78.50.109
    20:50:16: debug1: PAM: cleanup


    .... then the failed transfer:

    20:54:11: debug2: channel 0: read 28 from efd 9
    20:54:11: debug2: channel 0: rwin 131071 elen 28 euse 1
    20:54:11: debug2: channel 0: sent ext data 28
    20:55:11: debug2: channel 0: request keepalive@openssh.com confirm 1
    20:56:11: debug2: channel 0: request keepalive@openssh.com confirm 1
    20:57:11: debug2: channel 0: request keepalive@openssh.com confirm 1
    20:58:11: Disconnecting: Timeout, your session not responding.
    20:58:11: debug3: channel 0: close_fds r 7 w 7 e 9 c -1
    20:58:11: debug1: do_cleanup
    20:58:11: debug1: PAM: cleanup
    20:58:11: debug3: PAM: sshpam_thread_cleanup entering

    After the first three lines it just stops, without any error message,
    then the three keep-alive exchanges in one minute intervals, and then
    the timeout.

    Please help!

    Hans

  2. Re: How to trouble-shoot a hanging scp?

    Hans Salvisberg writes:

    > I'm trying to use scp for copying files from SuSE 9.1 (running under
    > VMware Workstation on Windows) to a remote host, also running SuSE 9.1.
    > Both installations are at 4.1p1-11.16 (the remote host started out at
    > 3.8p1-37.17, with the same problems).


    Test the network for packet loss in both directions. Last time I had
    troubles lke this it ended up being a finicky NIC going bad. Packet
    loss was the only other symptom we could find.



    --
    Todd H.
    http://www.toddh.net/

  3. Re: How to trouble-shoot a hanging scp?

    Todd H. wrote:
    > Hans Salvisberg writes:
    >
    >> I'm trying to use scp for copying files from SuSE 9.1 (running under
    >> VMware Workstation on Windows) to a remote host, also running SuSE 9.1.
    >> Both installations are at 4.1p1-11.16 (the remote host started out at
    >> 3.8p1-37.17, with the same problems).

    >
    > Test the network for packet loss in both directions. Last time I had
    > troubles lke this it ended up being a finicky NIC going bad. Packet
    > loss was the only other symptom we could find.


    Thank you for your reply! I don't have any dedicated equipment, but a
    ping flood (4000 packets) didn't show any packet loss.

    Hans


+ Reply to Thread