Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1169624

Re: [PATCH] ipv6: Fixed source specific default route handling.

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On 05/05/2015 12:36 PM, Markus Stenberg wrote:
> If there are only IPv6 source specific default routes present, the
> host gets -ENETUNREACH on e.g. connect() because ip6_dst_lookup_tail
> calls ip6_route_output first, and given source address any, it fails,
> and ip6_route_get_saddr is never called.
> 
> The change is to use the ip6_route_get_saddr, even if the initial
> ip6_route_output fails, and then doing ip6_route_output _again_ after
> we have appropriate source address available.
> 
> Note that this is '99% fix' to the problem; a correct fix would be to
> do route lookups only within addrconf.c when picking a source address,
> and never call ip6_route_output before source address has been
> populated.
> 
> Signed-off-by: Markus Stenberg <markus.stenberg@iki.fi>
> ---
>  net/ipv6/ip6_output.c | 39 +++++++++++++++++++++++++++++++--------
>  net/ipv6/route.c      |  5 +++--
>  2 files changed, 34 insertions(+), 10 deletions(-)
> 
...

So... how does ip6_route_get_saddr() select the source address when no
route is given? OpenWrt has recently started relying on this patch and
I'm seeing quite weird source address selection behaviour (@Steven:
especially since OpenWrt commit r45941).

Steps to reproduce:

  ip l add test link eth0 type macvlan
  ip l set test up
  ip a add fd00::20/64 dev eth0
  ip a add fd00::1/128 dev test

Upto here everything is okay,

  ping6 fd00::10

will use the correct source address fd00::20.

Now I add an additional source-specific route:

  ip r add fd00::/64 from fd00::/64 dev eth0

(this certainly looks like a contrived example, but the configuration
OpenWrt's netifd/odhcp6c creates is similar)

Without this patch, the ping will fail with 'network unreachable' (which
is weird by itself - why does the source-specific route shadow the
generic route even though no source address has been chosen?). But after
applying this patch, the kernel will now choose the address with the
longest common prefix with the destination, which is fd00::1 - even
though this address is assigned as /128.

Adding a prefsrc attribute to the source-specific route doesn't have an
effect as ip6_route_get_saddr() doesn't even get the route when the
non-source-specific ip6_route_output() has failed. Thus, there's
currently no way (to my knowledge) to specify the source address to use
when source-specific routes are involved...

Matthias

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH] ipv6: Fixed source specific default route handling. Matthias Schiffer <mschiffer@universe-factory.net> - 2015-06-21 19:20 +0200
  Re: [PATCH] ipv6: Fixed source specific default route handling. Markus Stenberg <markus.stenberg@iki.fi> - 2015-06-22 01:20 +0200
  Re: [PATCH] ipv6: Fixed source specific default route handling. Steven Barth <steven@midlink.org> - 2015-06-22 08:30 +0200
    Re: [PATCH] ipv6: Fixed source specific default route handling. YOSHIFUJI Hideaki/吉藤英明   <hideaki.yoshifuji@miraclelinux.com> - 2015-06-23 04:00 +0200

csiph-web