[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpUEdfeKNQzu2v74YR8Srezw11aYiTqQ0w_foaoBr4mQug@mail.gmail.com>
Date: Fri, 25 Mar 2016 15:23:12 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Vijay Pandurangan <vijayp@...ayp.ca>
Cc: Ben Greear <greearb@...delatech.com>,
netdev <netdev@...r.kernel.org>, Evan Jones <ej@...njones.ca>,
Cong Wang <cwang@...pensource.com>
Subject: Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."
On Fri, Mar 25, 2016 at 2:59 PM, Vijay Pandurangan <vijayp@...ayp.ca> wrote:
> 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 contain UDP packets to process b, what
> is the behaviour we want if the UDP packet *has an incorrect
> checksum*?
>
> It seems to me that I and II should have identical behaviour, and I
> would think that (II) would not deliver the packets to the
> application.
>
> In (I) with Cong's patch would we be delivering corrupt UDP packets to
> process b despite an incorrect checksum in (I)?
>
Right, I thought packet socket does the checksum by itself, so the
problem is: if user-space does the checksum like packet socket, its
checksum could be wrong therefore we can not trust it on RX path
once it loops back.
Let me think about it again.
Powered by blists - more mailing lists