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>