[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87hblss92x.fsf@small.ssi.corp>
Date: Fri, 28 May 2010 10:51:18 +0200
From: arno@...isbad.org (Arnaud Ebalard)
To: Scott C Otto <otts@...atel-lucent.com>
Cc: Brian Haley <brian.haley@...com>,
David Miller <davem@...emloft.net>,
YOSHIFUJI Hideaki / 吉藤英明
<yoshfuji@...ux-ipv6.org>, Jiri Olsa <jolsa@...hat.com>,
netdev@...r.kernel.org
Subject: Re: [REGRESSION,BISECTED] MIPv6 support broken by f4f914b58019f0
Hi,
Scott C Otto <otts@...atel-lucent.com> writes:
> All,
> Thanks for looking into this.
>
> The behavior of SO_BINDTODEVICE, certainly with IPV4, is to identify a specific
> interface to use for sending/receiving AF_INET packets upon. And that's how it
> has behaved with IPV4. Tools like ping, traceroute (and ping6, traceroute6)
> make use of it with the -i (interface) options.
>
> We ran into this issue when updating an IPV4 application to IPV6. The report
> provided one example of the issue.
>
> The original change was based on the semantics of flowi.oif used in IPV4. There
> flowi.oif (as it is with IPV6 as well) is also set to sk->sk_bound_dev_if when
> using ip_route_connect() and routing simply took a non-zero oif to enforce an
> interface. Looking at IPV4 tunneling, flowi.oif is set the same way from
> tunnel's parms.link as with IPV6 so would follow those semantics as well.
>
> Obviously, with IPV6, the semantics of flowi.oif are different and perhaps even
> vary with the users of IPV6.
>
> If that variability is desired, the proposed change from Brian (using
> sk->sk_bound_dev_if) would be an equivalent means of supporting SO_BINDTODEVICE
> while limiting the impact.
ok. Thanks for the feedback. Can you comment on what is below?
>> The below might actually be what was actually intended, triggering
>> on what the user forced, rather than assuming all callers require
>> strict behavior.
>>
>> -Brian
>>
>>
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index 294cbe8..252d761 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -814,7 +814,7 @@ struct dst_entry * ip6_route_output(struct net *net, struct sock *sk,
>> {
>> int flags = 0;
>>
>> - if (fl->oif || rt6_need_strict(&fl->fl6_dst))
>> + if ((sk && sk->sk_bound_dev_if) || rt6_need_strict(&fl->fl6_dst))
>> flags |= RT6_LOOKUP_F_IFACE;
>>
>> if (!ipv6_addr_any(&fl->fl6_src))
Brian, I tested the patch on my Mobile Node: it fixes the regression. I
also updated the kernel on my Home Agent to a 2.6.34 with that fix and
everything works as expected. *For that aspect* and fwiw, you get my
Tested-by: Arnaud Ebalard <arno@...isbad.org>
For the SO_BINDTODEVICE aspect, I don't have code at hand to test if the
fix works as expected. We should also double check that this will not
break other paths which use the sk->sk_bound_dev_if with a different
semantic:
$ grep -R sk_bound_dev_if net/ | wc -l
125
$ grep -R 'sk_bound_dev_if = ' net/
net/ieee802154/raw.c: sk->sk_bound_dev_if = dev->ifindex;
net/core/sock.c: sk->sk_bound_dev_if = index;
net/ipv6/datagram.c: sk->sk_bound_dev_if = usin->sin6_scope_id;
net/ipv6/datagram.c: sk->sk_bound_dev_if = np->mcast_oif;
net/ipv6/af_inet6.c: sk->sk_bound_dev_if = addr->sin6_scope_id;
net/ipv6/tcp_ipv6.c: sk->sk_bound_dev_if = usin->sin6_scope_id;
net/ipv6/tcp_ipv6.c: newsk->sk_bound_dev_if = treq->iif;
net/ipv6/raw.c: sk->sk_bound_dev_if = addr->sin6_scope_id;
net/sctp/socket.c: newsk->sk_bound_dev_if = sk->sk_bound_dev_if;
net/ipv4/ip_output.c: sk->sk_bound_dev_if = arg->bound_dev_if;
net/ipv4/udp.c: sk->sk_bound_dev_if = 0;
net/dccp/ipv6.c: newsk->sk_bound_dev_if = ireq6->iif;
net/dccp/ipv6.c: sk->sk_bound_dev_if = usin->sin6_scope_id;
Cheers,
a+
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists