Re: ssh_connect issue "Couldn't apply options"

2019-04-09 Thread Karlen Abrahamyan
Oh Thank you I solved the problem. The issue was the following. I use libssh in Windows, and in 7.2 SSH_OPTIONS_SSH_DIR was automatically set by default with path something like this "C:/Users/my_user". This is the path where .ssh folder would be created with known_hosts file inside. In

[PATCH] Don't send EOF on channel more than once

2019-04-09 Thread g4-lisz
Attached you find a patch for channels.c which prevents sending EOF on a channel more then once. Please comment. Till >From f8651e1831cf5273a3de2d22e2f4d7edf0fb457a Mon Sep 17 00:00:00 2001 From: Till Wimmer Date: Tue, 9 Apr 2019 15:57:03 +0200 Subject: [PATCH] Don't send EOF on channel more

[SFTP] Infinite loop after SSH_CHANNEL_FAILURE received in incorrect state 0

2019-04-09 Thread Yanis Kurganov
I've got the following error on Windows -> libssh SFTP -> AIX 6.1 Unfortunately, I have no access for this system and can't debug libssh Both 0.7.7 and 0.8.7 Full log attached ssh_packet_channel_success: Received SSH_CHANNEL_SUCCESS on channel (558:1) ssh_packet_process: Dispatching handler for

Re: [patch]: Stop connector socket-to-channel EOF flooding

2019-04-09 Thread Tilo Eckert
Am 09.04.2019 um 12:39 schrieb g4-l...@tonarchiv.ch: >> check whether you already sent it before: channel->local_eof != 0 > BTW channel properties are not exposed to client code. So maybe this > check should be added directly to channel_send_eof()? Yes, I think so, too. It does not really make

Re: ssh_connect issue "Couldn't apply options"

2019-04-09 Thread g4-lisz
On 08.04.19 15:31, Karlen Abrahamyan wrote: > Hi. I have previously used libssh version 0.7.2 on Windows and it > worked just fine, wanted to switch to new version 0.8.7 but I keep > getting "Couldn't apply options" error message on ssh_connect func > call and cant find any help in other threads.

[patch] ssh_options_set annotations: SSH_OPTIONS_PORT is pointer to int

2019-04-09 Thread g4-lisz
Hi there, a small patch to correct the ssh_options_set() param annotation for SSH_OPTIONS_PORT. Cheers, Till >From 1673002767e2231b7633fbd95671312685e3ed34 Mon Sep 17 00:00:00 2001 From: Till Wimmer Date: Tue, 9 Apr 2019 12:56:39 +0200 Subject: [PATCH] ssh_options_set annotations:

Re: How to set up timeout

2019-04-09 Thread Franciszek Juras
I repeat the question, as it's very important to me. How can I set timeout, after which functions like ssh_channel_request_exec or sftp_open fail if connection was lost? I use version 0.8.6. FJ niedz., 7 kwi 2019 o 09:42 Andreas Schneider napisał(a): > On Saturday, 6 April 2019 19:27:03 CEST

Re: [patch]: Stop connector socket-to-channel EOF flooding

2019-04-09 Thread g4-lisz
On 09.04.19 11:50, g4-l...@tonarchiv.ch wrote: > check whether you already sent it before: channel->local_eof != 0 BTW channel properties are not exposed to client code. So maybe this check should be added directly to channel_send_eof()?

Re: [patch]: Stop connector socket-to-channel EOF flooding

2019-04-09 Thread g4-lisz
On 09.04.19 11:50, g4-l...@tonarchiv.ch wrote: > On 09.04.19 10:03, Tilo Eckert wrote: >> Your callback sends an EOF for every received EOF from the server. If >> your server does the same, you end up with EOF ping pong. You might want >> to check whether you already sent it before:

Re: [patch]: Stop connector socket-to-channel EOF flooding

2019-04-09 Thread g4-lisz
On 09.04.19 10:03, Tilo Eckert wrote: > Am 08.04.2019 um 20:54 schrieb g4-l...@tonarchiv.ch: >>> I'm using connectors for a direct-tcp client. So this creates two >>> connectors FD in --> channel out and vice versa. >>> >>> Now when the socket forwarding peer (not the ssh server) closes the >>>

Could not write as much data as expected

2019-04-09 Thread Yanis Kurganov
Hello! I've got the following message: sftp_write: Could not write as much data as expected Looks like it's here: https://git.libssh.org/projects/libssh.git/tree/src/sftp.c?h=stable-0.8#n2060 And also I found this patch:

Re: [patch]: Stop connector socket-to-channel EOF flooding

2019-04-09 Thread Tilo Eckert
Am 08.04.2019 um 20:54 schrieb g4-l...@tonarchiv.ch: >> I'm using connectors for a direct-tcp client. So this creates two >> connectors FD in --> channel out and vice versa. >> >> Now when the socket forwarding peer (not the ssh server) closes the >> connection, i.e. reading on the socket returns