Re: Disconnecting: Corrupted MAC on input. - Solaris 8 64-bit SPARC

> I can't really follow that argument. If "tcp will recover" then the
> errors must be visible to TCP, and TCP will retransmit that segment
> before SSH can even take a look at it, let alone notice the corrupted
> MAC.

My apologies I worded that badly. I was more focused on trying to get
across that a layer 1 problem can be causing the symptoms this person is
seeing. Problems that would not lead to a noticeable issue in a non-SSH
TCP transfer (because there would be no disconnect) but would lead to a
very noticeable problem when using SSH.

In my specific case the corruption happened on the NIC but after the TCP
checksum was calculated. I have also seen situation where a faulty cable
introduces intermittent data corruption. TCP checksums do catch much of
it (but it does not necessarily catch all of it due to a higher than
expected rate of checksum collision
(http://www1.acm.org:80/sigcomm/sigco.../partridge.pdf)) but
sometimes a corrupted packet does get through and causes a disconnect
from SSH. In both cases its a layer 1 problem, but as you point out, the
specific corrupted packet causing the SSH disconnects is transparent to
TCP.

I was thinking more along the line that if TCP gets a corrupted packet
then it just retransmits. If SSH gets a corrupted packet it disconnects
(which is good, I wouldn't say this is anything but the correct behavior).

Previous discussions on this problem can be found here
http://marc.theaimsgroup.com/?t=108316318300002&r=1&w=2

specifically
http://marc.theaimsgroup.com/?l=open...5680024325&w=2
and the referenced bug #845
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/lis...enssh-unix-dev