From owner-freebsd-current@FreeBSD.ORG Thu Apr 10 06:35:38 2008 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 883E91065673 for ; Thu, 10 Apr 2008 06:35:38 +0000 (UTC) (envelope-from vnovy@vnovy.net) Received: from slimak.dkm.cz (smtp.dkm.cz [62.24.64.34]) by mx1.freebsd.org (Postfix) with SMTP id D543B8FC15 for ; Thu, 10 Apr 2008 06:35:37 +0000 (UTC) (envelope-from vnovy@vnovy.net) Received: (qmail 83913 invoked by uid 0); 10 Apr 2008 06:35:36 -0000 Received: from r9gs206.net.upc.cz (HELO home.chello.upc.cz) (78.102.200.206) by smtp.dkm.cz with SMTP; 10 Apr 2008 06:35:35 -0000 Message-ID: <47FDB51A.1030606@vnovy.net> Date: Thu, 10 Apr 2008 08:35:06 +0200 From: Vitezslav Novy User-Agent: Thunderbird 2.0.0.9 (X11/20071201) MIME-Version: 1.0 To: Jack Vogel References: <200802042142.38606.qpadla@gmail.com> <200802070018.54429.qpadla@gmail.com> <006801c87f19$a14d8060$b6db87d4@multiplay.co.uk> <200804092043.24500.qpadla@gmail.com> <2a41acea0804091659l7ac2d9adqcbdd0caf900469b@mail.gmail.com> In-Reply-To: <2a41acea0804091659l7ac2d9adqcbdd0caf900469b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Steven Hartland Subject: Re: IP bad-len 0 ( on em0 ) 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: Thu, 10 Apr 2008 06:35:38 -0000 Jack Vogel wrote: > On Wed, Apr 9, 2008 at 10:43 AM, Nikolay Pavlov wrote: >> On Thursday 06 March 2008 01:35:43 Steven Hartland wrote: >> > Did you ever get anywhere with this? Did Jack respond? >> >> Nope. I've disabled tso. > > > I've looked into this a little, and then got interrupted with other issues. The > reason the thing is zero'ed is because the hardware is going to repacketize > this big wad that its been handled, it should be making new headers that > appear in the packets on the wire. So its not yet clear to me what the > real brokenness is, you are actually SUPPOSED to zero that value and > csum according to documentation, but the rewritten headers should have > correct len's in them, so the question is why in some cases they do not. I think packets on wire have correct IP-len, but after sending packet to card, driver injects original long packet with zeroed IP-len to BPF. So in tcpdump, we see packet with zero IP-len. vita