On Sun, Mar 07, 2010 at 03:08:38PM -0800, Chuck Swiger wrote: > Hi, Tim-- > > On Mar 7, 2010, at 2:16 PM, Tim Kientzle wrote: > [ ... ] > > Corrupted MAC on input. > > Disconnecting: Packet corrupt > > rsync: connection unexpectedly closed ... [receiver] > > > > and then the rsync session is dead. > > > > It seems odd that a single corrupt packet would terminate the TCP connection. > > It's not TCP itself which is closing the connection; if a garbage packet as far as TCP or IP layer checksums was seen, it would be dropped and normal resend mechanisms would compensate. However, SSH adds it's own layer of data integrity checking called HMAC, which uses block-based hashes like MD5 or SHA, and is much stronger than the 32-bit CRCs used at TCP/IP layers. > > See: > > /usr/src/crypto/openssh/packet.c > http://en.wikipedia.org/wiki/HMAC > > The implication is that the data is being corrupted before it gets munged into network packets; failing memory is a likely cause, but bugs in the network stack, the NIC driver, or OpenSSL are also lower-order possibilities. long ago, with the 'iwi' driver, there was the following problem leading the the sae problem you are seeing: the driver was doing WEP in software, and wrote back the result to the original mbuf (actually, cluster). As a result, the first transmission of a segment was correct, but in case a rxmt, data would be encrypted twice, and the remote ssh end detected the garbage and dropped the connection. This was fixed with Sam's help around early 2007 if i remember well. An easy way to see if it is a similar problem is use ipfw to drop some packets e.g. ipfw add 100 prob 0.1 deny tcp out xmit wi0 // use your interface name cheers luigiReceived on Mon Mar 08 2010 - 06:48:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:01 UTC