[Nottingham] Strange ssh errors - Corrupted MAC on input.

[Simon Amor]

I've been trying to copy data between two servers, one that I know is  
working fine and the other which was freshly installed yesterday.  
Using rsync over ssh, I'm getting the following error messages after  
transferring anywhere between 10MB and 1000MB. I have around 50GB to  
copy and don't really want to have to restart rsync every few minutes  
as that's just a waste of time.

On the old server, whilst rsyncing to the new server:

Received disconnect from UNKNOWN: 2: Corrupted MAC on input.
rsync: writefd_unbuffered failed to write 4 bytes: phase  
"unknown" [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (463060 bytes received so far)  
[sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(434)

The reason the subject says ssh errors not rsync errors, is that I've  
been ssh'd into the new server from home and had exactly the same  
thing appear in the middle of my session at which point it closed the  
connection on me. The "Corrupted MAC on input" message appears to be  
the important part.

Both servers are Fedora Core 3 and google'ing for the error has given  
me plenty of people with the same problem, but never any solutions.  
The network port on the new server has been plugged into a new switch  
port with a new cable but still results in the same error. The main  
difference between the two is that the old one runs  
2.6.11-1.27_FC3smp and the new one runs 2.6.12-1.1376_FC3smp

Unfortunately I can't find the 2.6.11 rpms any more so can't even try  
using the same kernel on both. The servers are DELL boxes with 1GB  
and 2GB RAM (new and old) and a pair of 160GB SATA drives each. I  
tried upgrading the old server to 2.6.12-1.1372_FC3smp (the release  
before the current one) and it failed to find the drives on bootup  
which is why it's on 2.6.11 still.

Any suggestions on how to resolve this - either a software fix I can  
apply or some way to prove that the hardware is faulty - would be  
greatly appreciated.

    Simon
-- 
Simon Amor
simon at leaky.org
http://www.leaky.org/