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
next 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).