This is a discussion on Re: Disconnecting: Corrupted MAC on input. - Solaris 8 64-bit SPARC - openssh ; > 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 ...
> 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
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
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
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
and the referenced bug #845
openssh-unix-dev mailing list