Dropbear 0.50 server returnsexit code 255 to ssh when app returns 0

[Matt Johnston]

On Fri, Feb 29, 2008 at 03:32:52PM -0600, Steven Hein wrote:
> Steven Hein wrote:
> >Hello--
> >
> >I have not seen any new information on this issue since the thread
> >from last December:
> >
> >http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2007q4/000672.html
> >
> >Does anyone have any updates or workarounds?     I just upgraded
> >to 0.50 about 2 weeks ago and found that this is causing me troubles.
> >
...
> I spent some time digging in to this today   (rather
> unscientifically, by sprinkling dropbear_log() messages throughout
> svr-chansession.c).  I found that the child process didn't seem to
> terminate before that client requested that the session be closed.
> (Specifically, the child was still running when send_exitsignalstatus()
> was called, so exitpid was still -1.   I couldn't see any obvious
> reason for this, and the child process always terminated
> "very soon" (milliseconds) after send_exitsignalstatus() was done.

Yep, that seems to be the cause. I've attached a patch that
will wait for he process to exit before closing the channel,
which should fix the problem. I've put a testing release at
http://matt.ucc.asn.au/dropbear/testing/dropbear-0.51test2.tar.bz2
with that fix and a couple of other things.

I'd appreciate if anyone who has had odd channel-closing
issues could test that. I suspect that it might alter some
behaviour such as 'ssh hostname "sleep 10 & echo hello"',
but I can't see a better way to do it - if during cleanup a
process's stdin/stdout is closed before the process
terminates, then there'll always be that race. It seems
safer to just wait for the spawned shell to exit.

Cheers,
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: channel-exit-1.diff
Type: text/x-diff
Size: 1865 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080301/a52d4199/attachment.diff