From owner-freebsd-current@FreeBSD.ORG Sun Mar 7 23:08:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28A1B106566B for ; Sun, 7 Mar 2010 23:08:40 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 1132F8FC0A for ; Sun, 7 Mar 2010 23:08:39 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.151.101.134] by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KYX0052JPMEDQ90@asmtp028.mac.com>; Sun, 07 Mar 2010 15:08:39 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003070221 From: Chuck Swiger In-reply-to: <4B9425C4.5060309@freebsd.org> Date: Sun, 07 Mar 2010 15:08:38 -0800 Message-id: <07C6C4E7-3512-4003-BDDE-DEDB549F6EA8@mac.com> References: <4B9425C4.5060309@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1077) Cc: "'freebsd-current@freebsd.org'" Subject: Re: Wireless TCP aborts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 23:08:40 -0000 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. Regards, -- -Chuck