Henry Ludemann wrote:
> function conn->waitfor is set to 0 after switching to the SSH_STOP
> state.

Attached is a really nasty patch to show a possible cause of the
problem. At the end of handling the SSH_SFTP_UPLOAD_INIT state in
ssh_statemach_act, it stores the original 'keepon' in
sshc->orig_waitfor; this orig_waitfor has the 'write' set, as it is
ready to send (set in the earlier call to Curl_setup_transfer).

As the ssh has finished it's current traffic, rc is not
LIBSSH2_ERROR_EAGAIN, so '*block' is FALSE. Once the function returns
to ssh_multi_statemach, it calls ssh_block2waitfor. As 'block' is
false, it sets conn->waitfor to 0. Once it returns back up to
multi_runsingle, it changes to the 'do_done' state, and upon returning
back up to multi_socket it notices the state has changed when calling
'singlesocket'. This calls down into ssh_perform_getsock, where as
conn->waitfor is 0 (as set earlier in ssh_block2waitfor), it returns
GETSOCK_BLANK. This removes the socket from the list of sockets to
poll, effectively hanging the transfer.

My nasty test hack was to force the setting of waitfor to
origin_waitfor in ssh_statemach_act after SSH_SFTP_UPLOAD_INIT. This
means the socket state is correctly set to poll for writes, and allows
the sftp to successfully complete.

I'm not sure what the proper fix is; I'll keep investigating the code
to try and figure out whose responsibility it is to ensure the socket
is set to poll for writes after SSH_SFTP_UPLOAD_INIT. Any clues will
be gratefully accepted.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html