dbclient half-close?

[Catalin Patulea]

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 <cat at 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 at 1.2.3.4 'cat; echo foo'
> ^D
> foo
>
> dbclient:
> $ ./dbclient root at 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