netdev - Re: [PATCH bpf-next 1/2] selftest/bpf: add missed ip6ip6 test back

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201104184034.c2fse6kj2nwer3kv@kafai-mbp.dhcp.thefacebook.com>
Date:   Wed, 4 Nov 2020 10:40:34 -0800
From:   Martin KaFai Lau <kafai@...com>
To:     Hangbin Liu <liuhangbin@...il.com>
CC:     <netdev@...r.kernel.org>, William Tu <u9012063@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>, <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/2] selftest/bpf: add missed ip6ip6 test back

On Tue, Nov 03, 2020 at 12:29:07PM +0800, Hangbin Liu wrote:
> In comment 173ca26e9b51 ("samples/bpf: add comprehensive ipip, ipip6,
> ip6ip6 test") we added ip6ip6 test for bpf tunnel testing. But in commit
> 933a741e3b82 ("selftests/bpf: bpf tunnel test.") when we moved it to
> the current folder, we didn't add it.
> 
> This patch add the ip6ip6 test back to bpf tunnel test. Since the
> underlay network is the same, we can reuse the ipip6 framework directly.
> Iperf test is removed as currect framework simplified it in purpose.
> 
> Signed-off-by: Hangbin Liu <liuhangbin@...il.com>
> ---
>  tools/testing/selftests/bpf/test_tunnel.sh | 39 ++++++++++++++++++++--
>  1 file changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/bpf/test_tunnel.sh b/tools/testing/selftests/bpf/test_tunnel.sh
> index bd12ec97a44d..76a00d2ef988 100755
> --- a/tools/testing/selftests/bpf/test_tunnel.sh
> +++ b/tools/testing/selftests/bpf/test_tunnel.sh
> @@ -24,12 +24,12 @@
>  # Root namespace with metadata-mode tunnel + BPF
>  # Device names and addresses:
>  # 	veth1 IP: 172.16.1.200, IPv6: 00::22 (underlay)
> -# 	tunnel dev <type>11, ex: gre11, IPv4: 10.1.1.200 (overlay)
> +# 	tunnel dev <type>11, ex: gre11, IPv4: 10.1.1.200, IPv6: 1::22 (overlay)
>  #
>  # Namespace at_ns0 with native tunnel
>  # Device names and addresses:
>  # 	veth0 IPv4: 172.16.1.100, IPv6: 00::11 (underlay)
> -# 	tunnel dev <type>00, ex: gre00, IPv4: 10.1.1.100 (overlay)
> +# 	tunnel dev <type>00, ex: gre00, IPv4: 10.1.1.100, IPv6: 1::11 (overlay)
>  #
>  #
>  # End-to-end ping packet flow
> @@ -262,11 +262,13 @@ add_ipip6tnl_tunnel()
>  		ip link add dev $DEV_NS type $TYPE \
>  		local ::11 remote ::22
>  	ip netns exec at_ns0 ip addr add dev $DEV_NS 10.1.1.100/24
> +	ip netns exec at_ns0 ip addr add dev $DEV_NS 1::11/96
>  	ip netns exec at_ns0 ip link set dev $DEV_NS up
>  
>  	# root namespace
>  	ip link add dev $DEV type $TYPE external
>  	ip addr add dev $DEV 10.1.1.200/24
> +	ip addr add dev $DEV 1::22/96
>  	ip link set dev $DEV up
>  }
>  
> @@ -553,6 +555,34 @@ test_ipip6()
>          echo -e ${GREEN}"PASS: $TYPE"${NC}
>  }
>  
> +test_ip6ip6()
> +{
> +	TYPE=ip6tnl
> +	DEV_NS=ip6ip6tnl00
> +	DEV=ip6ip6tnl11
> +	ret=0
> +
> +	check $TYPE
> +	config_device
> +	add_ipip6tnl_tunnel
> +	ip link set dev veth1 mtu 1500
> +	attach_bpf $DEV ipip6_set_tunnel ipip6_get_tunnel
>From looking at the ipip6_set_tunnel in test_tunnel_kern.c.
I don't think they are testing an ip6ip6 packet.
If the intention is to test ip6ip6, why the existing
ip6ip6_set_tunnel does not need to be exercised?

> +	# underlay
> +	ping6 $PING_ARG ::11
> +	# ip6 over ip6
> +	ping6 $PING_ARG 1::11
> +	check_err $?
> +	ip netns exec at_ns0 ping6 $PING_ARG 1::22
> +	check_err $?
> +	cleanup
> +
> +	if [ $ret -ne 0 ]; then
> +                echo -e ${RED}"FAIL: ip6$TYPE"${NC}
> +                return 1
> +        fi
> +        echo -e ${GREEN}"PASS: ip6$TYPE"${NC}
> +}