Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp434073imu; Thu, 3 Jan 2019 00:12:58 -0800 (PST) X-Google-Smtp-Source: ALg8bN7RL2cNgnnZebc4ek21bykp1UtY9pnYCx0XO8ihW8Izs33v+6eCmC478LWy+ux34HERKc+M X-Received: by 2002:a17:902:20e9:: with SMTP id v38mr3573132plg.250.1546503178500; Thu, 03 Jan 2019 00:12:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546503178; cv=none; d=google.com; s=arc-20160816; b=vYsIfEF+OE0gf8zgXjuLzNrQjEXnQOOOiGra0Yveobrd35aF082abY/Xh+EP7RA0jw XF9kUPRShFHTvKM0rviwNsC7wY3a+sSZvysBpRZd9ftZksrnSlXYGoaTbKqFVJuMNDY8 6o46KNcm51Yw78iHWthxDfUMa6DoVRhOCRiDsB3SCufdDAuVdfuXwARvBoECxIBncL00 lPRDFG5loNsULvEjdIkXjlDWMNRh8GAoqjEBbK6On9vYvkUg6EGZVneWbRHZmddDOxaO UUplI7kq+lMrXnq9bNP2OyvfKlUbZAADfXmtKi+m0PYsyhaJ0OXIK71lQZ4azr4EUmXu fW2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=2wEgTzfPkp4zHKC9sHx/2j5NgYrBSoD9iovM+uPHOrg=; b=M8WlOr29GrvdWAniT94eE1h+GBJeVvonV18apNbQzUdJy/NLa43dX1GRUuxTclA5Iz 7T2EM3Kraurx0s+/dtWBbezrjZrx8a8iq2vdrDBap+asLNgA4spJXLqkM7LNwD2PGvLb 87TdwVzslYgU+a1ooo3v6yI65aMXmPx+HH+O8IVWOihJfWpONKfR+qTSHKX26a6Pyn/t 0O7zuxj4hpHVtvdvmcfX+PaxPlPvKgnPOWYQXs+u6LqyLOnCGAN8FxKOjHvPK1aC5PHG BhojKFqi2/MURMwtISD4VjCnHyD2lEOklq5nfUKG1ORH8VQBHaJGU2QsrBKyOvcpsWeo 02Ew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j5si1886262pfg.254.2019.01.03.00.12.19; Thu, 03 Jan 2019 00:12:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727371AbfACDUO (ORCPT + 99 others); Wed, 2 Jan 2019 22:20:14 -0500 Received: from mail.cn.fujitsu.com ([183.91.158.132]:52392 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726136AbfACDUN (ORCPT ); Wed, 2 Jan 2019 22:20:13 -0500 X-IronPort-AV: E=Sophos;i="5.56,433,1539619200"; d="scan'208";a="51178885" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 03 Jan 2019 11:20:11 +0800 Received: from G08CNEXCHPEKD03.g08.fujitsu.local (unknown [10.167.33.85]) by cn.fujitsu.com (Postfix) with ESMTP id 667424B7D550; Thu, 3 Jan 2019 11:20:11 +0800 (CST) Received: from ubuntu.g08.fujitsu.local (10.167.225.53) by G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 3 Jan 2019 11:20:18 +0800 From: Su Yanjun To: , , , , CC: , , , Subject: [PATCH] vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel Date: Thu, 3 Jan 2019 07:48:41 -0500 Message-ID: <1546519721-30837-1-git-send-email-suyj.fnst@cn.fujitsu.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.167.225.53] X-yoursite-MailScanner-ID: 667424B7D550.ACE21 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: suyj.fnst@cn.fujitsu.com X-Spam-Status: No Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Recently we run a network test over ipcomp virtual tunnel.We find that if a ipv4 packet needs fragment, then the peer can't receive it. We deep into the code and find that when packet need fragment the smaller fragment will be encapsulated by ipip not ipcomp. So when the ipip packet goes into xfrm, it's skb->dev is not properly set. The ipv4 reassembly code always set skb'dev to the last fragment's dev. After ipv4 defrag processing, when the kernel rp_filter parameter is set, the skb will be drop by -EXDEV error. This patch adds compatible support for the ipip process in ipcomp virtual tunnel. Signed-off-by: Su Yanjun --- net/ipv4/ip_vti.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c index de31b30..63de2f6 100644 --- a/net/ipv4/ip_vti.c +++ b/net/ipv4/ip_vti.c @@ -65,6 +65,9 @@ static int vti_input(struct sk_buff *skb, int nexthdr, __be32 spi, XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip4 = tunnel; + if (iph->protocol == IPPROTO_IPIP) + skb->dev = tunnel->dev; + return xfrm_input(skb, nexthdr, spi, encap_type); } @@ -76,10 +79,15 @@ static int vti_input(struct sk_buff *skb, int nexthdr, __be32 spi, static int vti_rcv(struct sk_buff *skb) { + __be32 spi = 0; + XFRM_SPI_SKB_CB(skb)->family = AF_INET; XFRM_SPI_SKB_CB(skb)->daddroff = offsetof(struct iphdr, daddr); + + if (ip_hdr(skb)->protocol == IPPROTO_IPIP) + spi = ip_hdr(skb)->saddr; - return vti_input(skb, ip_hdr(skb)->protocol, 0, 0); + return vti_input(skb, ip_hdr(skb)->protocol, spi, 0); } static int vti_rcv_cb(struct sk_buff *skb, int err) @@ -429,6 +437,12 @@ static struct xfrm4_protocol vti_ipcomp4_protocol __read_mostly = { .priority = 100, }; +static struct xfrm_tunnel ipip_handler __read_mostly = { + .handler = vti_rcv, + .err_handler = vti4_err, + .priority = 0, +}; + static int __net_init vti_init_net(struct net *net) { int err; @@ -597,6 +611,13 @@ static int __init vti_init(void) if (err < 0) goto xfrm_proto_comp_failed; + msg = "ipip tunnel"; + err = xfrm4_tunnel_register(&ipip_handler, AF_INET); + if (err < 0) { + pr_info("%s: cant't register tunnel\n",__func__); + goto xfrm_tunnel_failed; + } + msg = "netlink interface"; err = rtnl_link_register(&vti_link_ops); if (err < 0) @@ -606,6 +627,8 @@ static int __init vti_init(void) rtnl_link_failed: xfrm4_protocol_deregister(&vti_ipcomp4_protocol, IPPROTO_COMP); +xfrm_tunnel_failed: + xfrm4_tunnel_deregister(&ipip_handler, AF_INET); xfrm_proto_comp_failed: xfrm4_protocol_deregister(&vti_ah4_protocol, IPPROTO_AH); xfrm_proto_ah_failed: -- 2.7.4