* [PATCH] net: ipv6 bind to device issue
@ 2010-04-20 12:46 Jiri Olsa
2010-04-20 15:41 ` Brian Haley
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Jiri Olsa @ 2010-04-20 12:46 UTC (permalink / raw)
To: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet
Cc: netdev, Jiri Olsa
hi,
The issue raises when having 2 NICs both assigned the same
IPv6 global address.
If a sender binds to a particular NIC (SO_BINDTODEVICE),
the outgoing traffic is being sent via the first found.
The bonded device is thus not taken into an account during the
routing.
>From the ip6_route_output function:
If the binding address is multicast, linklocal or loopback,
the RT6_LOOKUP_F_IFACE bit is set, but not for global address.
So binding global address will neglect SO_BINDTODEVICE-binded device,
because the fib6_rule_lookup function path won't check for the
flowi::oif field and take first route that fits.
Following patch should handle the issue.
wbr,
jirka
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
---
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c2438e8..7bf7717 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -815,7 +815,7 @@ struct dst_entry * ip6_route_output(struct net *net, struct sock *sk,
{
int flags = 0;
- if (rt6_need_strict(&fl->fl6_dst))
+ if (rt6_need_strict(&fl->fl6_dst) || fl->oif)
flags |= RT6_LOOKUP_F_IFACE;
if (!ipv6_addr_any(&fl->fl6_src))
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] net: ipv6 bind to device issue 2010-04-20 12:46 [PATCH] net: ipv6 bind to device issue Jiri Olsa @ 2010-04-20 15:41 ` Brian Haley 2010-04-20 15:42 ` Jiri Olsa 2010-04-20 18:13 ` Brian Haley 2 siblings, 0 replies; 7+ messages in thread From: Brian Haley @ 2010-04-20 15:41 UTC (permalink / raw) To: Jiri Olsa Cc: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet, netdev Jiri Olsa wrote: > Signed-off-by: Jiri Olsa <jolsa@redhat.com> > --- > diff --git a/net/ipv6/route.c b/net/ipv6/route.c > index c2438e8..7bf7717 100644 > --- a/net/ipv6/route.c > +++ b/net/ipv6/route.c > @@ -815,7 +815,7 @@ struct dst_entry * ip6_route_output(struct net *net, struct sock *sk, > { > int flags = 0; > > - if (rt6_need_strict(&fl->fl6_dst)) > + if (rt6_need_strict(&fl->fl6_dst) || fl->oif) > flags |= RT6_LOOKUP_F_IFACE; > > if (!ipv6_addr_any(&fl->fl6_src)) Acked-by: Brian Haley <brian.haley@hp.com> Saw this within the past month here too and have been testing this same fix without problems. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] net: ipv6 bind to device issue 2010-04-20 12:46 [PATCH] net: ipv6 bind to device issue Jiri Olsa 2010-04-20 15:41 ` Brian Haley @ 2010-04-20 15:42 ` Jiri Olsa 2010-04-20 18:13 ` Brian Haley 2 siblings, 0 replies; 7+ messages in thread From: Jiri Olsa @ 2010-04-20 15:42 UTC (permalink / raw) To: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet; +Cc: netdev On Tue, Apr 20, 2010 at 02:46:12PM +0200, Jiri Olsa wrote: > hi, > > The issue raises when having 2 NICs both assigned the same > IPv6 global address. > > If a sender binds to a particular NIC (SO_BINDTODEVICE), > the outgoing traffic is being sent via the first found. > The bonded device is thus not taken into an account during the > routing. > > > From the ip6_route_output function: > > If the binding address is multicast, linklocal or loopback, > the RT6_LOOKUP_F_IFACE bit is set, but not for global address. > > So binding global address will neglect SO_BINDTODEVICE-binded device, > because the fib6_rule_lookup function path won't check for the > flowi::oif field and take first route that fits. > > Following patch should handle the issue. > > wbr, > jirka > > > Signed-off-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Scott Otto <scott.otto@alcatel-lucent.com> > --- > diff --git a/net/ipv6/route.c b/net/ipv6/route.c > index c2438e8..7bf7717 100644 > --- a/net/ipv6/route.c > +++ b/net/ipv6/route.c > @@ -815,7 +815,7 @@ struct dst_entry * ip6_route_output(struct net *net, struct sock *sk, > { > int flags = 0; > > - if (rt6_need_strict(&fl->fl6_dst)) > + if (rt6_need_strict(&fl->fl6_dst) || fl->oif) > flags |= RT6_LOOKUP_F_IFACE; > > if (!ipv6_addr_any(&fl->fl6_src)) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] net: ipv6 bind to device issue 2010-04-20 12:46 [PATCH] net: ipv6 bind to device issue Jiri Olsa 2010-04-20 15:41 ` Brian Haley 2010-04-20 15:42 ` Jiri Olsa @ 2010-04-20 18:13 ` Brian Haley 2010-04-21 7:21 ` Jiri Olsa 2010-04-22 5:50 ` David Miller 2 siblings, 2 replies; 7+ messages in thread From: Brian Haley @ 2010-04-20 18:13 UTC (permalink / raw) To: Jiri Olsa Cc: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet, netdev Jiri Olsa wrote: > diff --git a/net/ipv6/route.c b/net/ipv6/route.c > index c2438e8..7bf7717 100644 > --- a/net/ipv6/route.c > +++ b/net/ipv6/route.c > @@ -815,7 +815,7 @@ struct dst_entry * ip6_route_output(struct net *net, struct sock *sk, > { > int flags = 0; > > - if (rt6_need_strict(&fl->fl6_dst)) > + if (rt6_need_strict(&fl->fl6_dst) || fl->oif) > flags |= RT6_LOOKUP_F_IFACE; > > if (!ipv6_addr_any(&fl->fl6_src)) Actually, looking at this again, we might want to swap the order here since fl->oif should be filled-in for most link-local and multicast requests calling this: if (fl->oif || rt6_need_strict(&fl->fl6_dst)) Just a thought, but it potentially saves a call to determine the scope of the address. -Brian ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] net: ipv6 bind to device issue 2010-04-20 18:13 ` Brian Haley @ 2010-04-21 7:21 ` Jiri Olsa 2010-04-22 5:50 ` David Miller 1 sibling, 0 replies; 7+ messages in thread From: Jiri Olsa @ 2010-04-21 7:21 UTC (permalink / raw) To: Brian Haley Cc: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet, netdev On Tue, Apr 20, 2010 at 02:13:39PM -0400, Brian Haley wrote: > Jiri Olsa wrote: > > diff --git a/net/ipv6/route.c b/net/ipv6/route.c > > index c2438e8..7bf7717 100644 > > --- a/net/ipv6/route.c > > +++ b/net/ipv6/route.c > > @@ -815,7 +815,7 @@ struct dst_entry * ip6_route_output(struct net *net, struct sock *sk, > > { > > int flags = 0; > > > > - if (rt6_need_strict(&fl->fl6_dst)) > > + if (rt6_need_strict(&fl->fl6_dst) || fl->oif) > > flags |= RT6_LOOKUP_F_IFACE; > > > > if (!ipv6_addr_any(&fl->fl6_src)) > > Actually, looking at this again, we might want to swap the order > here since fl->oif should be filled-in for most link-local and > multicast requests calling this: > > if (fl->oif || rt6_need_strict(&fl->fl6_dst)) > > Just a thought, but it potentially saves a call to determine > the scope of the address. > > -Brian I think it's a good idea, attaching the changed patch thanks, jirka --- The issue raises when having 2 NICs both assigned the same IPv6 global address. If a sender binds to a particular NIC (SO_BINDTODEVICE), the outgoing traffic is being sent via the first found. The bonded device is thus not taken into an account during the routing. >From the ip6_route_output function: If the binding address is multicast, linklocal or loopback, the RT6_LOOKUP_F_IFACE bit is set, but not for global address. So binding global address will neglect SO_BINDTODEVICE-binded device, because the fib6_rule_lookup function path won't check for the flowi::oif field and take first route that fits. Following patch should handle the issue. wbr, jirka Signed-off-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Scott Otto <scott.otto@alcatel-lucent.com> --- net/ipv6/route.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index c2438e8..05ebd78 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -815,7 +815,7 @@ struct dst_entry * ip6_route_output(struct net *net, struct sock *sk, { int flags = 0; - if (rt6_need_strict(&fl->fl6_dst)) + if (fl->oif || rt6_need_strict(&fl->fl6_dst)) flags |= RT6_LOOKUP_F_IFACE; if (!ipv6_addr_any(&fl->fl6_src)) ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] net: ipv6 bind to device issue 2010-04-20 18:13 ` Brian Haley 2010-04-21 7:21 ` Jiri Olsa @ 2010-04-22 5:50 ` David Miller 2010-04-22 5:58 ` David Miller 1 sibling, 1 reply; 7+ messages in thread From: David Miller @ 2010-04-22 5:50 UTC (permalink / raw) To: brian.haley Cc: jolsa, kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet, netdev From: Brian Haley <brian.haley@hp.com> Date: Tue, 20 Apr 2010 14:13:39 -0400 > Actually, looking at this again, we might want to swap the order > here since fl->oif should be filled-in for most link-local and > multicast requests calling this: > > if (fl->oif || rt6_need_strict(&fl->fl6_dst)) > > Just a thought, but it potentially saves a call to determine > the scope of the address. Yes I think we should make this change. Jiri please respin your patch with the argument order reversed so that we can make the inexpensive check before the expensive one. Thanks. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] net: ipv6 bind to device issue 2010-04-22 5:50 ` David Miller @ 2010-04-22 5:58 ` David Miller 0 siblings, 0 replies; 7+ messages in thread From: David Miller @ 2010-04-22 5:58 UTC (permalink / raw) To: brian.haley Cc: jolsa, kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet, netdev From: David Miller <davem@davemloft.net> Date: Wed, 21 Apr 2010 22:50:15 -0700 (PDT) > Jiri please respin your patch with the argument order > reversed so that we can make the inexpensive check before > the expensive one. Nevermind, I see you posted an updated version already, which I've applied, thanks! ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-04-22 5:58 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-20 12:46 [PATCH] net: ipv6 bind to device issue Jiri Olsa 2010-04-20 15:41 ` Brian Haley 2010-04-20 15:42 ` Jiri Olsa 2010-04-20 18:13 ` Brian Haley 2010-04-21 7:21 ` Jiri Olsa 2010-04-22 5:50 ` David Miller 2010-04-22 5:58 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).