Actually, maybe they should be set to CHECKSUM_PARTIAL if we want veth to drop the packets if they have bad checksums before they hit the application level.
On Fri, Mar 25, 2016 at 12:41 AM, Vijay Pandurangan <vij...@vijayp.ca> wrote: > agreed. It should maybe be set to CHECKSUM_UNNECESSARY. The comment > seems to imply that it's treated the same as CHECKSUM_NONE but that's > evidently not true. I think that would fix the checksumming issue but > I'm fearful it may break something else: > http://lxr.free-electrons.com/source/include/linux/skbuff.h#L177 > > I'm really worried there are other equally subtle bugs hidden in this > code. Do we have any kind of regression test, or any automated way to > test all possible values on an skb to determine side effects to any > change here? (I'm new to the kernel so sorry if there's an answer in > an FAQ somewhere). > > If not, > 1. how should we ensure that our change doesn't break something else? > 2. Should we audit / simplify the checksum code or come up with a list > of test cases that covers all uses? > > > On Fri, Mar 25, 2016 at 12:34 AM, Ben Greear <gree...@candelatech.com> wrote: >> >> >> On 03/24/2016 06:44 PM, Vijay Pandurangan wrote: >>> >>> Oops, I think my last email didn't go through due to an inadvertent >>> html attachment from my phone mail client. >>> >>> Can you send us a copy of a packet you're sending and/or confirm that >>> the IP and UDP4 checksums are set correctly in the packet? >>> >>> If those are set right, I think we need to read through the networking >>> code again to see why this is broken... >> >> >> Wireshark decodes the packet as having no checksum errors. >> >> I think the contents of the packet is correct, but the 'ip_summed' >> field is set incorrectly to 'NONE' when transmitting on a raw packet >> socket. >> >> >> Thanks, >> Ben >> >> -- >> Ben Greear <gree...@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com
