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 [email protected] 'cat; echo foo' ^D foo dbclient: $ ./dbclient [email protected] '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
