Page MenuHomePhabricator

SSH_OPTIONS_TIMEOUT not used in non-blocking sockets
Closed, ResolvedPublic


I can not figure out if this is a bug or a feture (but i can not find any documentation saying that this is normal behavior), i'm trying to set a timeout value for the connect function on a non-blocking session.

i'm setting the options as:
long timeout=1;
sshoptionsset(session, SSHOPTIONSTIMEOUT, &timeout);

the timeout for the connect call becomes more like 10 seconds then 1.

In the misc.c in the function sshtimeoutelapsed() i can see that if the value timeout that is passed to that function == 0 there is no timeout, and if the socket is non blocking we are calling that function with the option SSHTIMEOUTNONBLOCKING which is defined as 0 in the include/libssh/session.h

So from what i can see, the option i sent in with sshoptionsset is never used when i use non-blocking sockets.

Event Timeline

migration created this object with visibility "Restricted Project (Project)".
migration created this object with edit policy "Restricted Project (Project)".
asn changed the visibility from "Restricted Project (Project)" to "Public (No Login Required)".Sep 4 2018, 9:15 PM

This is related to this issue discussed here:

Because SSH_OPTIONS_TIMEOUT is not used in the ssh_channel_read function, if there is a network disconnect, then it will block infinitely. I am consistently seeing this issue with network disconnects during a download for a blocking socket.

asn added a subscriber: asn.Nov 13 2018, 12:47 PM

Did you test this with libssh >= 0.8.3. Because I fixed some things.

I have tested with 0.8.4. It looks like SSH_TIMEOUT_DEFAULT is always -1 even if I set SSH_OPTIONS_TIMEOUT.

I am actually not seeing SSH_OPTIONS_TIMEOUT being used in many places at all. My thinking was that SSH_OPTIONS_TIMEOUT, if set, should be used in every ssh/sftp function that takes in an optional timeout value.

I am seeing this issue with sftp_read(). The sftp_read() function call was getting hung when there was a disconnect. I traced it to ssh_channel_read() which isn't using the user defined timeout.

See for two patches that address part of this problem.