> 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

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