Backup Central

Hi,

for the past week, I seem to be running into a consistent error
message during a backup run on one of the machines: "Corrupted MAC on
input".

This error is not a message of rdiff-backup but seems to be emitted by
the underlying ssh transport. Has anyone experienced this problem and
found a workaround?

The client's configuration is equal to five other backup clients who
don't have this problem. Could this be due to a large file, or a file
containing some kind of escape sequence?

I have tried the following:
- Changing the versions of ssh/sshd on the client and server;
I have tried OpenSSH 3.8.1p1 (FreeBSD standard) and OpenSSH 4.2p1
- Changing the login shell of the rdiff user on the server to /bin/sh
instead of tcsh
- Disabling ssh escape chars by using '-e none' parameter to ssh:
"--remote-schema '/usr/bin/ssh %s -e none rdiff-backup ..."

Versions: client and server are FreeBSD 5.4-RELEASE-p3 using
rdiff-backup from ports rdiff-backup-0.12.7_1.

Kind regards,
Walter Hop
Transip BV

--
Transip BV | http://www.transip.nl/
Hoogwaardige Innovatie | Aangename Zekerheid

Walter Hop wrote:
for the past week, I seem to be running into a consistent error
message during a backup run on one of the machines: "Corrupted MAC on
input"

Yes, I've seen exactly this error and there isn't a workaround as such.
It indicates network data corruption, and in my case a customer had a
cable modem that was corrupting fewer than 20 packets in a 1Gb file
transfer. After changing network cards, cables, etc, I finally convinced
the cable company to replace the modem, and the problem went away.

Not sure if that helps or not -

Keith

--
Keith Edmunds

+---------------------------------------------------------------------+
| Tiger Computing Ltd | Helping businesses make the most of Linux |
| "The Linux Company" | http://www.tiger-computing.co.uk |
+---------------------------------------------------------------------+

Walter Hop wrote:
I grabbed a 500MB file and scp'ed it repeatedly across the network
from the problem client to various hosts to see if I could recreate
the ssh error outside of rdiff-backup. The error happened here as
well, so it seems to be related to large streams of data, and the
problem is not due to some input that rdiff-backup throws at ssh.


we have solved similar problems where we had no control over some of the
lower layers, by implementing a openvpn tunnel. SSH over openvpn seems
to improve in reliability a little. I know it sounds whack, but it works.

dave