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

On 04/07/2016 08:11 AM, Vijay Pandurangan wrote: 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

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 03/25/2016 04:03 PM, Vijay Pandurangan wrote: On Fri, Mar 25, 2016 at 6:23 PM, Ben Greear 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 --> veth

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 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 --> veth --> process b >> >> II) process a ->

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

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 --> veth --> process b II) process a -> eth -> wire -> eth -> process b I believe (I) is the simplest setup we can create that will

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 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

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:56 PM, Ben Greear wrote: > On 03/24/2016 10:33 PM, Cong Wang wrote: > >> Here we go: >> >> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c >> index 1ecfa71..ab66080 100644 >> --- a/net/packet/af_packet.c >> +++

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 wrote: > > > On 03/24/2016 10:24 PM, Vijay Pandurangan wrote: >> >> On Fri, Mar 25, 2016 at 1:07 AM, Ben Greear >> wrote: >>> >>> On 03/24/2016 09:45 PM, Vijay Pandurangan wrote:

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

On 03/24/2016 10:33 PM, Cong Wang wrote: Here we go: diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index 1ecfa71..ab66080 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -1925,6 +1925,7 @@ static int packet_sendmsg_spkt(struct socket *sock, struct msghdr

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

From: Ben Greear Date: Fri, 25 Mar 2016 10:14:46 -0700 > Anyway, you know the stack and drivers better than me, so if you > think Cong's patch is valid, then I'll test it and make sure it > works in my setups at least. It probably is, I'm just waiting to see if Tom

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

On 03/25/2016 09:44 AM, David Miller wrote: From: Ben Greear Date: Fri, 25 Mar 2016 09:10:58 -0700 I am suspicious that this will break at least some drivers. I grepped around for ip_summed, and found this, for instance: davicom/dm9000.c /* The DM9000 is

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

From: Cong Wang Date: Fri, 25 Mar 2016 09:32:23 -0700 > So I believe dm9000 needs to fix. +1

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

From: Ben Greear Date: Fri, 25 Mar 2016 09:10:58 -0700 > I am suspicious that this will break at least some drivers. I > grepped around for ip_summed, and found this, for instance: > > davicom/dm9000.c > > /* The DM9000 is not smart enough to leave fragmented

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

On Fri, Mar 25, 2016 at 9:10 AM, Ben Greear wrote: > I am suspicious that this will break at least some drivers. I grepped > around > for ip_summed, and found this, for instance: > > davicom/dm9000.c > > /* The DM9000 is not smart enough to leave fragmented

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

On 03/24/2016 10:33 PM, Cong Wang wrote: On Thu, Mar 24, 2016 at 10:13 PM, Ben Greear wrote: On 03/24/2016 10:06 PM, Cong Wang wrote: On Thu, Mar 24, 2016 at 9:34 PM, Ben Greear wrote: On 03/24/2016 06:44 PM, Vijay Pandurangan wrote:

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

On 03/24/2016 10:24 PM, Vijay Pandurangan wrote: On Fri, Mar 25, 2016 at 1:07 AM, Ben Greear 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

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

On Thu, Mar 24, 2016 at 10:13 PM, Ben Greear wrote: > > > On 03/24/2016 10:06 PM, Cong Wang wrote: >> >> On Thu, Mar 24, 2016 at 9:34 PM, Ben Greear >> wrote: >>> >>> >>> >>> On 03/24/2016 06:44 PM, Vijay Pandurangan wrote: Oops, I

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 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 hit the >> application level. >

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

On 03/24/2016 10:06 PM, Cong Wang wrote: On Thu, Mar 24, 2016 at 9:34 PM, Ben Greear 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

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

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 hit the application level. VETH is pretty special in that when you transmit a frame on one device, it's pair

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

On Thu, Mar 24, 2016 at 9:34 PM, Ben Greear 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

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 wrote: > agreed. It should maybe be set to CHECKSUM_UNNECESSARY. The

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

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:

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 and UDP4 checksums are set correctly in the packet? If

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: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

On 03/24/2016 06:11 PM, Ben Greear wrote: On 03/24/2016 05:06 PM, Ben Greear wrote: On 03/24/2016 04:56 PM, Cong Wang wrote: On Thu, Mar 24, 2016 at 3:01 PM, Ben Greear wrote: I have an application that creates two pairs of veth devices. a <-> b c <-> d b and

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

On 03/24/2016 05:06 PM, Ben Greear wrote: On 03/24/2016 04:56 PM, Cong Wang wrote: On Thu, Mar 24, 2016 at 3:01 PM, Ben Greear wrote: I have an application that creates two pairs of veth devices. a <-> b c <-> d b and c have a raw packet socket opened on them

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

On 03/24/2016 04:56 PM, Cong Wang wrote: On Thu, Mar 24, 2016 at 3:01 PM, Ben Greear wrote: I have an application that creates two pairs of veth devices. a <-> b c <-> d b and c have a raw packet socket opened on them and I 'bridge' frames between b and c to

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

On Thu, Mar 24, 2016 at 3:01 PM, Ben Greear wrote: > I have an application that creates two pairs of veth devices. > > a <-> b c <-> d > > b and c have a raw packet socket opened on them and I 'bridge' frames > between b and c to provide network emulation (ie,

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

On 03/24/2016 03:49 PM, Vijay Pandurangan wrote: Hmm that's troubling. We tested various UDP configurations but I don't think we tested this setup. Do you have code or more specific instructions we can use to replicate this bug? The user-space app is not open source, and the routing setup is

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

I have an application that creates two pairs of veth devices. a <-> b c <-> d b and c have a raw packet socket opened on them and I 'bridge' frames between b and c to provide network emulation (ie, configurable delay). I put IP 1.1.1.1/24 on a, 1.1.1.2/24 on d, and then create a UDP