From patchwork Thu Jan 26 13:44:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 9539281 X-Patchwork-Delegate: kvalo@adurom.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0796A60429 for ; Thu, 26 Jan 2017 13:46:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E802A28174 for ; Thu, 26 Jan 2017 13:46:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DCC8B282EC; Thu, 26 Jan 2017 13:46:19 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D14F428174 for ; Thu, 26 Jan 2017 13:46:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752334AbdAZNp7 (ORCPT ); Thu, 26 Jan 2017 08:45:59 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:32868 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752208AbdAZNpB (ORCPT ); Thu, 26 Jan 2017 08:45:01 -0500 Received: by mail-pg0-f65.google.com with SMTP id 194so22443911pgd.0; Thu, 26 Jan 2017 05:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=oz2oYPPu7YxapCT679Al7doOjQQIC9H1DLXxFmnc+cE=; b=UOEZ2ibeq537BF8hqhVOb+U36n48fwIUJmEIn8iO2RQYbuESN7rQruBxGY2cuvd0tm Obv8mXIE+9y5LrOJmTQqpI4I9b4bIUFJVv4beCrLap4tNw6x7jxXV8tuaDTSFgHaTr28 udXldJ0Q053dQBeI8ydvUefDFso2nBvb68pgjNqZquwsUoY4x92bBv7btGrNsyE5EfGt 3iAJcbb1UwUC+mi0pfiMJM3a+mW1Zm8vp83ZELm3wdFFVwLNvXuW6YjaZ8bkm+G88W/U qcSXzZYb4rNOiovab/MH2vHjFQclhzd7janFSGCP5nYXNWInDUIsKultww8VTQkcIqVQ nfsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=oz2oYPPu7YxapCT679Al7doOjQQIC9H1DLXxFmnc+cE=; b=KihJdWJv8fEYCelP3P3kHLKxmHhKCX7jKXMDpN9MqlHYiuXCvzizyYLj45iwRVaVD1 YBhURRadoF8yxPX/nz23uH1MFNqoLPPwdZ3qq48UxOzc1DdmWmyTkDVBpyGVUN0q4EZJ JMKm4DwxeIQUXZqPA040178Ax0D7o5Lzpb53WeX5Q8/Zhi3fshuzM7/4cQ1zU4SgcjzX 825jgEOsm5Zy7CuJ5gMCQ+P5n5pwKjF8N5GkEfyU8rvy+4jhYlOeNm5g+77coDJAGN/t 6JLUL7zUSTLttkRHdt8DrO6fwmCX3LE5bt+IItcjAL4Uahj2X7rnckO0rLmnXkdt9Tpq 0MTg== X-Gm-Message-State: AIkVDXKxb8JOfYDvJnhCSP8CCTF9OFE0ANPkLDwhhr5aX637gUGLrVIC30FeA2JYStYhpQ== X-Received: by 10.99.193.17 with SMTP id w17mr3209389pgf.124.1485438300633; Thu, 26 Jan 2017 05:45:00 -0800 (PST) Received: from [192.168.86.171] (c-73-231-122-98.hsd1.ca.comcast.net. [73.231.122.98]) by smtp.googlemail.com with ESMTPSA id p15sm3805290pfk.58.2017.01.26.05.44.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 05:45:00 -0800 (PST) Message-ID: <1485438299.5145.117.camel@edumazet-glaptop3.roam.corp.google.com> Subject: Re: IPv6-UDP 0x0000 checksum From: Eric Dumazet To: Johannes Berg Cc: netdev@vger.kernel.org, linux-wireless Date: Thu, 26 Jan 2017 05:44:59 -0800 In-Reply-To: <1485437276.14760.3.camel@sipsolutions.net> References: <1485437276.14760.3.camel@sipsolutions.net> X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, 2017-01-26 at 14:27 +0100, Johannes Berg wrote: > Hi, > > It looks like right now we may have a hardware bug and accept 0x0000 as > valid, when the outcome of the calculation is 0xffff. > > What do you think we should do about this? > > We could ignore the issue entirely, since 0 wasn't ever supposed to be > sent anyway - but then we don't drop frames that we should drop. I > didn't manage to find the code in the IPv6/UDP stack that even does > that, but I assume it's there somewhere. > > Alternatively, we could parse the packet to find the checksum inside, > and if it's 0 then don't report CHECKSUM_UNNECESSARY, but that seems > rather expensive/difficult due to the IPv6 variable header and all > that. If we wanted to go this route, are there any helper functions for > this? > > Unfortunately, in the current devices, we neither have a complete > indication that the packet was even UDP-IPv6, nor do we have the raw > csum or anything like that. I think they're adding that to the next > hardware spin, but we probably need to address this issue now. > > johannes Hi Johannes I am afraid information is missing. Is this a xmit or rcv problem ? I recently fixed an issue, could this be this ? commit 4f2e4ad56a65f3b7d64c258e373cb71e8d2499f4 Author: Eric Dumazet Date: Sat Oct 29 11:02:36 2016 -0700 net: mangle zero checksum in skb_checksum_help() Sending zero checksum is ok for TCP, but not for UDP. UDPv6 receiver should by default drop a frame with a 0 checksum, and UDPv4 would not verify the checksum and might accept a corrupted packet. Simply replace such checksum by 0xffff, regardless of transport. This error was caught on SIT tunnels, but seems generic. Signed-off-by: Eric Dumazet Cc: Maciej Żenczykowski Cc: Willem de Bruijn Acked-by: Maciej Żenczykowski Signed-off-by: David S. Miller diff --git a/net/core/dev.c b/net/core/dev.c index 820bac239738eb021354ac95ca5bbdff1840cb8e..eaad4c28069ff523ac784bf2dffd0acff82341a0 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2484,7 +2484,7 @@ int skb_checksum_help(struct sk_buff *skb) goto out; } - *(__sum16 *)(skb->data + offset) = csum_fold(csum); + *(__sum16 *)(skb->data + offset) = csum_fold(csum) ?: CSUM_MANGLED_0; out_set_summed: skb->ip_summed = CHECKSUM_NONE; out: