RE: delayed_close always activated in channel_rcv_close when exiting an ssh shell session

["Murphy, Gearoid P" <gearoid.murphy@xxxxxx>]

Hi Aris

Sorry for the delay in replying.

I am not using the callback interface, is this the recommended approach?.

The sequence as I see it is this:

I type exit in the ssh client. The remote ssh server sends a channel close packet.  The ssh client processes the packet in channel_rcv_close  and sets the 'delayed_close' flag because of data on the stdout buffer, additionally, it sets the 'remote_eof' flag on the channel. The ssh client calls 'ssh_channel_poll' and is returned an SSH_EOF error code, which tells it that the connection is terminated. The SSH_EOF error code is returned from 'ssh_channel_poll' function after checking the value of the 'remote_eof' flag. To the best of my current awareness, the 'delayed_close' flag is not used.

Is that sequence correct from your perspective?, I will try to figure out why the 'channel_rcv_close' function detects data on stdout, as I don't think there should be any there.

Thanks
 - Gearoid
________________________________________
From: Aris Adamantiadis [aris@xxxxxxxxxxxx]
Sent: 17 June 2011 18:18
To: libssh@xxxxxxxxxx
Subject: Re: delayed_close always activated in channel_rcv_close when exiting an ssh shell session

Hi Geraoid,

The normal behaviour of delayed_close it to signal the close of the
channel after the last byte has been read (hence receiving SSH_EOF).
doing otherwise is likely to disrupt applications that would receive
the close before the EOF and would skip the end of the stream.
Now, there may be an implementation error that doesn't call the
rcv_close callback when last bytes have been read. Are you using the
callback interface ?

Aris

Le 17/06/11 18:33, Murphy, Gearoid P a écrit :
> Hi
>
> I recently completed a prototype x509 ssh client built on top of libssh for the Windows command prompt. It consists of a basic event loop which checks for data off stdin and the ssh shell channel. It sleeps in intervals of 20 milliseconds and loops as long as the channel is not closed. Other than the limited terminal capabilities of the windows console, it works great. The only problem I encounter is on exit.
>
> When I type 'exit', the remote ssh server shuts down the channel and waits for my libssh client to do likewise. What I find is that when the channel close packet is recv'd, the function "channel_rcv_close" always places the channel in a "delayed_close" state because it detects data in the channel stdout buffer. My initial understanding was that the channel state would be updated once the data has been transmitted but this is not so. Currently, I can only detect if the channel has closed when the 'ssh_channel_poll' function returns an SSH_EOF.
>
> Is this a bug or a feature? :), any insight is appreciated.
>
> - Gearoid
>