netdev - Re: [PATCH net] selftests: fib_rule_tests: Fix icmp proto with ipv6

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] [day] [month] [year] [list]

Date:   Wed, 8 May 2019 13:38:27 -0600
From:   David Ahern <dsahern@...il.com>
To:     Hangbin Liu <liuhangbin@...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 5/7/19 2:20 AM, Hangbin Liu wrote:
> 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?
> 

seems to me the test is a bit off; the source, gateway and address on
dummy are all in the same subnet. egress device == ingress device would
cause a redirect. That is right after the valiate_source check.