Josh Graessley writes:

CSUM_TCP_SUM16 is only for the GMAC hardware, you shouldn't need to set it

for your hardware. It only causes some weird special case code to be

executed. Ideally, you should be able to get things working with the other

flags. The hardware checksum support in the kernel is still new, so it may

contain some rough edges you'll get snagged on, as you're noticing. Some of

this is addressed on a branch we're working on.

I don't recall what the psuedo header does. Perhaps someone else can help

Do you mean the CSUM_PSEUDO_HDR flag? It means the device has checksummed the entire packet (including the psuedo header) and has left the csum in csum_data.

out there. I do know that you can't perform hardware udp/tcp checksums on

fragmented packets unless you're going to handle reassembly in your

hardware. The UDP or TCP checksum is in the first fragment that contains the

UDP or TCP header. All other fragments of the packet contain the IP header

followed by UDP or TCP data. You can't calculate the UDP/TCP checksum until

you've collected all fragments. I believe most stacks avoid TCP

fragmentation, so I doubt you'll see much if any of that. This will still be

a problem from UDP though.

Yeah.. I don't want to collect all the fragments -- I want ip_reass() to collect them because that's its job. Eg, I want to pass the payload checksums up the stack and have ip_reass() add things up. In fact, if you look at the code, its already adding the csum's up in the "Concatenate fragments." section of ip_reass. All that needs to be done is to fix the proto layers to call in_pseudo() to adding the psuedo header sum on packets without CSUM_TCP_SUM16 or CSUM_PSEUDO_HDR set & I'll be a happy camper. FWIW, this is how it works in FreeBSD. Cheers, Drew