Bug 110507 - scp corrupts files in transit
scp corrupts files in transit
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openssl (Show other bugs)
3.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-20 09:45 EST by Need Real Name
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-22 07:23:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2003-11-20 09:45:38 EST
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@target.com:


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 16:43:22 EST
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 16:53:31 EST
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 18:58:00 EST
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 07:19:22 EST
x
Comment 5 Need Real Name 2003-11-22 07:23:16 EST
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.

Note You need to log in before you can comment on or make changes to this bug.