> More information appended... > >> Hi, >> >> We are running the Dropbear 0.50 SSH server on an ARM9 platform. We are >> connecting to it from a fast quad-core intel server over 100-Base-T. >> >> We found this problem when trying to build Perl for the target. The >> cross-compile process uploads and runs programs on the target and checks >> the exit code from the SSH client to check the target program's exit >> code. >> >> The ARM9 platform is running a stock Linux 2.6.18 kernel compiled with >> the >> GCC CodeSourcery 2006q3-26 v4.1.1. >> >> The host Intel platform is running CentOS5 with OpenSSH_4.3p2. >> >> A sample shell script on the target is: >> >> #!/bin/bash >> echo "ARG: $1" >> exit $1 >> >> When we run dropbear 0.50 server on the target without debug enabled, we >> get exit code 255 from SSH. e.g. >> >> # ssh [EMAIL PROTECTED] /tmp/test.sh 1 >> ARG: 1 >> # echo $? >> 255 >> # >> >> # ssh [EMAIL PROTECTED] /tmp/test.sh 100 >> ARG: 1 >> # echo $? >> 255 >> # >> >> If we recompile dropbear with debug enabled, but don't pass the -v >> option >> when starting dropbear, the behavior is the same. If we run dropbear >> with >> the "-F -E -v" options, we get the correct exit codes. >> >> # ssh [EMAIL PROTECTED] /tmp/test.sh 1 >> TRACE: enter sign_key_free >> TRACE: enter dsa_key_free >> TRACE: enter dsa_key_free: key == NULL >> TRACE: enter rsa_key_free >> TRACE: leave rsa_key_free >> TRACE: leave sign_key_free >> ARG: 1 >> # echo $? >> 1 >> # >> >> # ssh [EMAIL PROTECTED] /tmp/test.sh 100 >> TRACE: enter sign_key_free >> TRACE: enter dsa_key_free >> TRACE: enter dsa_key_free: key == NULL >> TRACE: enter rsa_key_free >> TRACE: leave rsa_key_free >> TRACE: leave sign_key_free >> ARG: 1 >> # echo $? >> 100 >> # >> >> Does anyone have any ideas what could be causing this? >> >> Has anyone seen this on other platforms or is happy that dropbear does >> return the correct exit codes in their tests? >> >> Thanks, >> >> Roger >> > > I have upgraded the host to OpenSSH 4.7 and the problem persists. > > Turning on full logging on the host provides the following end trace on a > failing connection (when dropbear is not generating logging output to the > serial terminal): > > debug2: channel 0: open confirm rwindow 8000 rmax 8000 > ARG: 100 > debug2: channel 0: rcvd eof > debug2: channel 0: output open -> drain > debug2: channel 0: obuf empty > debug2: channel 0: close_write > debug2: channel 0: output drain -> closed > debug2: channel 0: rcvd close > debug2: channel 0: close_read > debug2: channel 0: input open -> closed > debug3: channel 0: will not send data after close > debug2: channel 0: almost dead > debug2: channel 0: gc: notify user > debug2: channel 0: gc: user detached > debug2: channel 0: send close > debug2: channel 0: is dead > debug2: channel 0: garbage collecting > debug1: channel 0: free: client-session, nchannels 1 > debug3: channel 0: status: The following connections are open: > #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) > > debug3: channel 0: close_fds r -1 w -1 e 7 c -1 > debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 > debug1: Exit status -1 >
TYPO: Below should read ..."when dropbear is generating logging"... The cut-and-paste daemon strikes again! > > On a working connection, when dropbear is not generating logging output to > the serial terminal, following end trace is gathered: > > debug2: channel 0: written 106 to efd 7 > ARG: 100 > debug2: channel 0: rcvd eof > debug2: channel 0: output open -> drain > debug2: channel 0: obuf empty > debug2: channel 0: close_write > debug2: channel 0: output drain -> closed > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > debug2: channel 0: rcvd close > debug2: channel 0: close_read > debug2: channel 0: input open -> closed > debug3: channel 0: will not send data after close > debug2: channel 0: almost dead > debug2: channel 0: gc: notify user > debug2: channel 0: gc: user detached > debug2: channel 0: send close > debug2: channel 0: is dead > debug2: channel 0: garbage collecting > debug1: channel 0: free: client-session, nchannels 1 > debug3: channel 0: status: The following connections are open: > #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) > > debug3: channel 0: close_fds r -1 w -1 e 7 c -1 > debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.5 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 > debug1: Exit status 100 > > > With the working connection, we get the "client_input_channel_req" event > coming in whereas in the failing connection, it doesn't occur. > > Does this information give anyone a clue/suggestion as to what may be > failing? > > Thanks. >
