Bug 139944

Summary: scp command sometimes returns wrong exit code
Product: [Fedora] Fedora Reporter: Aleksandar Milivojevic <alex>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-06 15:34:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
scp -v on CentOS4/RHEL4
none
scp -v of FC-devel built on CentOS4/RHEL4 none

Description Aleksandar Milivojevic 2004-11-18 21:09:43 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Firefox/0.10.1

Description of problem:
The scp command from openssh package sometimes returns wrong exit
code.  The file is transferred correctly.  Exit code is wrong.

If I scp from Linux box to Linux box: OK
If I scp from Linux FC3 box to Solaris box: ERROR
If I scp from Linux RH73 box to Solaris box: OK
If I scp from Solaris box to Linux box: OK
If I scp from Solaris box to Solaris box: OK

The only problem is when scp command on Fedora Core 3 is connecting to
server on Solaris 9.  Same thing using scp command on Red Hat 7.3
works correctly.  All other combinations work correctly.  My wild
guess is that there's something wrong with the client on FC3.

The SSH server on Solaris box is the one that comes with Solaris 9.

BTW, it might be related.  When I ssh from FC3 box to Solaris9 box,
and then logout, ssh session sometimes hangs (not always
reproducable).  Escape key sequence doesn't work.  I need to either
kill ssh process from another window, or close the window with hung
session.

Version-Release number of selected component (if applicable):
openssh-3.9p1-7

How reproducible:
Always

Steps to Reproduce:
1. From FC3 box: scp filename solaris9-box:
2. echo $?

Actual Results:  echo $? returns 1

Expected Results:  It should return 0

Additional info:
Comment 1 Tomas Mraz 2005-04-05 19:32:27 UTC 
Can you try openssh-4.0p1 from FC development?
However you would need to rebuild it from .src.rpm if you don't want to upgrade
other packages to FC development.

Also could you try to post a log which is produced when running scp to the
Solaris box with -v option.
Comment 2 Aleksandar Milivojevic 2005-04-06 15:09:48 UTC 
I've upgraded my machine to CentOS 4 recently (distro built from RHEL 4 SRPMs,
basically a clone).  Bug was still present (openssh-3.9p1-8.RHEL4.1).  Then I
rebuilt openssh package from FC development tree and installed it
(openssh-4.0p1-2) and got the same error.

This menas that bug is present in:
   - FC3
   - FC devel
   - RHEL4

I will include scp -v from both openssh-3.9p1-8.RHEL4.1 and openssh-4.0p1-2 as
attachments.  Diff on the files doesn't show any differences (other than version
numbers, and some other unimportant details).
Comment 3 Aleksandar Milivojevic 2005-04-06 15:11:03 UTC 
Created attachment 112757 [details]
scp -v on CentOS4/RHEL4
Comment 4 Aleksandar Milivojevic 2005-04-06 15:12:04 UTC 
Created attachment 112758 [details]
scp -v of FC-devel built on CentOS4/RHEL4
Comment 5 Tomas Mraz 2005-04-06 15:34:27 UTC 
The problem is that the local scp only executes scp on the remote machine
through the ssh connection. The remote scp returns -1 and this exit status (!=
0) is translated in the local scp as 1. The problem lies on the Solaris side not
on the FC side.
Comment 6 Aleksandar Milivojevic 2005-04-06 16:46:30 UTC 
OK, how do you than explain than openssh as distributed with Red Hat 7.3 works
just fine?  Plus, Solaris to Solaris also works fine.  And more or less
anything-else (other than openssh 3.9+) to Solaris works fine.

IMO, something on the FC side is triggering Solaris side to return -1.
Comment 7 Tomas Mraz 2005-04-06 16:56:02 UTC 
I'd suppose the problem could lie in the versions of the openssh on the systems.
You can try to report that upstream to OpenSSH bugzilla http://bugzilla.mindrot.org/