"Couldn't apply options" on a minimal test case console app #1
Comments
|
Have you tried other libssh binaries such as the one from vcpkg? |
|
Hi
It's a good idea and apparently from vcpkg it works without any problems
(same exact code)
I am unable to find out the root cause in ShiftMediaProject that causes it
On Thu, 27 Jun 2019 at 19:18, Matthew Oliver ***@***.***> wrote:
Have you tried other libssh binaries such as the one from vcpkg?
If its an issue with the binaries provided here then i can help but if its
an issue with libssh itself then you should try the libssh upstream
developers instead.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1?email_source=notifications&email_token=AAPQE3R567TLAROZJJLFPF3P4TR45A5CNFSM4HZPNGWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYXUK6A#issuecomment-506414456>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAPQE3UD5363GGP2VSVOSA3P4TR45ANCNFSM4HZPNGWA>
.
--
Thanks,
Noam Rathaus
|
|
There is new 0.9.0 version of libssh now available. See if that fixes your issues. |
|
helo The current version 0.10.4 still has this problem |
|
The existing sftp async read api has two problems : 1. sftp_async_read() assumes that the value of the third parameter count is same as the number of bytes requested to read in the corresponding call to sftp_async_read_begin(). But the documentation of sftp_async_read() allows the value of count parameter to be more than that requested length. If value of count parameter is more than that requested length then sftp_async_read() updates the file->offset incorrectly which leads to further read/writes occuring from incorrect offsets. The problem here is that sftp_async_read() doesn't know about the number of bytes requested to read specified in the call to sftp_async_read_begin(), and it wrongly assumes the value of its count parameter (which is actually the size of the buffer to store the read data) to be the same as the number of bytes requested to read. 2. sftp_async_read_begin() returns an uint32_t type value type casted to int as a request identifier, whereas sftp_async_read() expects an uint32_t type value as a request identifier. Due to this the user has to typecast the identifier returned by sftp_async_read_begin() from int to uint32_t and then pass it to sftp_async_read(). This type casting is cumbersome for the user and hence the approach is not user-friendly. This commit solves the above two problems by introducing a new sftp aio api. The sftp_aio_begin_*() functions in the api send an i/o request to the sftp server and provide the caller a dynamically allocated structure storing information about the sent request. Information like number of bytes requested for i/o, id of sent request etc is stored in the structure. That structure should be provided to the sftp_aio_wait_*() functions in the api which wait for the response corresponding to the request whose info is stored in the provided structure. The libssh user is supposed to handle that structure through an opaque type sftp_aio. Since the structure stores the number of bytes requested for i/o, sftp_aio_wait_*() knows about the number of bytes requested for i/o (specified in the call to sftp_aio_begin_*()) and hence updates the file->offset correctly solving problem #1 present in the existing async api. Since the structure provided by sftp_aio_begin_*() (containing the request id) is supplied to sftp_aio_wait_*(), no casting of id's needs to be done by the user solving problem #2 of the existing async api. Signed-off-by: Eshan Kelkar <[email protected]> Reviewed-by: Sahana Prasad <[email protected]> Reviewed-by: Jakub Jelen <[email protected]>
Running a console application with libssh doesn't ssh_connect, rather returns "Couldn't apply options" - which isn't very informative.
Context
I tried to run the following code:
But it returns "Couldn't apply options" error to ssh_connect(), all the ssh_options_set work (return a value of 0)
Expected Behavior
Connect to the SSH server
Actual Behavior
Returns an error
Steps to Reproduce
Your Environment
Possible Fix
:Shrug:
The text was updated successfully, but these errors were encountered: