cat at vv.carleton.ca
Sat Jul 13 17:31:48 WST 2013
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, 184.108.40.206 is an openwrt router running
dropbear server. The remote command is designed to wait for EOF, then
output something to stdout.
$ ssh root at 220.127.116.11 'cat; echo foo'
$ ./dbclient root at 18.104.22.168 'cat; echo foo'
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