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 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.
