From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shannon Nelson Subject: Re: [PATCH net-next 0/2] fixes for ipsec selftests Date: Thu, 21 Jun 2018 10:25:24 -0700 Message-ID: References: <1529473363-4036-1-git-send-email-shannon.nelson@oracle.com> <6134e116-13c5-ee9d-e539-35679efcd665@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Networking , David Miller To: Anders Roxell Return-path: Received: from userp2120.oracle.com ([156.151.31.85]:54574 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932508AbeFURZ3 (ORCPT ); Thu, 21 Jun 2018 13:25:29 -0400 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 6/21/2018 9:56 AM, Anders Roxell wrote: > On Thu, 21 Jun 2018 at 02:32, Shannon Nelson wrote: >> >> On 6/20/2018 4:18 PM, Anders Roxell wrote: >>> On Thu, 21 Jun 2018 at 00:26, Shannon Nelson wrote: >>>> >>>> On 6/20/2018 12:09 PM, Anders Roxell wrote: >>>>> On Wed, 20 Jun 2018 at 07:42, Shannon Nelson wrote: >>>>>> >>>>>> A couple of bad behaviors in the ipsec selftest were pointed out >>>>>> by Anders Roxell and are addressed here. >>>>>> >>>>>> Shannon Nelson (2): >>>>>> selftests: rtnetlink: hide complaint from terminated monitor >>>>>> selftests: rtnetlink: use a local IP address for IPsec tests >>>>>> >>>>>> tools/testing/selftests/net/rtnetlink.sh | 11 +++++++---- >>>>>> 1 file changed, 7 insertions(+), 4 deletions(-) >>>>>> >>>>>> -- >>>>>> 2.7.4 >>>>>> >>>>> >>>>> Hi Shannon, >>>>> >>>>> With this patches applied and my config patch. >>>>> >>>>> I still get this error when I run the ipsec test: >>>>> >>>>> FAIL: can't add fou port 7777, skipping test >>>>> RTNETLINK answers: Operation not supported >>>>> FAIL: can't add macsec interface, skipping test >>>>> RTNETLINK answers: Protocol not supported >>>>> RTNETLINK answers: No such process >>>>> RTNETLINK answers: No such process >>>>> FAIL: ipsec >>>> >>>> One of the odd things I noticed about this script is that there really >>>> aren't any diagnosis messages, just PASS or FAIL. I followed this >>>> custom when I added the ipsec tests, but I think this is something that >>>> should change so we can get some idea of what breaks. >>>> >>>> I'm curious about the "RTNETLINK answers" messages and where they might >>>> be coming from, especially "RTNETLINK answers: Protocol not supported". >>> >>> I added: "set -x" in the beginning of the rtnetlink.sh script. >>> + ip x s add proto esp src 10.66.17.140 dst 10.66.17.141 spi 0x07 mode >>> transport reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' >>> 0x3132333435 >>> 363738393031323334353664636261 128 sel src 10.66.17.140/24 dst 10.66.17.141/24 >>> RTNETLINK answers: Protocol not supported >> >> Okay, so ip didn't like this command... >> >>>> What are the XFRM and AES settings in your kernel config - what is the >>>> output from >>>> egrep -i "xfrm|_aes" .config >>> >>> CONFIG_XFRM=y >>> CONFIG_XFRM_ALGO=y >>> CONFIG_XFRM_USER=y >>> CONFIG_INET_XFRM_MODE_TUNNEL=y >>> CONFIG_INET6_XFRM_MODE_TRANSPORT=y >>> CONFIG_INET6_XFRM_MODE_TUNNEL=y >>> CONFIG_INET6_XFRM_MODE_BEET=y >>> CONFIG_CRYPTO_AES=y >> >> And this is probably why - there seem to be a few config variables >> missing, including CONFIG_INET_XFRM_MODE_TRANSPORT, which might be why >> the ip command fails above. >> >> Here's what I have in my config: >> CONFIG_XFRM=y >> CONFIG_XFRM_OFFLOAD=y >> CONFIG_XFRM_ALGO=m >> CONFIG_XFRM_USER=m >> # CONFIG_XFRM_SUB_POLICY is not set >> # CONFIG_XFRM_MIGRATE is not set >> CONFIG_XFRM_STATISTICS=y >> CONFIG_XFRM_IPCOMP=m >> CONFIG_INET_XFRM_TUNNEL=m >> CONFIG_INET_XFRM_MODE_TRANSPORT=m >> CONFIG_INET_XFRM_MODE_TUNNEL=m >> CONFIG_INET_XFRM_MODE_BEET=m >> CONFIG_INET6_XFRM_TUNNEL=m >> CONFIG_INET6_XFRM_MODE_TRANSPORT=m >> CONFIG_INET6_XFRM_MODE_TUNNEL=m >> CONFIG_INET6_XFRM_MODE_BEET=m >> CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m >> CONFIG_SECURITY_NETWORK_XFRM=y >> CONFIG_CRYPTO_AES=y >> # CONFIG_CRYPTO_AES_TI is not set >> CONFIG_CRYPTO_AES_X86_64=m >> CONFIG_CRYPTO_AES_NI_INTEL=m >> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m >> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m >> CONFIG_CRYPTO_DEV_PADLOCK_AES=m >> >> Can I talk you into adding CONFIG_INET_XFRM_MODE_TRANSPORT to your >> config > > Yes you can. > >> and trying again? > > same issue with CONFIG_INET_XFRM_MODE_TRANSPORT=y Interesting. I took only CONFIG_INET_XFRM_MODE_TRANSPORT out of my config and was able to see the "Protocol not supported" message. I'm not familiar enough with the crypto algorithm setup, but I suspect there's a combination of the other missing CONFIGs that are needed along with CONFIG_INET_XFRM_MODE_TRANSPORT. My knee-jerk reaction voice wants to say this is the test working as expected, pointing out to us that the kernel config is not up to what it should be. However, perhaps a better answer is that the test should be reworked to just skip the rest if it can't set up the expected test environment, as is done in the macsec case. So the remaining question then is should the test be marked as failed, as in the macsec test if it can't set up it's interface, or just skipped? sln > > Cheers, > Anders >