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
luigi
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
