Maybe the check on common-channel.c:338 should be against writefd instead of readfd? This would get set by close_chan_fd(channel->writefd) once recv_eof happens.
This patch indeed causes 'foo' to surface after input EOF: diff -r 69cb561cc4c4 common-channel.c --- a/common-channel.c Sat Jul 13 11:53:24 2013 +0300 +++ b/common-channel.c Sat Jul 13 12:50:41 2013 +0300 @@ -335,7 +335,7 @@ } /* And if we can't receive any more data from them either, close up */ - if (channel->readfd == FD_CLOSED + if (channel->writefd == FD_CLOSED && (ERRFD_IS_WRITE(channel) || channel->errfd == FD_CLOSED) && !channel->sent_close && close_allowed On Sat, Jul 13, 2013 at 12:31 PM, Catalin Patulea <c...@vv.carleton.ca> wrote: > Hi, > > I'm seeing a difference in how dbclient handles EOF on input compared > to openssh client. openssh client propagates input EOF to the remote > command, but continues pumping command stdout. dbclient seems to abort > before flushing the stdout buffer. > > In the following examples, 1.2.3.4 is an openwrt router running > dropbear server. The remote command is designed to wait for EOF, then > output something to stdout. > > openssh client: > $ ssh root@1.2.3.4 'cat; echo foo' > ^D > foo > > dbclient: > $ ./dbclient root@1.2.3.4 'cat; echo foo' > ^D > <no output> > > I build dropbear with DEBUG_TRACE and these are the last few lines: > TRACE (...): empty queue dequeing > ^D > TRACE (...): send normal readfd > TRACE (...): enter send_msg_channel_data > TRACE (...): enter send_msg_channel_data isextended 0 fd 0 > TRACE (...): maxlen 16375 > TRACE (...): CLOSE some fd 0 > TRACE (...): leave send_msg_channel_data: len 0 read err 17 or EOF for fd 0 > TRACE (...): enter send_msg_channel_eof > TRACE (...): leave send_msg_channel_eof > TRACE (...): sending close, readfd is closed > TRACE (...): enter send_msg_channel_close 0xcbfdc0 > TRACE (...): enter cli_tty_cleanup > TRACE (...): leave cli_tty_cleanup: not in raw mode > TRACE (...): CLOSE some fd -1 > TRACE (...): CLOSE some fd 2 > > I tried reading through the relevant sections of channel-common.c but > I could use some guidance/background. Is this behaviour intentional? > > Catalin