On Friday 21 of August 2009 00:25:54 Daniel Stenberg wrote:
> 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"
As far as I can tell this works properly.
> (EAGAIN) and store that as a waitfor bitmask, and then
> ssh_perform_getsock() uses that for the multi interface.
I spotted this, though didn't test with the multi interface.
> For the easy interface in ssh_easy_statemach(), libcurl uses
This is not the place where libcurl is looping. ssh_easy_statemach() does not
run during the transfer at all. It is called only two times before the upload
is initiated. That's why I placed the workaround to Curl_sftp_send.
The looping situation looks following:
#1 sftp_packet_read (sftp=0x62b880) at sftp.c:176
#2 sftp_packet_require (sftp=0x62b880, packet_type=101 'e', request_id=2,
data=0x7fffffffd8a8, data_len=0x7fffffffd8b0)
at sftp.c:310
#3 sftp_write (handle=0x62ca70, buffer=0x61a269 "\353H\220\20\216м",
count=16384) at sftp.c:1486
#4 libssh2_sftp_write (hnd=0x62ca70, buffer=0x61a269 "\353H\220\20\216м",
count=16384) at sftp.c:1521
#5 Curl_sftp_send (conn=0x6202c0, sockindex=0, mem=0x61a269, len=16384) at
ssh.c:2753
#6 Curl_write (conn=0x6202c0, sockfd=10, mem=0x61a269, len=16384,
written=0x7fffffffda18) at sendf.c:287
#7 readwrite_upload (data=0x615ab0, conn=0x6202c0, k=0x615ad8,
didwhat=0x7fffffffda98) at transfer.c:1589
#8 Curl_readwrite (conn=0x6202c0, done=0x7fffffffdaff) at transfer.c:1692
#9 Transfer (conn=0x6202c0) at transfer.c:1953
#10 Curl_perform (data=0x615ab0) at transfer.c:2575
#11 curl_easy_perform (curl=0x615ab0) at easy.c:557
The command was:
curl -T ~/vm/rawhide.img -u xdudka00 --verbose sftp://sorento/~/
> 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?
Sure, the content is the same and seems ok to me, but it differs from
conn->data->req.keepon when looping.
Kamil
