netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: netdev <netdev@vger.kernel.org>, ej@evanjones.ca, vijayp@vijayp.ca
Cc: Cong Wang <cwang@twopensource.com>
Subject: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."
Date: Thu, 24 Mar 2016 15:01:58 -0700	[thread overview]
Message-ID: <56F463D6.7080406@candelatech.com> (raw)

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 connection
(using policy based routing to ensure frames are sent on the appropriate
interfaces).

This is user-space only app, and kernel in this case is completely unmodified.

The commit below breaks this feature:  UDP frames are sniffed on both a and d ports
(in both directions), but the UDP socket does not receive frames.

Using normal ethernet ports, this network emulation feature works fine, so it is
specific to VETH.

A similar test with just sending UDP between a single veth pair:  e <-> f
works fine.  Maybe it has something to do with raw packets?


The patch below is the culprit:


[greearb@ben-dt3 linux-2.6]$ git bisect bad
ce8c839b74e3017996fad4e1b7ba2e2625ede82f is the first bad commit
commit ce8c839b74e3017996fad4e1b7ba2e2625ede82f
Author: Vijay Pandurangan <vijayp@vijayp.ca>
Date:   Fri Dec 18 14:34:59 2015 -0500

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

     Packets that arrive from real hardware devices have ip_summed ==
     CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
     CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
     current version of veth will replace CHECKSUM_NONE with
     CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
     a veth device to be delivered to the application. This caused applications
     at Twitter to receive corrupt data when network hardware was corrupting
     packets.

...

diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 0ef4a5a..ba21d07 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -117,12 +117,6 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
                 kfree_skb(skb);
                 goto drop;
         }
-       /* don't change ip_summed == CHECKSUM_PARTIAL, as that
-        * will cause bad checksum on forwarded packets
-        */
-       if (skb->ip_summed == CHECKSUM_NONE &&
-           rcv->features & NETIF_F_RXCSUM)
-               skb->ip_summed = CHECKSUM_UNNECESSARY;

         if (likely(dev_forward_skb(rcv, skb) == NET_RX_SUCCESS)) {
                 struct pcpu_vstats *stats = this_cpu_ptr(dev->vstats);


Any suggestions for how to fix this so that I get the old working behaviour and
the bug this patch was trying to fix is also resolved?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

             reply	other threads:[~2016-03-24 22:02 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-24 22:01 Ben Greear [this message]
     [not found] ` <CAKUBDd91rR7QTwCO6L6ZfRe4fuHw0L5+Zi7qm0uF018dwVGCLg@mail.gmail.com>
2016-03-24 22:57   ` veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good." Ben Greear
2016-03-24 23:56 ` Cong Wang
2016-03-25  0:06   ` Ben Greear
2016-03-25  1:11     ` Ben Greear
2016-03-25  1:13       ` Ben Greear
2016-03-25  1:44         ` Vijay Pandurangan
2016-03-25  4:34           ` Ben Greear
2016-03-25  4:41             ` Vijay Pandurangan
2016-03-25  4:45               ` Vijay Pandurangan
2016-03-25  5:07                 ` Ben Greear
2016-03-25  5:24                   ` Vijay Pandurangan
2016-03-25 14:35                     ` Ben Greear
2016-03-25 21:51                       ` Vijay Pandurangan
2016-03-25  5:06             ` Cong Wang
2016-03-25  5:13               ` Ben Greear
2016-03-25  5:33                 ` Cong Wang
2016-03-25 16:10                   ` Ben Greear
2016-03-25 16:32                     ` Cong Wang
2016-03-25 16:45                       ` David Miller
2016-03-25 16:44                     ` David Miller
2016-03-25 17:14                       ` Ben Greear
2016-03-25 19:00                         ` David Miller
2016-03-25 20:56                   ` Ben Greear
2016-03-25 21:59                     ` Vijay Pandurangan
2016-03-25 22:23                       ` Ben Greear
2016-03-25 23:03                         ` Vijay Pandurangan
2016-03-25 23:46                           ` Ben Greear
2016-04-07 15:11                             ` Vijay Pandurangan
2016-04-07 18:32                               ` Ben Greear
2016-03-25 22:23                       ` Cong Wang
2016-03-25 22:16                     ` Cong Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56F463D6.7080406@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=cwang@twopensource.com \
    --cc=ej@evanjones.ca \
    --cc=netdev@vger.kernel.org \
    --cc=vijayp@vijayp.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).