XL driver checksum producing corrupted but checksum-correct packets

Robert Watson rwatson at freebsd.org
Sat Jan 24 11:14:22 PST 2004


On Sat, 24 Jan 2004, Luigi Rizzo wrote:

> On Sat, Jan 24, 2004 at 01:38:37PM -0500, Robert Watson wrote:
> ...
> > (2) Try the NDIS driver with the NDIS-u-lator on FreeBSD 5.x and see if
> >     that also has the problem.
> 
> but going this way you have no idea on what the driver does, including
> enabling hw checksums. This looks like a useless test at least for the
> purpose of finding out what is going wrong

Actually, I'm more curious about whether it's a known errata/misbehavior
for the card that 3Com's drivers work around, or not.  The problem could
well be compleely unrelated to hardware checksuming per se -- the
corruption might well be taking place as the buffer is moved from the
card's buffer to the operating system managed buffer.  If the NDIS driver
doesn't illustrate the same problem, it tells us that by frobbing
appropriately, this problem can be worked around.  It also tells us that
by looking a bit harder at what the driver is doing (i.e., how it frobs
the hardware), we can learn something about the appropriate workaround. 
If it's a delay/timing issue, it's less likely we can learn something, but
if the NDIS driver is simply disabling hardware checksumming for specific
chipsets, that's something we should be able to figure out.  On the other
hand, if the NDIS driver shows the exact same problem, this might not be
an issue known to the vendor.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research




More information about the freebsd-hackers mailing list