Subject: RE: closing a channel

From: "denis bider" <[email-masked]>
Date: Fri, 22 Mar 2002 14:16:39 +0100

> > Much like a black man is still a man, and a brown
> > cow is still a cow, I would think that extended
> > data is still data - especially since data and
> > extended data consume the same window.
>
> it could be some kind of out-of-band thing.

I find it difficult to imagine how it could be out of band if it consumes
the same window.

> are WINDOW adjust messages allowed after EOF?

Good point. I would vote no, because they don't make any sense after EOF.
But I think this should be specified more clearly in the draft. Anyone?

---

From: Markus Friedl <[email-masked]>
Date: Fri, 22 Mar 2002 13:25:28 +0100

Hi, is it allowed to send an EXTENDED data message
after sending an EOF message?  Is extended data
considered channel data?

The draft says:

	3.3 Closing a Channel

	   When a party will no longer send more data to a channel, it
	   SHOULD send SSH_MSG_CHANNEL_EOF.

---

From: "denis bider" <[email-masked]>
Date: Fri, 22 Mar 2002 14:04:53 +0100

> Hi, is it allowed to send an EXTENDED data
> message after sending an EOF message?
> Is extended data considered channel data?

Much like a black man is still a man, and a brown cow is still a cow, I
would think that extended data is still data - especially since data and
extended data consume the same window. This should be no issue.

However, I think the draft should be more clear about how EOF relates to
channel requests. It doesn't say anything about whether requests and
responses can be sent after EOF has been sent.

In the current implementations, there probably isn't a channel request that
it would make sense sending after EOF has been sent. But in general, there
might be applications where this could be reasonable, e.g. if the channel
request results in only a request response and doesn't cause any data to be
sent in either direction.

Does the draft allow channel requests and responses to be sent after EOF or
not?

---

From: Markus Friedl <[email-masked]>
Date: Fri, 22 Mar 2002 14:05:38 +0100

---

From: Markus Friedl <[email-masked]>
Date: Fri, 22 Mar 2002 14:38:05 +0100

> I find it difficult to imagine how it could be out of band if it consumes

hm, I still cannot find where the draft says that it's a protocol
violation, EOF is just a hint.  You're just not allowed to send
data after CLOSE...

---

From: "denis bider" <[email-masked]>
Date: Fri, 22 Mar 2002 14:53:59 +0100

> hm, I still cannot find where the draft says that
> it's a protocol violation, EOF is just a hint.
> You're just not allowed to send data after CLOSE...

Where does the draft say that EOF is just a 'hint'? What it says is this:

  When a party will no longer send more data to
  a channel, it SHOULD send SSH_MSG_CHANNEL_EOF.

I.e.: it says that you _should_ send EOF when you will no longer send more
data. What it _doesn't_ say is that you "may" send more data after you have
sent EOF. I think the draft's implication here is that it would be
unacceptable to send more data after you have sent EOF. I find your
interpretation rather strange.

I do agree, however, that the draft should be clarified with regard to this.
I didn't think it was ambiguous, but seeing that someone like you can
interpret that section so differently from myself, it clearly requires
clarification. Just one sentence is not enough.

---

From: Markus Friedl <[email-masked]>
Date: Fri, 22 Mar 2002 15:00:09 +0100

On Fri, Mar 22, 2002 at 02:53:59PM +0100, denis bider wrote:
> I think the draft's implication here is that it would be
> unacceptable to send more data after you have sent EOF.

Well, I agree, that not more CHANNEL_DATA should be sent
after CHANNEL_EOF, but to me CHANNEL_EXTENDED_DATA is
a different channel w/o explicit EOF.

---

From: Markus Friedl <[email-masked]>
Date: Fri, 22 Mar 2002 15:05:05 +0100

> a different channel w/o explicit EOF.

a different data stream w/o explicit EOF, but I'm probably wrong :)

---

From: "denis bider" <[email-masked]>
Date: Fri, 22 Mar 2002 15:28:45 +0100

Ylonen, Kivinen, Saarinen, Rinne, Lehtinen - you are the authors of the SSH
Connection Protocol draft. What do you think? Will you augment the draft
with a more concise specification of what EOF means and what it doesn't?

Especially with regard to the following:

- Is EOF just a hint or not? (I hope it's not.)

- Does it apply to extended data or not? (I hope it does.)

- How does it relate to channel requests and responses? What about window
adjustment messages? Are any of these allowed to be sent after EOF?

Thanks,

denis

---

From: [email-masked] (Niels Möller)
Date: 22 Mar 2002 19:41:14 +0100

> after sending an EOF message?  Is extended data

I'd say extended data count as data. Sending EOF means that you won't
send either ordinary data or extended data anymore. (On the server
side, I have a counter on the session channel. When I get EOF on the
process' stdout or stderr, I decrement the counter. When it reaches
zero, I send EOF on the channel).

My reasons for this:

Ordinary data and extended data are treated as a single stream for
flow control. It would be odd to treat them differently with respect
to EOF only.

Allowing extended data after EOF means that there's no way to indicate
EOF on the extended data channel; the other end can never know that it
shouldn't expect more data. That's bad. Consider a client that wants
to wait until the server will send no more data of any kind, and then
send some final CHANNEL_REQUESTs before closing the channel.

It might be desirable to have a wider separation between stdout and
stderr data than is provided by the extended data hack. But if we want
that, the Right Way is create a separate channel for stderr, with
independent flow control and working EOF indication. One should invent
a message

  byte   CHANNEL_OPEN
  string "session-stderr"
  uint32 channel ; The session we want to attach this channel to

or something like that.

My answers to some of the other questions raised in this thread:

Can one send CHANNEL_REQUEST after EOF? I'd say yes. In particular,
the order in which my server sends CHANNEL_EOF and CHANNEL_REQUEST
"exit-status" depends on the the relative timing of i/o and the
SIGCHLD signal, and is esssentially random. 

Can one send WINDOW_ADJUST after EOF? This is an ill-posed question.
The EOF message I send and the WINDOW_ADJUST messages I send affects
different directions of the channel, and they are therefore
independent. I can send EOF as soon as the channel is created, and
then go on sending lots of WINDOW_ADJUST messages while I download a
GB or two of data.

Can I send WINDOW_ADJUST after I *received* EOF? Yes, the other
end can't know the exact sequence of events anyway. And turning it
around, what should I do if I *receive* WINDOW_ADJUST after I *sent*
EOF? I'd say such messages should be silently ignored; the other end
may well have sent the WINDOW_ADJUST before seeing my EOF.

Best regards,
/Niels

---

From: Timo J Rinne <[email-masked]>
Date: Fri, 22 Mar 2002 23:52:23 +0200

> - Is EOF just a hint or not? (I hope it's not.)

No.  It does have very clear semantics.

> - Does it apply to extended data or not? (I hope it does.)

Yes.  No more data to the channel after EOF.  At least that was the
idea when I was more involved with the drafts.  And extended data is
data too in this respect.

> adjustment messages? Are any of these allowed to be sent after EOF?

Nope, if they refer to the closed channel.

//Rinne

---

From: "denis bider" <[email-masked]>
Date: Fri, 22 Mar 2002 21:07:20 +0100

> > - How does it relate to channel requests and
> > responses? What about window adjustment messages?
> > Are any of these allowed to be sent after EOF?
>

But "after EOF" does not imply that EOF has been sent in both directions.
Presumably, the situation would be that one side has sent EOF, while the
other side continues to stream data. In this situation, is the side that has
already sent EOF allowed to send a channel request or a response to the
other side's request, or not?

I would say yes, it ought to be allowed. But I think this is something that
should be clearly stated in the specification, not something we should be
wondering about right now.

I think the specification must be amended to clarify this. I imagine that is
the whole point of having the specification in the first place.

---

From: [email-masked] (Niels Möller)
Date: 22 Mar 2002 22:30:52 +0100

> SIGCHLD signal, and is esssentially random. 

Let me provide an admittedly contrived, but I hope still illustrative,
example. Say we have a unix environment, and the server receives a
CHANNEL_REQUEST "exec" request on a session channel with the following
command line:

  "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17"

The server forks and execs (assuming the user's login shell is
/bin/sh) the subprocess

  /bin/sh -c "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17"

What my server will send to the client in this situation is

  CHANNEL_DATA "foo\n"     # The data the process sent to its stdout
  CHANNEL_EOF              # The process closed its stdout and stderr
  ... delay of about 30 seconds ...
  CHANNEL_REQUEST "exit-status" 17
  CHANNEL_CLOSE

I believe this is a reasonable use of the protocol, and it obviously
sends a CHANNEL_REQUEST long after the CHANNEL_EOF. What are the
alternatives?

* One could delay the CHANNEL_EOF until after the CHANNEL_REQUEST
  message. I think that's bad, there's no reson not to tell the client
  right away that it will get no more data on the channel.

* One could wait just a short while for the process to die, and if it
  doesn't die, just send CHANNEL_EOF and CHANNEL_CLOSE anyway.
  The client won't get any exit-status. This is ugly: For a start,
  what's a reasonable "short while"? It happens in practice that the
  server detects EOF before it gets to handle the SIGCHLD signal
  process death. I don't want a race-condition to determine whether or
  not the client gets any exit-status message (I've had such race
  conditions in the past, I hope I have fixed them by now).

* Brutally kill the process after we detect EOF, so we don't need to
  wait to send exit-status/exit-signal, or send a lying exit-status
  message.

I don't like any of these alternatives *at all*, and I believe the
behaviour described above, with CHANNEL_REQUEST "exit-status" sent a
while after CHANNEL_EOF, is the best and most natural way to report the
sequence of events to the client. Please don't ban it.

Best regards,
/Niels

---

From: "denis bider" <[email-masked]>
Date: Fri, 22 Mar 2002 23:35:21 +0100

> CHANNEL_DATA "foo\n"
> CHANNEL_EOF

This looks very reasonable. Does your server behave the same if the client
sends EOF immediately after issuing the exec request? That's what my clients
do - when issuing an exec request, they let the server know immediately that
they're not going to send any data.

I find it problematic that the specification doesn't say who is supposed to
close the session channel. Can the client rely on the server closing the
channel after the child process exits? If not, can the client rely on the
server sending an 'exit-status' message?

Since the draft's wording about 'exit-status' is that its use is only
"recommended", and since the draft doesn't say anything about the server
closing the channel when the child process terminates, my implementation
currently assumes that it cannot rely on any of that. So, preferring to be
safe than sorry, it automatically closes the channel after EOF has been both
sent and received.

But if I knew that I can rely on the server to send 'exit-status' or to
close the channel upon child process termination, I would prefer not to rush
with my own CHANNEL_CLOSE so that I can possibly catch the program's exit
code.

---

From: Wei Dai <[email-masked]>
Date: Fri, 22 Mar 2002 19:44:57 -0800

>   right away that it will get no more data on the channel.

What's the purpose of CHANNEL_EOF, anyway? I thought it was used to tell
the other side that no more data will be sent so that the other side can
feel free to close the channel whenever it finishes sending its data. If
you're going to send more information (e.g., the exit code) in the form of
a CHANNEL_REQUEST after sending CHANNEL_EOF, then how does the other side
know when it's safe to close the channel without losing information?

> with my own CHANNEL_CLOSE so that I can possibly catch the program's exit   

That's fine in the case of a shell command, but what about other types of
channels where the concept of child process termination doesn't apply?

My interpretation is that no channel data or requests should be sent after
CHANNEL_EOF, but SSH_MSG_CHANNEL_SUCCESS and SSH_MSG_CHANNEL_FAILURE are
allowed. I prefer this interpretation because it allows a simple rule for
deciding when to initiate CHANNEL_CLOSE for all types of channels that
ensures channels don't stay open after they're no longer useful. The rule
is to do it as soon as both of the following two conditions are met: 

1. CHANNEL_EOF has been sent by this side (i.e. this side has no more data
or requests to send)
2. CHANNEL_EOF has been received from the other side, or this side cannot
process any more incoming channel data or requests.

---

From: [email-masked] (Niels Möller)
Date: 23 Mar 2002 08:39:51 +0100

> they're not going to send any data.

The client's EOF request doesn't matter here, the server will close
the channel as soon as the all of three events EOF on process stdout, EOF on
process stderr, death of process, have occured.

Earlier versions waited for the client to send EOF, but not all
clients do that. It makes some sense to wait for the client's EOF, but
for that to work we need the client to respont to exit-status with
EOF, and exit-status isn't mandatory, so that gets pretty fragile. So
I changed that behaviour a while ago after discussion on this list.

> with my own CHANNEL_CLOSE so that I can possibly catch the program's exit

I think the best you can do is to rely on the server to send
CHANNEL_CLOSE when the remote process is gone.

I include the description on channel close from lsh/doc/NOTES below.

Regards,
/Niels

EOF ON CHANNELS

A typical channel (i.e. all channels created in the current
implementation) are, at each end, connected to one or more fd:s for
reading and writing. When the source fd(:s), i.e. the fd:s that we are
reading, have no more data available, a CHANNEL_EOF message should be
sent. As there may be several such fd:s, we use a counter SOURCES in
the channel struct to keep track of the number of active source fd:s.
When an fd is closed, the counter is decremented, and when it reaches
zero, the CHANNEL_EOF message is sent.

The decrementing of the counter is done by the close-callback for the
fd, not by the read handler, as this is the easiest way to
ensure that it is called exactly once whenever a fd dies. However, the
sending of the CHANNEL_EOF message is done by the read handlers
do_channel_write() and do_channel_write_extended(). This is because
otherwise, eof on bidirectional fd:s migth be delayed until it is
closed also for writing. There are more unsolved issues with
bidirectional fd:s though, in particular tcp connections where one
direction is closed (with shutdown()) long before the other.

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.

---

From: [email-masked] (Niels Möller)
Date: 23 Mar 2002 08:58:13 +0100

Wei Dai <[email-masked]> writes:

> feel free to close the channel whenever it finishes sending its
> data.

To me, a channel can be viewed as three parts: two dataflows, one for
each directions, and sometimes auxillary communication like
CHANNEL_REQUEST.

If the parties are A and B, the dataflow from A to B are controlled by
the CHANNEL_DATA, CHANNEL_EXTENDED_DATA and CHANNEL_EOF sent by A, and
the WINDOW_ADJUST messages sent by B.

I think it's best to treat this dataflow independently from the
dataflow in the other direction, and from the auxillary communication.
Theyäre three orthogonal components of the channel.

> If you're going to send more information (e.g., the exit code) in
> the form of a CHANNEL_REQUEST after sending CHANNEL_EOF, then how
> does the other side know when it's safe to close the channel without
> losing information?

It's hard to know that for sure. As I said in my other message,
initiating close when EOF have been both sent and received is the
right thing to do for most channels, but it doesn't quite work for
sessions.

When I do

  ssh host cat foo

I want the channel to be closed and the local ssh process to exit when
all data has been sent by the server, and the remote process has died.
I think it would be annoying if the above command would keep the
channel open for ever just because the client never sends EOF. If the
server waits for EOF, users would have to type

  ssh host cat foo </dev/null

or

  ssh host cat foo
  ^D

to get the channel to close when they want. That would make sense, but
it would also annoy users. So I think it's better that the server
sends CHANNEL_CLOSE when the remote process is gone, regardless of
whether or not the client has sent EOF. (Clients replying to
exit-status with CHANNEL_EOF would also work; that's what my code used
to do, but I consider that solution less robust than simply having the
server initiate close).

> channels where the concept of child process termination doesn't apply?

For other channels, the "close whenever you have both sent and
received EOF"-rule works fine.

> process any more incoming channel data or requests.

Consider the

  ssh host cat foo

case. I'm afraid your simple rules are not sufficient (and I have
actually implemented them).

Regards,
/Niels

---

From: Markus Friedl <[email-masked]>
Date: Sat, 23 Mar 2002 09:30:59 +0100

>   /bin/sh -c "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17"

the reason for linking CHANNEL_EOF to CHANNEL_DATA only was:

/bin/sh -c "echo foo; exec >/dev/null; sleep 30; exec 2>/dev/null; sleep 30; exit 17"

so the EOF messages triggers a close(stdout) in the client
without waiting 30 more seconds.

---

From: Markus Friedl <[email-masked]>
Date: Sat, 23 Mar 2002 09:38:05 +0100

> flow control. It would be odd to treat them differently with respect

Yes, I see this.  My reason for linking EOF to the CHANNEL_DATA
is that i wanted to signal the EOF for the logins stdout
immediately to the client, so I can close(stdout).

> stderr data than is provided by the extended data hack.

Yes, that would help.

> SIGCHLD signal, and is esssentially random. 

Yes, of course. You can send CHANNEL_REQUEST always, until you
send a CHANNEL_CLOSE message.

> Can one send WINDOW_ADJUST after EOF? This is an ill-posed question.

I think EOF and WINDOW_ADJUST are unrelated. Even receiving a
WINDOW_ADJUST after an EOF makes sense, because the peer could have
sent the WINDOW_ADJUST before he receives the EOF.

---

From: Wei Dai <[email-masked]>
Date: Sat, 23 Mar 2002 09:12:34 -0800

> actually implemented them).

Maybe you didn't notice that condition 2 has two parts. If the child
process (cat in this case) terminates, then this side cannot process any
more incoming channel data or requests, so condition 2 is satisfied.

But I can see why you want to make CHANNEL_EOF independent from
CHANNEL_REQUEST, and also why Markus wants to make CHANNEL_EOF independent
from both CHANNEL_EXTENDED_DATA and CHANNEL_REQUEST.

What do you think about this proposal: link CHANNEL_EOF to all of
CHANNEL_DATA, CHANNEL_EXTENDED_DATA, and CHANNEL_REQUEST, and create two
new channel message types: CHANNEL_DATA_END, linked only to CHANNEL_DATA,
and CHANNEL_EXTENDED_DATA_END, linked only to CHANNEL_EXTENDED_DATA.
CHANNEL_EXTENDED_DATA_END would look like this:

     byte      SSH_MSG_CHANNEL_EXTENDED_DATA_END
     uint32    recipient_channel
     uint32    data_type_code

so there would be one CHANNEL_EXTENDED_DATA_END for each type of
extended data.

Then, CHANNEL_EOF would be used to determine when to close the channel,
and CHANNEL_DATA_END and CHANNEL_EXTENDED_DATA_END would be used to tell
the other side to close the corresponding fds.

---

From: Markus Friedl <[email-masked]>
Date: Sun, 24 Mar 2002 10:44:56 +0100

> more incoming channel data or requests, so condition 2 is satisfied.

i don't think so. incoming requests are handled by sshd, so they
could still be satisfied, e.g.  a possible request asking: "what's
the exit status of 'cat'"

---

From: [email-masked] (Niels Möller)
Date: 24 Mar 2002 21:30:36 +0100

> without waiting 30 more seconds.

I see. I don't think it's a very strong argument, though. If you
interchange stdout and stderr,

  /bin/sh -c "echo foo; exec 2>/dev/null; sleep 30; exec >/dev/null; sleep 30; exit 17"

you don't get the client to close stderr immediately when the remote
process closes it's stderr.

I'd prefer that sending neither DATA nor EXTENDED_DATA be allowed
after you've sent EOF.

It's still fine to send EOF immediately when you detect EOF on the
process' stdout, but if you do that, you should also stop reading
stderr, or discard any data you get from it. Don't send it to the
client.

/Niels

---

From: [email-masked] (Niels Möller)
Date: 24 Mar 2002 21:47:41 +0100

> CHANNEL_EXTENDED_DATA_END would look like this:

I don't like it. It's too much extra complexity for a small very gain.
It's the kind of improvement that identifies a design by a committee...

For most channels, sending EOF when you don't want to send any kind of
data, and CLOSE when you want the channel to go away, are exactly the
two messages you need. Then enters the EXTENDED_DATA hack, which so
far is used *exclusivelt* for session channels, and which has the
minor bug that it doesn't quite separate the stdout and stderr flow
(as what should have been two independent flows share both EOF
notifications and the flow-control related messages).

The situation could be improved, but then the right way is *not* to
introduce more variants of the EOF message to clean up after the
EXTENDED_DATA hack, but to introduce a new CHANNEL_OPEN or
CHANNEL_REQUEST messages that attaches a separate stderr channel to a
session.

And the bottom line is that I think EXTENDED_DATA, while not perfect,
is still pretty good, good enough that we shouldn't bend the rest of
the protocol to "fix" it. And I encourage anybody that is annoyed by
the limitations of EXTANDED_DATA to experiment with things like

  CHANNEL_OPEN "stderr-for-session" session

without changing our now almost standard core protocols.

Regards,
/Niels

---

From: "denis bider" <[email-masked]>
Date: Sun, 24 Mar 2002 22:02:54 +0100

Strongly agreed.

> I'd prefer that sending neither DATA nor EXTENDED_DATA
> be allowed after you've sent EOF.
> 
> It's still fine to send EOF immediately when you detect
> EOF on the process' stdout, but if you do that, you
> should also stop reading stderr, or discard any data
> you get from it. Don't send it to the client.

---

From: "denis bider" <[email-masked]>
Date: Sun, 24 Mar 2002 22:14:13 +0100

> > What do you think about this proposal:
> > link CHANNEL_EOF to all of CHANNEL_DATA,
> > CHANNEL_EXTENDED_DATA, and CHANNEL_REQUEST,
> > and create two new channel message types:
> > CHANNEL_DATA_END, linked only to CHANNEL_DATA,
>
> I don't like it. It's too much extra complexity
> for a small very gain. It's the kind of improvement
> that identifies a design by a committee...

Strongly agreed.

At this point of the protocol's evolution, drastic solutions like
introducing new message types would be counter-productive. All that is
required is a clear definition of what exactly CHANNEL_EOF means. This
definition should be compatible with most existing SSH2 implementations.
(Except obviously broken ones.)

> Then enters the EXTENDED_DATA hack,

I'm not bothered by EXTENDED_DATA being a hack. It is what it is, it works
how it works, that's fine with me. Now that the cat is out of the bag, and
50% of the world's secure shell servers already support SSH2, we won't get
rid of EXTENDED_DATA by redesigning the protocol. If we try to do so, we'll
just have to support the new system as well as the existing one.

---

From: Markus Friedl <[email-masked]>
Date: Mon, 25 Mar 2002 09:39:51 +0100

On Sun, Mar 24, 2002 at 09:30:36PM +0100, Niels Mller wrote:
> I see. I don't think it's a very strong argument, though.

Sure, but applications using ssh might behave different if the EOF
is delayed (e.g. stderr is not closed at all) and not send an
EOF in the other direction.

---

From: [email-masked] (Niels Möller)
Date: 25 Mar 2002 13:35:37 +0100

> EOF in the other direction.

Can you say some more about the problems you see? I don't see that the
opensshd behaviour solves real problems. As for EOF sent by the
client, my experience is that one can't rely on clients sending EOF
(on a session) as the result of the server sending EOF.

Clients typically send EOF when they get EOF on stdin, and often not
at all (e.g. with "ssh host cat foo" command, a typical client never
sends any EOF, no matter what combination of EOF, "exit-status" or
CLOSE that the server sends. (Older versions of lsh did send EOF as a
response to "exit-status", but that's the only case I'm aware of. It
turned out to not be very useful, as no other clients seemed to do
that)).

I think the current opensshd behaviour of sending EXTENDED_DATA after
EOF is simply a minor bug that should be fixed sooner or later. Do you
have a good reason for keeping that behaviour?

The below is an excerpt from a log in an lsh bug report, where the
user connected to an opensshd server with the command

  $ lsh openserver "echo hej 1>&2"

> lsh: Registering local channel 0.
> lsh: Taking channel 0 in use, (local 0).
> lsh: client.c: Receiving exit-status 0 on channel 0
> lsh: Receiving EOF on channel 0 (local 0)
> lsh: Extended data on closed or non-existant channel 0
> lsh: Receiving CLOSE on channel 0 (local 0)

(The warning message above is not entire accurate in this case, what
it means is simply that lsh received extended data after eof. The
channel does exist and it isn't closed).

Best regards,
/Niels

---

From: Markus Friedl <[email-masked]>
Date: Mon, 25 Mar 2002 13:47:08 +0100

> have a good reason for keeping that behaviour?

I never intended to keep the behaviour.