Date: Fri, 23 May 2003 11:34:18 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: truckman@FreeBSD.org (Don Lewis) Cc: current@FreeBSD.org Subject: Re: possible bug fix for 82550-based fxp packet truncation problem Message-ID: <20030523183419.0636037B401@hub.freebsd.org> In-Reply-To: <200305230611.h4N6BUM7077910@gw.catspoiler.org> from Don Lewis at "May 22, 2003 11:11:30 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> >
> > 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.
-Bill
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu
wpaul@windriver.com | Wind River Systems
=============================================================================
"If stupidity were a handicap, you'd have the best parking spot."
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030523183419.0636037B401>