From: Nicolas Dichtel <nicolas.dich...@6wind.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.dich...@6wind.com> Applied and queued up for -stable, thanks.
