From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18D96C43218 for ; Fri, 26 Apr 2019 15:15:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CCA34206BA for ; Fri, 26 Apr 2019 15:15:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="TVXxyEei" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726537AbfDZPPT (ORCPT ); Fri, 26 Apr 2019 11:15:19 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:38087 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725984AbfDZPPT (ORCPT ); Fri, 26 Apr 2019 11:15:19 -0400 Received: by mail-pl1-f195.google.com with SMTP id f36so1725069plb.5 for ; Fri, 26 Apr 2019 08:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=49mI4iueKvDRnNOSqzxtXDF1j4czG+/w5ODYnDkhBrs=; b=TVXxyEei4LubAtbOuMxEIjWKHIziUbHpPW3Pzd/6sHhR/29CqTn0gIyhiEqimnjgd2 GvPlcWWqvYPyxf9pitF5tUYUKV/lxFvsSn3+ttI2IepMlb+GmjMgL0Rb5jApHoEjAxbs 3XqBvOC3B3fgm5AuRrvZKC1muqdkdN0HHSpkYLYzzdB5j90QokApr+AZ2pl81ysGuQ3D SXfwlao6iud3zYqWHGrAIyYn84UzL2JLFAOnM7iUXmslh3Xw6Bab0pxy7xnDHSyYDPoe 2WtK2JwGXLnlYcQrtnynE7VLayWo+4G0Omtahxl6ns5t604urZwjiTE5ohd+nOA406CH 9p7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=49mI4iueKvDRnNOSqzxtXDF1j4czG+/w5ODYnDkhBrs=; b=h3SWHKsRN5Za7xNUBj7Z9wN+Z9HAHjr4gAE1zb8K1omJfCB+TahSc+vzILJg+1EjU5 YBvb/XLb0Gxz0yi+9bqI6sLpeOBcnTE/qY8XPivWeeCxnZrkyMzayJmbjK1xrC7hk2OL 1p+ve9+58nUe9CoAFsLuPyfFqzjS/Aid0vXelZPNZwRc3966UKhhVgXaEkqp7r8Q79Ec 4imnKV34uZKyuK7IdxSraEEYgcQipgNnanpOBw6MBZyzh3I9Fr5ogfgbim273KD9/A8n DELhsIf9/gjc9J9+YWSGFH+V7V6ed7+LkI1A3KHqriMxkrSrk0qB2shprPp0W9Hp8R2m D7JQ== X-Gm-Message-State: APjAAAXl482Abx+pI5ZZRFoYoF9iJT7bZu7ZGueq6TT9MMtlzcJikxBo 7saf5rZmdiEHd2f187KqMRGHTV4dcxs= X-Google-Smtp-Source: APXvYqyq19N0Idce6SfH6OUH2V6OQelZUMTxw3iTU0iZJ8gfVqpZe7Sk22tg9uttvjceU0hzjaMw5A== X-Received: by 2002:a17:902:854a:: with SMTP id d10mr1406273plo.8.1556291718108; Fri, 26 Apr 2019 08:15:18 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id l10sm55122342pfc.46.2019.04.26.08.15.17 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Apr 2019 08:15:18 -0700 (PDT) Date: Fri, 26 Apr 2019 08:15:11 -0700 From: Stephen Hemminger To: netdev@vger.kernel.org Subject: Fw: [Bug 203433] New: CONFIG_IXGBE_IPSEC forces HW_ACCEL Message-ID: <20190426081511.4011dce0@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Begin forwarded message: Date: Fri, 26 Apr 2019 11:06:27 +0000 From: bugzilla-daemon@bugzilla.kernel.org To: stephen@networkplumber.org Subject: [Bug 203433] New: CONFIG_IXGBE_IPSEC forces HW_ACCEL https://bugzilla.kernel.org/show_bug.cgi?id=203433 Bug ID: 203433 Summary: CONFIG_IXGBE_IPSEC forces HW_ACCEL Product: Networking Version: 2.5 Kernel Version: 5.0.9 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other Assignee: stephen@networkplumber.org Reporter: gheorghe@linux.com Regression: No The IXGBE_IPSEC module doesn't check if the child SA has HW_ACCEL enabled or disabled, causing HW_ACCEL to be always enabled, even if, in some cases, there is no support for it: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c?h=v5.1-rc6#n1085 There should be a check to see if the SA has HW_ACCEL or not, something like this: if (!xs->xso.offload_handle) return 1; I noticed this when running StrongSwan within macvlan networks with Docker, on ArchLinux, on this nic: 82599ES 10-Gigabit SFI/SFP+ Network Connection. The connection is getting established and the packages are sent through the tunnel, but if the IPsec server has some form of NAT (masquerade or SNAT), packages don't get pushed out the 10 GbE device. This can be seen with `tcpdump -n -e -i interface icmp`: 21:51:17.575688 84:b5:9c:c5:77:00 > 02:42:8b:1c:d9:43, ethertype IPv4 (0x0800), length 98: 10.201.0.1 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64 21:51:17.575717 02:42:8b:1c:d9:43 > 84:b5:9c:c5:77:00, ethertype IPv4 (0x0800), length 98: 139.28.217.67 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64 ## Here a reply should be seen, but there is none. On further inspection we determined that packages are not sent out the interface, even if NAT can be seen in the tcpdump. The solution to make IPsec work was to recompile the kernel without CONFIG_IXGBE_IPSEC (which is currently "y" by default on multiple distributions, so we can expect this problem to appear in the future). After this, NAT works for the IPsec connection and ICMP reply can be seen with tcpdump on the interface: 84:b5:9c:c5:77:00 > 02:42:8b:1c:d9:43, ethertype IPv4 (0x0800), length 98: 10.201.0.1 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64 02:42:8b:1c:d9:43 > 84:b5:9c:c5:77:00, ethertype IPv4 (0x0800), length 98: 139.28.217.67 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64 84:b5:9c:c5:77:00 > 02:42:8b:1c:d9:43, ethertype IPv4 (0x0800), length 98: 9.9.9.9 > 139.28.217.67: ICMP echo reply, id 10752, seq 1, length 64 Steps to reproduce 1. create an IPsec connection, without HW offload (StrongSwan has it off by default, and it can also assign VIPs) 2. add masquerade for the VIPs, to go out the IXGBE nic. 3. tcpdump on the server and ping from the client If I can help in any way on this case, please let me know. -- You are receiving this mail because: You are the assignee for the bug.