Re: last-call issues..

[nisse%lysator.liu.se@localhost (Niels Möller)]

Bill Sommerfeld <sommerfeld%east.sun.com@localhost> writes:

>  - Niels M. pointed out that there are current interop problems
> between OpenSSH and lsh relating to channel EOF and channel close;
> lshd attempts graceful shutdown but doesn't ever get an EOF from
> OpenSSH's client.  

> Resolution: the "forward output until EOF, then close channel"
> 	behavior should be documented as an implementors note.
> 	(need volunteer to supply text)

I've changed the lsh/lshd behaviour now, and I wrote up a summary in
http://www.lsaytor.liu.se/~nisse/lsh/doc/NOTES, appended below. This
description is a little lsh specific, but perhaps it could be edited
to fit in the draft?

>  - Wei Dai requested an extension to allow for forwarding of a
> server-chosen port ("pick a port, forward it to me, and tell me what
> it is").
> 
> Resolution: Unresolved.  Do we need a new opcode for this or can we
> overload the meaning of "forward port zero"?

Even if the "tcpip-forward" global request, with zero port, is reused
for this, a new reply message is still needed.

/Niels

CLOSING CHANNELS

The right conditions for closing a channel, and in particular a
session, are even more subtle. The basic rules are:

1. When SSH_MSG_CHANNEL_CLOSE is both sent and received, the channel
   is killed. This is unconditionally required by the spec.

2. When SSH_MSG_CHANNEL_EOF is both sent and received,
   SSH_MSG_CHANNEL_CLOSE is sent. This is a rule with a few
   exceptions, controlled by the CHANNEL_CLOSE_AT_EOF flag, see below.

These two rules are sufficient for most channel types.

When looking at the channel close logic for session channels, one has
to consider these three events that may occur in arbitrary order:

 * The client sends SSH_MSG_CHANNEL_EOF on the channel.

 * The server sends SSH_MSG_CHANNEL_EOF on the channel (this happens
   when there are no more processes which have the files the server
   has opened for stdout or stderr open).

 * The child process created by the server dies. An exit-status or
   exit-signal message is sent to the client.

Previous versions of lshd handled these conditions as follows: It
closed the channel according to rule (2) above, no exceptions. This
causes other clients to hang, because they never send any
SSH_MSG_CHANNEL_EOF. Using lsh did work right, only because it
responded to the exit-status message with a SSH_MSG_CHANNEL_EOF.

But the server can't rely on clients sending SSH_MSG_CHANNEL_EOF.
Instead, it must treat process death in much the same way as reception
of SSH_MSG_CHANNEL_EOF. The channel is closed once the server has both
encountered EOF on the process' stdout and stderr (resulting in a
SSH_MSG_CHANNEL_EOF), and sent an exit-status or exit-signal message.

As a further complication, rule (2) must be relaxed, because otherwise
the channel may get closed before the exit-status message is sent.