This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-users] Re: Corrupted MAC on input errors on large SCP to a DomU

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] Re: Corrupted MAC on input errors on large SCP to a DomU
From: Jan Niehusmann <jan@xxxxxxxxxx>
Date: Wed, 18 Jan 2006 09:05:33 +0100
Delivery-date: Wed, 18 Jan 2006 11:38:52 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43CD8A0E.8000200@xxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <43CD8A0E.8000200@xxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Debian Thunderbird 1.0.7 (X11/20051017)
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 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.


Xen-users mailing list

<Prev in Thread] Current Thread [Next in Thread>