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

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

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