[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Ok, the server sends back a final string saying "logout" on the stdout buffer, that would explain why it goes into the delayed_close state, my bad.

The only aspect I'm uncertain about is the close state of the channel after this buffer has been exhausted. Should libssh update set the channel to a closed state once it has removed all the data from a buffer and the "delay_close" flag is enabled?, It's not a big deal one way or the other, I just to be sure I'm in accordance with the intended design.

 - Gearoid
From: Murphy, Gearoid P
Sent: 20 June 2011 16:26
To: libssh@xxxxxxxxxx
Subject: RE: delayed_close always activated in channel_rcv_close when exiting an ssh shell session

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.

 - 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 ?


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

Archive administrator: postmaster@lists.cynapses.org