Subject: Re: libssh2 hangs in channel_close()

Re: libssh2 hangs in channel_close()

From: Simon Josefsson <simon_at_josefsson.org>
Date: Thu, 15 Apr 2010 08:51:00 +0200

Peter Stuge <peter_at_stuge.se> writes:

> Daniel Stenberg wrote:
>> If libssh2 skips the waiting for the remote EOF, what happens?
>> Peter's fix added both sending and waiting, and I think what we
>> suggest is that we drop the waiting.
>
> I don't think that this is for the best. The topic recently came up
> also on the OpenSSH list:
>
> http://lists.mindrot.org/pipermail/openssh-unix-dev/2010-April/028537.html
> http://anoncvs.mindrot.org/index.cgi/openssh/PROTOCOL?revision=1.14&view=markup#l40
>
> From this wording (and the RFC) it is clear to me that it is not so
> polite to CLOSE without first sending and receiving EOF - even if it
> *is* allowed. To me it makes a lot of sense to first clean up, and
> then CLOSE. So I implemented what I consider polite and more correct
> client behavior. And, OpenSSH works like that.
>
>
> commit 0ecd0eb37c02216bcb0c34797beb645bf14cf4bb removed the waiting
> for EOF and I believe this change originates in a somewhat different
> philosophy - one of more forcibly terminating the connection and
> shutting down more like *NOW*.
>
> I can understand the desire to not want to care about the server, but
> I don't think that it is the best we can do.
>
> It seems a bad idea to consciously do something in libssh2 that
> *could* upset servers, even though it is allowed by protocol. I've
> seen several sensitive servers mentioned on the OpenSSH list, and in
> any case I think it's best to take as few risks as possible.
>
> So, I do not think that it is what libssh2 should do by default!
>
> Actually - I don't think libssh2 should do it at all.
>
> If the calling app wants to just close down ASAP then they could
> close() the socket and move on. Or even exit().
>
> In summary I don't think we should encourage apps to CLOSE early.
> Be tolerant on input (API) but strict with output (protocol) is one
> way to explain it.
>
>
> If there are problems with two-way EOF then let's investigate them
> thoroughly and learn what the problem is, rather than yank code that
> happens to trigger the symptom.
>
> I guess noone else will look into what the actual problem is with the
> testcase, so I'll try to do it, but I'm not sure when I'll find time.

The problem with our self test, which uses OpenSSH, appears to be that
OpenSSH never sends the EOF so libssh2 waits forever. At least this is
the conclusion I made from the discussion so far.

/Simon
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-04-15