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]
Date:   Tue, 7 May 2019 16:20:01 +0800
From:   Hangbin Liu <liuhangbin@...il.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Roopa Prabhu <roopa@...ulusnetworks.com>, davem@...emloft.net,
        netdev@...r.kernel.org
Subject: Re: [PATCH net] selftests: fib_rule_tests: Fix icmp proto with ipv6

On Tue, Apr 30, 2019 at 12:00:46PM -0600, David Ahern wrote:
> On 4/29/19 8:37 PM, Hangbin Liu wrote:
> > An other issue is The IPv4 rule 'from iif' check test failed while IPv6
> > passed. I haven't found out the reason yet.
> > 
> > # ip -netns testns rule add from 192.51.100.3 iif dummy0 table 100
> > # ip -netns testns route get 192.51.100.2 from 192.51.100.3 iif dummy0
> > RTNETLINK answers: No route to host
> > 
> >     TEST: rule4 check: from 192.51.100.3 iif dummy0           [FAIL]
> > 
> > # ip -netns testns -6 rule add from 2001:db8:1::3 iif dummy0 table 100
> > # ip -netns testns -6 route get 2001:db8:1::2 from 2001:db8:1::3 iif dummy0
> > 2001:db8:1::2 via 2001:db8:1::2 dev dummy0 table 100 metric 1024 iif dummy0 pref medium
> > 
> >     TEST: rule6 check: from 2001:db8:1::3 iif dummy0          [ OK ]
> 
> use perf to look at the fib lookup parameters:
>   perf record -e fib:* -- ip -netns testns route get 192.51.100.2 from
> 192.51.100.3 iif dummy0
>   perf script

Hi David, Roopa,

>From the perf record the result looks good.
fib_table_lookup could get correct route.

For IPv4:
ip  7155 [001]  8442.915515: fib:fib_table_lookup: table 255 oif 0 iif 2 proto 0 192.51.100.3/0 -> 192.51.100.2/0 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
ip  7155 [001]  8442.915517: fib:fib_table_lookup: table 100 oif 0 iif 2 proto 0 192.51.100.3/0 -> 192.51.100.2/0 tos 0 scope 0 flags 0 ==> dev dummy0 gw 192.51.100.2 src 198.51.100.1 err 0

For IPv6:
ip  6950 [000]   759.328850: fib6:fib6_table_lookup: table 255 oif 0 iif 2 proto 0 2001:db8:1::3/0 -> 2001:db8:1::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ip  6950 [000]   759.328852: fib6:fib6_table_lookup: table 100 oif 0 iif 2 proto 0 2001:db8:1::3/0 -> 2001:db8:1::2/0 tos 0 scope 0 flags 0 ==> dev dummy0 gw 2001:db8:1::2 err 0


Then I tracked the code and found in function ip_route_input_slow(),
after fib_lookup(), we got res->type == RTN_UNICAST. So if we haven't
enabled forwarding, it will return -EHOSTUNREACH.

But even we enabled forwarding, we still need to disable rp_filter as the
source/dest address are in the same subnet. The ip_mkroute_input()
-> __mkroute_input() -> fib_validate_source() -> __fib_validate_source() will
return -EXDEV if we enabled rp_filter.

So do you think if we should enable forwarding and disble rp_filter before
test "from $SRC_IP iif $DEV" or just diable this test directly?

Thanks
Hangbin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ