Re: kern/34799: IP Filter does not work correctly with gem(4) when hardware chec

["David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>]

The following reply was made to PR kern/34799; it has been noted by GNATS.

From: "David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>
To: jdc%coris.org.uk@localhost, gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/34799: IP Filter does not work correctly with gem(4) when 
hardware chec
Date: Mon, 28 Jan 2008 21:16:47 -0500

 >Looking at this further, I thought that we should be setting the receive
 >checksum offset to the end of the ethernet header, not the end of the IP
 >header.  However, when I do this, the checksum part of the received data
 >is still the same, but the hash value part changed.
 >
 >I looked at the OpenSolaris and Linux sources to see what they were doing.
 >OpenSolaris sets the offset to the end of the ethernet header (so they must
 >see the same bug that we're seeing) and Linux appears to ignore receive
 >checksums entirely.
 >
 >I'm tempted to do the latter, as then we will at least work out of the box,
 >rather than breaking with ipfilter.  Also, I'm pretty much out of ideas at
 >this point.
 
 Hi,
 
 I did some more poking about on the web, and found this reference
 from Darwin developers' correspondence:
 
 http://lists.apple.com/archives/darwin-kernel/2002/Jan/msg00036.html
 
 I think this except is telling:
 
 "> Also, why does darwin not allow csum offloading for received ip
 >fragments using the CSUM_TCP_SUM16 method?
 
 The CSUM_TCP_SUM16 flag is used to indicate that the GMAC's checksum is
 being used. The GMAC hardware checksum has some limitations. There are a lot
 of checks for the various limitations to avoid cases where the hardware does
 the wrong thing. I believe IP fragments may be one of the cases where the
 chipset does the wrong thing."
 
 Could it be that this problem only appears on macppc because specific
 GMAC chips are defective?  I don't know anything about GMAC, but I
 wonder if there were bugs present in the chips shipped in (some) Apple
 machines, but perhaps not in the ones used by Sun?  (Though there was
 that old IPFilter FAQ entry about the eri driver under Solaris not
 working with hardware checksumming too...  Maybe it's the same problem,
 and it affects very specific Sun hardware as well.)
 
 My gem card shows it's revision 0:
 gem0 at pci2 dev 15 function 0: Apple Computer GMAC Ethernet (rev. 0x00)
 
 My guess is that revision 1 GMAC chips behave differently in this
 regard.
 
 Regards,
 
 Dave
 
 PS Having tested the GENERIC kernel from HEAD, it seems that gem no
 longer supports UDP checksumming?  It did with 4.0.