On 28-Jan-2009, at 3:23 AM, Ignatios Souvatzis wrote:
Last time this was reported, I think the culprit was the hardware checksumming, which ensures that the packets are correct *on the wire*, but not yet in the machine's main memory. As I understand, this would apply to transmitted packets only, but on a NAT box or a router, most packets are transmitted at some point... Switch .*SUM.* off for a quick test.
Hmmm... yes, as I said in the rest of the message [:-)], that's what I did, and it seems to work better now (at least no more packets are logged as "bad" and my client hasn't called to complain that everything is blocked).
I'm naively guessing the NAT is changing the UDP header but not recalculating the checksum, perhaps because (part of) the NAT code assumes the hardware will fix the checksum on the way out?
Anyway, in PR# 34799 it seemed to me that the problem was buggy assumptions in the gem(4) driver about what capabilities the chip actually had.
I'm wondering if the problem is really in the driver/chip or rather instead in a fundamental conflict between the concept of hardware checksumming and the IPF/NAT code which assumes it can both manipulate the packets and then verify the checksums in the packets. I've forgotten too much about the IPF code to remember where to dig into it quickly to see if it has any logic flaws in its understanding of what's possible when the interface does hardware checksumming.
--
Greg A. Woods; Planix, Inc.
<woods%planix.ca@localhost>
Attachment:
PGP.sig
Description: This is a digitally signed message part