Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Sat, Apr 30, 2016 at 5:52 PM, Ben Greear wrote: >> >> Good point, so if you had: >> >> eth0 <-> raw <-> user space-bridge <-> raw <-> vethA <-> veth B <-> >> userspace-stub <->eth1 >> >> and user-space hub enabled this elide flag, things would work, right? >> Then, it

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Sat, Apr 30, 2016 at 5:29 PM, Ben Greear <gree...@candelatech.com> wrote: > > > On 04/30/2016 02:13 PM, Vijay Pandurangan wrote: >> >> On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear <gree...@candelatech.com> >> wrote: >>> >>> >>> &

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear wrote: > > > On 04/30/2016 12:54 PM, Tom Herbert wrote: >> >> We've put considerable effort into cleaning up the checksum interface >> to make it as unambiguous as possible, please be very careful to >> follow it. Broken

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

[oops – resending this because I was using gmail in HTML mode before by accident] There was a discussion on a separate thread about this. I agree with Sabrina fully. I believe veth should provide an abstraction layer that correctly emulates a physical network in all ways. Consider an environment

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

On Fri, Mar 25, 2016 at 7:46 PM, Ben Greear wrote: > A real NIC can either do hardware checksums, or it cannot. If it > cannot, then the host must do it on the CPU for both transmit and > receive. > > Veth is not a real NIC, and it cannot do hardware checksum offloading.

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

On Fri, Mar 25, 2016 at 6:23 PM, Ben Greear <gree...@candelatech.com> wrote: > On 03/25/2016 02:59 PM, Vijay Pandurangan wrote: >> >> consider two scenarios, where process a sends raw ethernet frames >> containing UDP packets to b >> >> I) process a -

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

consider two scenarios, where process a sends raw ethernet frames containing UDP packets to b I) process a --> veth --> process b II) process a -> eth -> wire -> eth -> process b I believe (I) is the simplest setup we can create that will replicate this bug. If process a sends frames that

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

On Fri, Mar 25, 2016 at 10:35 AM, Ben Greear <gree...@candelatech.com> wrote: > > > On 03/24/2016 10:24 PM, Vijay Pandurangan wrote: >> >> On Fri, Mar 25, 2016 at 1:07 AM, Ben Greear <gree...@candelatech.com> >> wrote: >>> >

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

On Fri, Mar 25, 2016 at 1:07 AM, Ben Greear <gree...@candelatech.com> wrote: > On 03/24/2016 09:45 PM, Vijay Pandurangan wrote: >> >> Actually, maybe they should be set to CHECKSUM_PARTIAL if we want veth >> to drop the packets if they have bad checksums before they h

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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_UN

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

; 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

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: [PATCH] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

Just as a followup, I wrote a short blog detailing the bug and our resolution: (https://twitter.com/vijayp/status/697837808417779716) Thanks again for your help in guiding us through our first kernel patch. This was a great experience! direct link: https://medium.com/vijay-pandurangan/linux

[PATCH] veth: don't modify ip-summed; doing so treats packets with bad checksums as good.

authored-by: Evan Jones <e...@evanjones.ca> Signed-off-by: Evan Jones <e...@evanjones.ca> Cc: Nicolas Dichtel <nicolas.dich...@6wind.com> Cc: Phil Sutter <p...@nwl.cc> Cc: Toshiaki Makita <makita.toshi...@lab.ntt.co.jp> Cc: netdev@vger.kernel.org Cc: linux-ker.

[PATCH] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

authored-by: Evan Jones <e...@evanjones.ca> Signed-off-by: Evan Jones <e...@evanjones.ca> Cc: Nicolas Dichtel <nicolas.dich...@6wind.com> Cc: Phil Sutter <p...@nwl.cc> Cc: Toshiaki Makita <makita.toshi...@lab.ntt.co.jp> Cc: netdev@vger.kernel.org Cc: linux-ker.

Re: [PATCH] veth: don't modify ip-summed; doing so treats packets with bad checksums as good.

path again to see if we missed something, but I'd love input from anyone else! -- Vijay Pandurangan https://www.twitter.com/vijayp http://www.vijayp.ca On Fri, Dec 18, 2015 at 2:00 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > (Cc'ing Eric B and Tom) > > On Fri, Dec 18,