All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH bpf-next] bpf: test_tc_tunnel.sh needs reverse path filtering disabled
@ 2019-03-25  9:36 ` alan.maguire
  0 siblings, 0 replies; 9+ messages in thread
From: Alan Maguire @ 2019-03-25  9:36 UTC (permalink / raw)
  To: willemdebruijn.kernel, shuah, ast, daniel, kafai, songliubraving,
	yhs, linux-kselftest, netdev, bpf

test_tc_tunnel.sh sets up a pair of namespaces connected by a
veth pair to verify encap/decap using bpf_skb_adjust_room.  In
testing this, it uses tunnel links as the peer of the bpf-based
encap/decap.  However because the same IP header is used for inner
and outer IP, when packets arrive at the tunnel interface they will
be dropped by reverse path filtering as those packets are expected
on the veth interface (where the destination IP of the decapped
packet is configured).

To avoid this, ensure reverse path filtering is disabled for the
namespace using tunneling.

Fixes: 98cdabcd0798 ("selftests/bpf: bpf tunnel encap test")
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
---
 tools/testing/selftests/bpf/test_tc_tunnel.sh | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/testing/selftests/bpf/test_tc_tunnel.sh b/tools/testing/selftests/bpf/test_tc_tunnel.sh
index dcf3206..c805adb 100755
--- a/tools/testing/selftests/bpf/test_tc_tunnel.sh
+++ b/tools/testing/selftests/bpf/test_tc_tunnel.sh
@@ -160,6 +160,14 @@ server_listen
 # client can connect again
 ip netns exec "${ns2}" ip link add dev testtun0 type "${tuntype}" \
 	remote "${addr1}" local "${addr2}"
+# Because packets are decapped by the tunnel they arrive on testtun0 from
+# the IP stack perspective.  Ensure reverse path filtering is disabled
+# otherwise we drop the TCP SYN as arriving on testtun0 instead of the
+# expected veth2 (veth2 is where 192.168.1.2 is configured).
+ip netns exec "${ns2}" sysctl -qw net.ipv4.conf.all.rp_filter=0
+# rp needs to be disabled for both all and testtun0 as the rp value is
+# selected as the max of the "all" and device-specific values.
+ip netns exec "${ns2}" sysctl -qw net.ipv4.conf.testtun0.rp_filter=0
 ip netns exec "${ns2}" ip link set dev testtun0 up
 echo "test bpf encap with tunnel device decap"
 client_connect
-- 
1.8.3.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH bpf-next] bpf: test_tc_tunnel.sh needs reverse path filtering disabled
@ 2019-03-25  9:36 ` alan.maguire
  0 siblings, 0 replies; 9+ messages in thread
From: alan.maguire @ 2019-03-25  9:36 UTC (permalink / raw)


test_tc_tunnel.sh sets up a pair of namespaces connected by a
veth pair to verify encap/decap using bpf_skb_adjust_room.  In
testing this, it uses tunnel links as the peer of the bpf-based
encap/decap.  However because the same IP header is used for inner
and outer IP, when packets arrive at the tunnel interface they will
be dropped by reverse path filtering as those packets are expected
on the veth interface (where the destination IP of the decapped
packet is configured).

To avoid this, ensure reverse path filtering is disabled for the
namespace using tunneling.

Fixes: 98cdabcd0798 ("selftests/bpf: bpf tunnel encap test")
Signed-off-by: Alan Maguire <alan.maguire at oracle.com>
---
 tools/testing/selftests/bpf/test_tc_tunnel.sh | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/testing/selftests/bpf/test_tc_tunnel.sh b/tools/testing/selftests/bpf/test_tc_tunnel.sh
index dcf3206..c805adb 100755
--- a/tools/testing/selftests/bpf/test_tc_tunnel.sh
+++ b/tools/testing/selftests/bpf/test_tc_tunnel.sh
@@ -160,6 +160,14 @@ server_listen
 # client can connect again
 ip netns exec "${ns2}" ip link add dev testtun0 type "${tuntype}" \
 	remote "${addr1}" local "${addr2}"
+# Because packets are decapped by the tunnel they arrive on testtun0 from
+# the IP stack perspective.  Ensure reverse path filtering is disabled
+# otherwise we drop the TCP SYN as arriving on testtun0 instead of the
+# expected veth2 (veth2 is where 192.168.1.2 is configured).
+ip netns exec "${ns2}" sysctl -qw net.ipv4.conf.all.rp_filter=0
+# rp needs to be disabled for both all and testtun0 as the rp value is
+# selected as the max of the "all" and device-specific values.
+ip netns exec "${ns2}" sysctl -qw net.ipv4.conf.testtun0.rp_filter=0
 ip netns exec "${ns2}" ip link set dev testtun0 up
 echo "test bpf encap with tunnel device decap"
 client_connect
-- 
1.8.3.1

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH bpf-next] bpf: test_tc_tunnel.sh needs reverse path filtering disabled
@ 2019-03-25  9:36 ` alan.maguire
  0 siblings, 0 replies; 9+ messages in thread
From: Alan Maguire @ 2019-03-25  9:36 UTC (permalink / raw)


test_tc_tunnel.sh sets up a pair of namespaces connected by a
veth pair to verify encap/decap using bpf_skb_adjust_room.  In
testing this, it uses tunnel links as the peer of the bpf-based
encap/decap.  However because the same IP header is used for inner
and outer IP, when packets arrive at the tunnel interface they will
be dropped by reverse path filtering as those packets are expected
on the veth interface (where the destination IP of the decapped
packet is configured).

To avoid this, ensure reverse path filtering is disabled for the
namespace using tunneling.

Fixes: 98cdabcd0798 ("selftests/bpf: bpf tunnel encap test")
Signed-off-by: Alan Maguire <alan.maguire at oracle.com>
---
 tools/testing/selftests/bpf/test_tc_tunnel.sh | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/testing/selftests/bpf/test_tc_tunnel.sh b/tools/testing/selftests/bpf/test_tc_tunnel.sh
index dcf3206..c805adb 100755
--- a/tools/testing/selftests/bpf/test_tc_tunnel.sh
+++ b/tools/testing/selftests/bpf/test_tc_tunnel.sh
@@ -160,6 +160,14 @@ server_listen
 # client can connect again
 ip netns exec "${ns2}" ip link add dev testtun0 type "${tuntype}" \
 	remote "${addr1}" local "${addr2}"
+# Because packets are decapped by the tunnel they arrive on testtun0 from
+# the IP stack perspective.  Ensure reverse path filtering is disabled
+# otherwise we drop the TCP SYN as arriving on testtun0 instead of the
+# expected veth2 (veth2 is where 192.168.1.2 is configured).
+ip netns exec "${ns2}" sysctl -qw net.ipv4.conf.all.rp_filter=0
+# rp needs to be disabled for both all and testtun0 as the rp value is
+# selected as the max of the "all" and device-specific values.
+ip netns exec "${ns2}" sysctl -qw net.ipv4.conf.testtun0.rp_filter=0
 ip netns exec "${ns2}" ip link set dev testtun0 up
 echo "test bpf encap with tunnel device decap"
 client_connect
-- 
1.8.3.1

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH bpf-next] bpf: test_tc_tunnel.sh needs reverse path filtering disabled
  2019-03-25  9:36 ` alan.maguire
  (?)
@ 2019-03-25 13:17   ` willemdebruijn.kernel
  -1 siblings, 0 replies; 9+ messages in thread
From: Willem de Bruijn @ 2019-03-25 13:17 UTC (permalink / raw)
  To: Alan Maguire
  Cc: Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
	Martin KaFai Lau, songliubraving, yhs, linux-kselftest,
	Network Development, bpf

On Mon, Mar 25, 2019 at 5:36 AM Alan Maguire <alan.maguire@oracle.com> wrote:
>
> test_tc_tunnel.sh sets up a pair of namespaces connected by a
> veth pair to verify encap/decap using bpf_skb_adjust_room.  In
> testing this, it uses tunnel links as the peer of the bpf-based
> encap/decap.  However because the same IP header is used for inner
> and outer IP, when packets arrive at the tunnel interface they will
> be dropped by reverse path filtering as those packets are expected
> on the veth interface (where the destination IP of the decapped
> packet is configured).
>
> To avoid this, ensure reverse path filtering is disabled for the
> namespace using tunneling.
>
> Fixes: 98cdabcd0798 ("selftests/bpf: bpf tunnel encap test")
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>

Acked-by: Willem de Bruijn <willemb@google.com>

Thanks, Alan. Indeed, I had been developing on a platform with reverse
path filter off by default (debian stretch).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH bpf-next] bpf: test_tc_tunnel.sh needs reverse path filtering disabled
@ 2019-03-25 13:17   ` willemdebruijn.kernel
  0 siblings, 0 replies; 9+ messages in thread
From: willemdebruijn.kernel @ 2019-03-25 13:17 UTC (permalink / raw)


On Mon, Mar 25, 2019 at 5:36 AM Alan Maguire <alan.maguire at oracle.com> wrote:
>
> test_tc_tunnel.sh sets up a pair of namespaces connected by a
> veth pair to verify encap/decap using bpf_skb_adjust_room.  In
> testing this, it uses tunnel links as the peer of the bpf-based
> encap/decap.  However because the same IP header is used for inner
> and outer IP, when packets arrive at the tunnel interface they will
> be dropped by reverse path filtering as those packets are expected
> on the veth interface (where the destination IP of the decapped
> packet is configured).
>
> To avoid this, ensure reverse path filtering is disabled for the
> namespace using tunneling.
>
> Fixes: 98cdabcd0798 ("selftests/bpf: bpf tunnel encap test")
> Signed-off-by: Alan Maguire <alan.maguire at oracle.com>

Acked-by: Willem de Bruijn <willemb at google.com>

Thanks, Alan. Indeed, I had been developing on a platform with reverse
path filter off by default (debian stretch).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH bpf-next] bpf: test_tc_tunnel.sh needs reverse path filtering disabled
@ 2019-03-25 13:17   ` willemdebruijn.kernel
  0 siblings, 0 replies; 9+ messages in thread
From: Willem de Bruijn @ 2019-03-25 13:17 UTC (permalink / raw)


On Mon, Mar 25, 2019@5:36 AM Alan Maguire <alan.maguire@oracle.com> wrote:
>
> test_tc_tunnel.sh sets up a pair of namespaces connected by a
> veth pair to verify encap/decap using bpf_skb_adjust_room.  In
> testing this, it uses tunnel links as the peer of the bpf-based
> encap/decap.  However because the same IP header is used for inner
> and outer IP, when packets arrive at the tunnel interface they will
> be dropped by reverse path filtering as those packets are expected
> on the veth interface (where the destination IP of the decapped
> packet is configured).
>
> To avoid this, ensure reverse path filtering is disabled for the
> namespace using tunneling.
>
> Fixes: 98cdabcd0798 ("selftests/bpf: bpf tunnel encap test")
> Signed-off-by: Alan Maguire <alan.maguire at oracle.com>

Acked-by: Willem de Bruijn <willemb at google.com>

Thanks, Alan. Indeed, I had been developing on a platform with reverse
path filter off by default (debian stretch).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH bpf-next] bpf: test_tc_tunnel.sh needs reverse path filtering disabled
  2019-03-25  9:36 ` alan.maguire
  (?)
@ 2019-03-25 14:03   ` daniel
  -1 siblings, 0 replies; 9+ messages in thread
From: Daniel Borkmann @ 2019-03-25 14:03 UTC (permalink / raw)
  To: Alan Maguire, willemdebruijn.kernel, shuah, ast, kafai,
	songliubraving, yhs, linux-kselftest, netdev, bpf

On 03/25/2019 10:36 AM, Alan Maguire wrote:
> test_tc_tunnel.sh sets up a pair of namespaces connected by a
> veth pair to verify encap/decap using bpf_skb_adjust_room.  In
> testing this, it uses tunnel links as the peer of the bpf-based
> encap/decap.  However because the same IP header is used for inner
> and outer IP, when packets arrive at the tunnel interface they will
> be dropped by reverse path filtering as those packets are expected
> on the veth interface (where the destination IP of the decapped
> packet is configured).
> 
> To avoid this, ensure reverse path filtering is disabled for the
> namespace using tunneling.
> 
> Fixes: 98cdabcd0798 ("selftests/bpf: bpf tunnel encap test")
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>

Applied, thanks!

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH bpf-next] bpf: test_tc_tunnel.sh needs reverse path filtering disabled
@ 2019-03-25 14:03   ` daniel
  0 siblings, 0 replies; 9+ messages in thread
From: daniel @ 2019-03-25 14:03 UTC (permalink / raw)


On 03/25/2019 10:36 AM, Alan Maguire wrote:
> test_tc_tunnel.sh sets up a pair of namespaces connected by a
> veth pair to verify encap/decap using bpf_skb_adjust_room.  In
> testing this, it uses tunnel links as the peer of the bpf-based
> encap/decap.  However because the same IP header is used for inner
> and outer IP, when packets arrive at the tunnel interface they will
> be dropped by reverse path filtering as those packets are expected
> on the veth interface (where the destination IP of the decapped
> packet is configured).
> 
> To avoid this, ensure reverse path filtering is disabled for the
> namespace using tunneling.
> 
> Fixes: 98cdabcd0798 ("selftests/bpf: bpf tunnel encap test")
> Signed-off-by: Alan Maguire <alan.maguire at oracle.com>

Applied, thanks!

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH bpf-next] bpf: test_tc_tunnel.sh needs reverse path filtering disabled
@ 2019-03-25 14:03   ` daniel
  0 siblings, 0 replies; 9+ messages in thread
From: Daniel Borkmann @ 2019-03-25 14:03 UTC (permalink / raw)


On 03/25/2019 10:36 AM, Alan Maguire wrote:
> test_tc_tunnel.sh sets up a pair of namespaces connected by a
> veth pair to verify encap/decap using bpf_skb_adjust_room.  In
> testing this, it uses tunnel links as the peer of the bpf-based
> encap/decap.  However because the same IP header is used for inner
> and outer IP, when packets arrive at the tunnel interface they will
> be dropped by reverse path filtering as those packets are expected
> on the veth interface (where the destination IP of the decapped
> packet is configured).
> 
> To avoid this, ensure reverse path filtering is disabled for the
> namespace using tunneling.
> 
> Fixes: 98cdabcd0798 ("selftests/bpf: bpf tunnel encap test")
> Signed-off-by: Alan Maguire <alan.maguire at oracle.com>

Applied, thanks!

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-03-25 14:03 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-25  9:36 [PATCH bpf-next] bpf: test_tc_tunnel.sh needs reverse path filtering disabled Alan Maguire
2019-03-25  9:36 ` Alan Maguire
2019-03-25  9:36 ` alan.maguire
2019-03-25 13:17 ` Willem de Bruijn
2019-03-25 13:17   ` Willem de Bruijn
2019-03-25 13:17   ` willemdebruijn.kernel
2019-03-25 14:03 ` Daniel Borkmann
2019-03-25 14:03   ` Daniel Borkmann
2019-03-25 14:03   ` daniel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.