[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190622.170712.2073255657139689928.davem@davemloft.net>
Date: Sat, 22 Jun 2019 17:07:12 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: nicolas.dichtel@...nd.com
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
Date: Thu, 20 Jun 2019 14:34:34 +0200
> The scenario is the following: the user uses a raw socket to send an ipv6
> packet, destinated to a not-connected network, and specify a connected nh.
> Here is the corresponding python script to reproduce this scenario:
...
> fd00:175::/64 is a connected route and fd00:200::fa is not a connected
> host.
>
> With this scenario, the kernel starts by sending a NS to resolve
> fd00:175::2. When it receives the NA, it flushes its queue and try to send
> the initial packet. But instead of sending it, it sends another NS to
> resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
> the user sends again the packet, it now uses the right nh (fd00:175::2).
>
> The problem is that ip6_dst_lookup_neigh() uses the rt6i_gateway, which is
> :: because the associated route is a connected route, thus it uses the dst
> addr of the packet. Let's use rt6_nexthop() to choose the right nh.
>
> Note that rt and in6addr_any are const in ip6_dst_lookup_neigh(), thus
> let's constify rt6_nexthop() to avoid ugly cast.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@...nd.com>
Applied and queued up for -stable, thanks.
Powered by blists - more mailing lists