From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 21 06:27:05 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7050B16A400 for ; Tue, 21 Mar 2006 06:27:05 +0000 (UTC) (envelope-from arr@watson.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id C32E943D45 for ; Tue, 21 Mar 2006 06:27:02 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.13.4/8.13.4) with ESMTP id k2L6R1i7095757; Tue, 21 Mar 2006 01:27:01 -0500 (EST) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.13.4/8.13.4/Submit) with ESMTP id k2L6R04E095754; Tue, 21 Mar 2006 01:27:01 -0500 (EST) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Tue, 21 Mar 2006 01:27:00 -0500 (EST) From: "Andrew R. Reiter" To: Scott Long In-Reply-To: <441F9B28.7030602@samsco.org> Message-ID: <20060321012458.I92974@fledge.watson.org> References: <20060320211720.GB31216@uriah.heep.sax.de> <20060320235732.GA79203@cdnetworks.co.kr> <20060321061508.GK31216@uriah.heep.sax.de> <441F9B28.7030602@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Joerg Wunsch , freebsd-sparc64@freebsd.org Subject: Re: hme(4) broken on non-sparc64 systems in -current X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 06:27:05 -0000 On Mon, 20 Mar 2006, Scott Long wrote: :Joerg Wunsch wrote: :> As Pyun YongHyeon wrote: :> :> :> > How about backing out rev. 1.46(if_hme.c)? :> :> :> > For the same patch sent to bard@OpenBSD I got a positive report :> > so it's strange to me though.(brad@OpenBSD reported Rx checksum :> > offload breakage on little endian systems.) :> :> :> Yes, backing that out helps. I'm not sure what this change was trying :> to fix. I've noticed before that tools like ethereal reported the :> checksum as invalid but the traffic itself was unaffected. Anyway, as :> it was now, the traffic was blocked, so perhaps there's more than one :> spot where this needs to be fixed? :> :> I'll look a bit further into it tonight. Thanks! :> : :When tx checksum offloading is enabled, you'll always get checksum errors when :capturing the local end of the transmission. That expected, :since the checksum never gets computed until long after the bpf tap has :captured it. : :Scott : Something to note (from the application side) is that many applications that use libnids don't offer the option to deal with cksum offloading. Things like dsniff will want you to turn offloading off since there is no simple way (unless you modify the source, which then weakens the reliabliity of the stream assembly) to deal with this. Just an extra thought to thing of. Cheers, Andrew -- arr@watson.org