On 5/7/19 2:20 AM, Hangbin Liu wrote:

On Tue, Apr 30, 2019 at 12:00:46PM -0600, David Ahern wrote:

quoted

On 4/29/19 8:37 PM, Hangbin Liu wrote:

quoted

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.