From owner-freebsd-current@FreeBSD.ORG Mon Mar 8 07:48:03 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 50C3A106564A; Mon, 8 Mar 2010 07:48:03 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 12F2E8FC0C; Mon, 8 Mar 2010 07:48:02 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D455C730A1; Mon, 8 Mar 2010 08:57:33 +0100 (CET) Date: Mon, 8 Mar 2010 08:57:33 +0100 From: Luigi Rizzo To: Chuck Swiger , Tim Kientzle , "'freebsd-current@freebsd.org'" Message-ID: <20100308075733.GA24644@onelab2.iet.unipi.it> References: <4B9425C4.5060309@freebsd.org> <07C6C4E7-3512-4003-BDDE-DEDB549F6EA8@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07C6C4E7-3512-4003-BDDE-DEDB549F6EA8@mac.com> User-Agent: Mutt/1.4.2.3i Cc: 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: Mon, 08 Mar 2010 07:48:03 -0000 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