Xen users - Jan 2006 - Corrupted MAC on input errors on large SCP to a DomU

I have seen this occur a number of times when performing very large
transfers from a desktop to/from a DomU

Current configuration

Dom0 - Debian 3.1 + Xen 2.0.7

DomU - RHEL4 U2 - TLS is still enabled.

All networking is 100Mb Full duplex, and there are no network errors on
any of the domain. Using plain vanilla bridge mode networking but using
a random MAC address rather than a fixed MAC.

Example of the error is

user@localhost > rsync -av  very_large_file domu:/media/archive/
building file list ... done
very_large_file
Received disconnect from 10.0.0.2: 2: Corrupted MAC on input.
rsync: writefd_unbuffered failed to write 4 bytes: phase "unknown"
[sender]: Broken pipe (32)
rsync: connection unexpectedly closed (121821 bytes received so far)
[sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(359)


Anyone else ever seen this issue?

Steve

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Steven Ellis wrote:
> All networking is 100Mb Full duplex, and there are no network errors on
> any of the domain. Using plain vanilla bridge mode networking but using
> a random MAC address rather than a fixed MAC.
[...]
> Received disconnect from 10.0.0.2: 2: Corrupted MAC on input.
Sorry, I don''t have a solution for your problem. But please note that
the MAC mentioned by ssh is something completely different from the MAC
used by the network setup: Ssh is talking about a ''message
authentication code'', which is a kind of checksum, while your network
card uses a ''media access control''-Address. So don''t
be confused by this
ambiguous use of an acronym.

As the MAC ssh talks about is a checksum, your problem may be caused by
some random data corrution. Normally this would be caught by the TCP
checksum and a retransmit would occur automatically. But the virtual
network cards of xen try to avoid checksumming, assuming that there are
not transmission errors when no real network cable is involved. So if
something like a bug or bad RAM causes random corruption of data
packets, you may get the mentioned error message.

To verify it''s really not a bug in ssh, you could try to transfer large
files with (e.g.) http, and then compare the copy to the original. As
http doesn''t do additional checksumming, the bad transmission would not
be caught by the protocol and you''d get a corrupted file. The kind of
corruption (single bit flips, bytes set to zero, ranges overwritten by
some other data, ...) may point to the cause of the problem.

Jan


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users