Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 May 2003 13:35:11 -0700 (PDT)
From:      Don Lewis <truckman@FreeBSD.org>
To:        wpaul@FreeBSD.org
Cc:        current@FreeBSD.org
Subject:   Re: possible bug fix for 82550-based fxp packet truncation problem
Message-ID:  <200305232035.h4NKZBM7079385@gw.catspoiler.org>
In-Reply-To: <20030523183419.0636037B401@hub.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 23 May, Bill Paul wrote:
>> > 
>> > Just to let people know, I have been trying to investigate this, but
>> > my time has been somewhat limited lately. The original reason I turned
>> > off the IP checksumming on transmit was that there was one test case
>> > where the chip seemed to be generating improper checksums. That is,
>> > if you did something like: ping -s 1473 <otherhost>. This would result
>> > in a full sized frame, plus a small IP fragment containing just one
>> > byte of data. On the machine I used for testing, the small fragment
>> > was rejected by the host on the other side due to a bad header checksum.
>> 
>> According to the second note in the Intel document that I cited,
>> hardware checksumming is unsupported in this case.
> 
> Argh. No. IP checksumming == a checksum of the IP header only. The
> chip is perfectly capable of computing IP header checksums over
> fragments, and does so quite well, _except_ in this one bizarro case
> I encountered with tiny packets on this single P166 system.

Maybe that was the original intent and hardware bugs were found later.
The Intel document specifically says (emphasis mine):
	Therefore, the driver should not request *any* offload features
        for an IP fragment.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305232035.h4NKZBM7079385>