From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 11:26:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D41116A4CE for ; Sun, 25 Jan 2004 11:26:57 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAEE843D53 for ; Sun, 25 Jan 2004 11:26:45 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0PJOUUd001459; Sun, 25 Jan 2004 14:24:30 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0PJOUEd001456; Sun, 25 Jan 2004 14:24:30 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 25 Jan 2004 14:24:30 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20040125131053.X873@odysseus.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Max Laier cc: hackers@freebsd.org Subject: Re: XL driver checksum producing corrupted but checksum-correct packets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 19:26:57 -0000 On Sun, 25 Jan 2004, Mike Silbersack wrote: > On Sat, 24 Jan 2004, Robert Watson wrote: > > > To pick up the corrupted packet on the machine where the corruption is > > occurring, you might want to try hooking up the UDP checksum drop case to > > BPF_MTAP() for a special BPF device or rule, or have it spit them into a > > raw socket (probably easier). > > He said that the packet's checksum passes, but it is corrupt, so this > won't work. I may have misread: my reading was that the if_xl card marks the packet as having passed the checksum test, but if you let the OS do the checksum, the checksum fails. I.e., either the hardware checksumming is broken, or the data is corrupted between when the hardware does the checksum, and it reaches the OS buffer. As such, Sam's patch works because it tells the OS to ignore the checksum results from the hardware (although it doesn't disable the checking of checksums), causing the OS to recalculate the checksums and drop the packets rather than accepting them. The goal of the change I suggested would be to also do the checksums in the OS as well, which allows you to detect the bad packets, but instead of dropping them, funnel them aside for later analysis. However, if I've misread, sorry for the confusion! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research