Disconnecting: Corrupted MAC on input. - Solaris 8 64-bit SPARC OpenSSH 4.4p1

[Chris Rapier]

> 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/sigcomm95/papers/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=openssh-unix-dev&m=108575680024325&w=2
and the referenced bug #845