Bug 110507

Summary: scp corrupts files in transit
Product: Red Hat Enterprise Linux 3 Reporter: Need Real Name <christopher>
Component: opensslAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 3.0CC: shillman
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: 2003-11-22 12:23:48 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:

Description Need Real Name 2003-11-20 14:45:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
occasional bytes get corrupted when using scp

Version-Release number of selected component (if applicable):
Copying from RedHat 9 (openssl-0.9.6-3) to Enterprise 3 (openssl-
0.9.7a-22.1)

How reproducible:
Always

Steps to Reproduce:
1. Run "md5sum" on a big (800 megs) file
2. use "scp" to copy it from RH9 th RHEL3 (other combinations may 
fail also)
3. Run "md5sum" on the copy: it's different.

(scping it back again and using "diff" reveals the occasional byte 
has changed)

I have my SSH running on port 52263, so the command I use is:-

scp -P 52266 bigfile.tgz user:


Actual Results:  the new file is corrupted

Expected Results:  no corruption

Additional info:

I've had the same results using several different machines.

Also - same result using different ethernet cards between same 
machines (I have 2 subnets and 2 cards in my test PCs)

Searching google reveals other people experiencing similar problems.

Comment 1 Suzanne Hillman 2003-11-20 21:43:22 UTC
I am unable to reproduce this, at least while using machines with the
default port. If I specify the default port, I can't reproduce.
Even if I change the port, and specify it, I can't reproduce it. Note
that I changed the port on the RHEL3 machine, and scp'd while on and
from the RHL9 machine.

Can you give more detail on how you make this happen? Eg, how often it
happens? If it happens on specific machines with specific set ups, or
on all machines of the appropriate releases that you've tried it on?

Comment 2 Need Real Name 2003-11-20 21:53:31 UTC
I have 4 physical machines.

A  1 in California (RHEL3)
   3 on my office LAN (Australia)
B    1 RH9
C    1 RH9
D    1 Quad-boot: RHEL2.1, RHEL3.0, Windows XP, RHEL3.0

The problem occurs with SCP between 
  B and A (B(eth0) -> DSL504 -> internet -> (eth0)A)
  B and D (B(eth0) -> (eth0)D)  [both RHEL3's and the RHEL2.1 XP 
untested]
  B and D (B(eth1) -> (eth1)D)  [both RHEL3's and the RHEL2.1 XP 
untested]
  
I will attempt the "scp" commands again using "C" instead of "B" and 
let you know the results.

Comment 3 Need Real Name 2003-11-20 23:58:00 UTC
Update:-

The same file, copied using
  A: Samba, and
  B: HTTP, and
  C: using "sz" from within an SSH terminal window (nonstandard SSH 
port)

does NOT get corrupted.

The corruption that appears when using "scp" seems to be random - 
it's not the same bytes that get messed up every time - it's 
different ones.

Comment 4 Need Real Name 2003-11-22 12:19:22 UTC
x

Comment 5 Need Real Name 2003-11-22 12:23:16 UTC
False alarm, something else seems to be the cause:-

[cnd]$ cp D1 D2;cp D1 D3;cp D1 D4;cp D1 D5;cp D1 D6;cp D1 D7;cp D1 
D8;cp D1 D9
[cnd]$ md5sum D*
7b104ece295533594620027897c13e9b  D1
0f3b2603a2811382bc513e5747973d35  D2
7b104ece295533594620027897c13e9b  D3
7f14dd469544b02e5db79c7fadba2d0c  D4
dcb3418466371c6c5f964d1c205c59e4  D5
0bb7e1e0d2bf040e5048c49573219999  D6
7b104ece295533594620027897c13e9b  D7
0bb7e1e0d2bf040e5048c49573219999  D8
c689d7e318a9271e86555c7c69db9b2d  D9

Sorry guys - my original test SCP file was smaller, so got corrupted 
less often than the above, and by fluke of unlucky coincidence, only 
did it when I was using "scp" and not when I used anything else - 
until I noticed it occur once without scp - hence my idea to try the 
above test...

If this bug is still "open", someone else will need to close it - I 
don't know how.