cat at vv.carleton.ca
Sat Jul 13 17:51:09 WST 2013
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)
On Sat, Jul 13, 2013 at 12:31 PM, Catalin Patulea <cat at vv.carleton.ca> wrote:
> 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, 220.127.116.11 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 18.104.22.168 'cat; echo foo'
> $ ./dbclient root at 22.214.171.124 'cat; echo foo'
> <no output>
> I build dropbear with DEBUG_TRACE and these are the last few lines:
> TRACE (...): empty queue dequeing
> 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?
More information about the Dropbear