]> git.baikalelectronics.ru Git - kernel.git/commit
ipv4: use new_gw for redirect neigh lookup
authorStephen Suryaputra Lin <stephen.suryaputra.lin@gmail.com>
Thu, 10 Nov 2016 16:16:15 +0000 (11:16 -0500)
committerDavid S. Miller <davem@davemloft.net>
Sun, 13 Nov 2016 17:24:44 +0000 (12:24 -0500)
commit1958b9d8ca5ac096b6f55773db056e6ce7f734cc
tree2ea71d6490d1789212d6893d9b663480fcb052da
parent46810cd8127859d4c0d4916195e65da692e405d9
ipv4: use new_gw for redirect neigh lookup

In v2.6, ip_rt_redirect() calls arp_bind_neighbour() which returns 0
and then the state of the neigh for the new_gw is checked. If the state
isn't valid then the redirected route is deleted. This behavior is
maintained up to v3.5.7 by check_peer_redirect() because rt->rt_gateway
is assigned to peer->redirect_learned.a4 before calling
ipv4_neigh_lookup().

After commit a934d4a8fe23 ("ipv4: Maintain redirect and PMTU info in
struct rtable again."), ipv4_neigh_lookup() is performed without the
rt_gateway assigned to the new_gw. In the case when rt_gateway (old_gw)
isn't zero, the function uses it as the key. The neigh is most likely
valid since the old_gw is the one that sends the ICMP redirect message.
Then the new_gw is assigned to fib_nh_exception. The problem is: the
new_gw ARP may never gets resolved and the traffic is blackholed.

So, use the new_gw for neigh lookup.

Changes from v1:
 - use __ipv4_neigh_lookup instead (per Eric Dumazet).

Fixes: a934d4a8fe23 ("ipv4: Maintain redirect and PMTU info in struct rtable again.")
Signed-off-by: Stephen Suryaputra Lin <ssurya@ieee.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/ipv4/route.c