[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OF367F9F64.87ED9167-ON882573B6.0063B893-882573B6.0064BE22@us.ibm.com>
Date: Wed, 19 Dec 2007 10:18:24 -0800
From: David Stevens <dlstevens@...ibm.com>
To: Vlad Yasevich <vladislav.yasevich@...com>
Cc: Brian Haley <brian.haley@...com>,
David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
netdev-owner@...r.kernel.org,
YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local
connect()
Vlad Yasevich <vladislav.yasevich@...com> wrote on 12/19/2007 07:20:53 AM:
> But this still requires either a SO_BINDTODEVICE or sin6_scope_id. This
> means the an application can call BINDTODEVICE(eth0), MULTICAST_IF(eth1)
> issue a connect on a UDP socket an succeed? Seems wrong to me.
>
> Can you check section 6.7 of RFC 3542.
No, it requires one of SO_BINDTODEVICE, sin6_scope_id, or
IPV6_MULTICAST_IF.
If you do an SO_BINDTODEVICE(eth0) and then an IPV6_MULTICAST_IF(eth1),
the
IPV6_MULTICAST_IF will fail in setsockopt (EINVAL), because it requires a
match
for bound sockets. I'm not sure if SO_BINDTODEVICE resets mcast_oif if you
do
them in the reverse order, but that would be a bug in SO_BINDTODEVICE.
The precedence order as implemented already is:
SO_BINDTODEVICE is highest and always wins
sin6_scope_id next
IPV6_MULTICAST_IF
and the existing code has the rule that all link-local addresses require a
sin6_scope_id. The change (intended) is to relax the sin6_scope_id rule
only
for link-local multicasts that have done either an SO_BINDTODEVICE or
IPV6_MULTICAST_IF already.
+-DLS
--
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