Hi, and thanks,

indeed, the bad execution wasn't caused by this warning.
I started debugging en found some strange behavior. The results are
different when i run a 'release' build, or a build with the debug flags
(CURLDEBUG, CURL_LIBSSH2_DEBUG and LIBSSH2DEBUG) turned on.

When these flags are turned on, my transfers work just fine !!

A memory of en earlier experience came up. The trace functions might be
slowing down the process, just enough to receive some additional network
data.

It seems this is the case here as well.

with CURL_LIBSSH2_DEBUG turned off, something was preventing me from
logging in properly to my sftp server:

..SFTP 0xeadca8 state change from SSH_STOP to SSH_S_STARTUP
..SFTP 0xeadca8 state change from SSH_S_STARTUP to SSH_AUTHLIST
..SFTP 0xeadca8 state change from SSH_AUTHLIST to SSH_SESSION_FREE
..SFTP 0xeadca8 state change from SSH_SESSION_FREE to SSH_STOP
..Closing connection #0
..Error in the SSH layer

So i added a Sleep(100) in libssh2_packet_requirev_ex() at line 1201 in
packet.c. Now logging in works fine, but i get stuck a little further:

..SFTP 0xeadca8 state change from SSH_STOP to SSH_S_STARTUP
..SFTP 0xeadca8 state change from SSH_S_STARTUP to SSH_AUTHLIST
..SSH authentication methods available: publickey,gssapi-with-mic,password
..SFTP 0xeadca8 state change from SSH_AUTHLIST to SSH_AUTH_PKEY_INIT
..SFTP 0xeadca8 state change from SSH_AUTH_PKEY_INIT to SSH_AUTH_PASS_INIT
..SFTP 0xeadca8 state change from SSH_AUTH_PASS_INIT to SSH_AUTH_PASS
..Initialized password authentication
..SFTP 0xeadca8 state change from SSH_AUTH_PASS to SSH_AUTH_DONE
..Authentication complete
..SFTP 0xeadca8 state change from SSH_AUTH_DONE to SSH_SFTP_INIT
..Failure initialising sftp session

..SFTP 0xeadca8 state change from SSH_SFTP_INIT to SSH_SESSION_FREE
..SFTP 0xeadca8 state change from SSH_SESSION_FREE to SSH_STOP
..Closing connection #0

could it be my program executes too fast ? or is there an internal LIBSSH2
timeout set too low ?

thanks
Immanuel

Daniel Stenberg wrote:

> On Tue, 18 Sep 2007, junk_at_igrspace.com wrote:
>
>> also, execution doesn't seem to go the way it should.
>
> I don't see how that warning should prevent things to work since on your
> 32
> bit system the long and int will be the same size...
>
>> what is the best way to work around this ?
>
> I think we should make sure both libcurl and libssh2 first checks for
> "__ssize_t_defined" and only do the magic if that is not set and we should
> set
> it afterwards.
>
> The __ssize_t_defined define is what glibc uses for exactly this purpose
> and I
> think it makes sense to use an already established define for this.
>
> Are you up to providing us with the necessary patches? (I'm co-admining
> the
> libssh2 project so I can take that patch as well)
>
> --
> Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
>
Received on 2007-09-18