More than likely this is due to a layer 1 problem somewhere along the
path. I saw this happen with some of the older intel pro e1000 cards but
I've also seen it happen with bad cables and flaky drivers (esp when
using some sort of offloading). A straight forward tcp transfer will
recovery from some intermittent hardware faults by just retransmitting
but MAC will, for obvious reasons, fail in these same conditions.

You can try to isolate problem by varying path components.

Good luck

Thomas Baden wrote:
> Hi everyone,
> I tried finding this using Google, but no joy.
> I have a massive (6GB uncompressed, 2.9GB compressed)
> file I'm attempting to transfer using SCP or SFTP. I
> get a random length into the transfer, and then it
> aborts with "Disconnecting: Corrupted MAC on input."
> Both hosts are Solaris 8, using OpenSSH4.4p1 compiled
> 64-bit by the Sun Forte C compiler. I've tried
> passing -o'Compression no' and -o'MACs
> hmac-sha1,hmac-ripemd160,hmac-sha1-96' in an attempt
> to sidestep the MAC that's causing the grief (I assume
> it's MD5, as that's the default first MAC). It only
> seems to happen in connection with this one file, as
> other files (not nearly as large) all transfer without
> pain.
> Does anyone have any suggestions?
> scp -vvv gives the following when it bombs:
> ebug2: channel 0: window 57344 sent adjust 73728
> debug2: channel 0: window 57344 sent adjust 73728
> Disconnecting: Corrupted MAC on input.
> debug3: channel 0: close_fds r 4 w 5 e 6 c -1
> lost connection
> I've even tried doing the following:
> ssh $host gzip -dc $file | gzip -9 > $file
> and got the same result.
> Cheers,
> -Thomas
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> _______________________________________________
> openssh-unix-dev mailing list

openssh-unix-dev mailing list