On Thu, 20 Aug 2009, Kamil Dudka wrote:

> I don't think it's a libssh2 bug. I've debugged it for a while and it seems
> libssh2 is returning correct transfer direction info. However curl is not
> willing to use the value.
>
> libcurl saves the direction properly to conn->proto.sshc.waitfor, but the
> variable is not accessed during transfer at all. The common layer
> (transfer.c) then expects an outgoing transfer during upload while libssh2
> is waiting for ACK (incoming transfer).

Really? What about ssh_block2waitfor() and ssh_perform_getsock() in lib/ssh.c?

ssh_block2waitfor() is supposed to figure out the reason for a "block"
(EAGAIN) and store that as a waitfor bitmask, and then ssh_perform_getsock()
uses that for the multi interface.

For the easy interface in ssh_easy_statemach(), libcurl uses
libssh2_session_block_directions() directly to figure out what to wait for.
Quite possibly that should rather use the 'waitfor' variable instead. Can you
compare the results from that libssh2_session_block_directions() call with the
contents of the waitfor variable to see if you can detect deviances during
transfer?

> The attached patch fixes the problem, but I am not going to apply it as it's
> more likely a workaround than a fix.

Right, since it will make the multi interface less non-blocking it isn't a
suitable.

> Note that it doesn't loop with SCP upload, but only with SFTP upload for me.

Not too surprising really, SFTP is doing a lot more back-and-forth sending of
packets during a transfer than SCP so SFTP is more likely to end up in a
situation where it blocks in the "reverse" direction (like you're downloading
but get EAGAIN on the send() or vice versa).

-- 
  / daniel.haxx.se