David Stevens wrote: > Vlad Yasevich <[EMAIL PROTECTED]> 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 should have checked that... so the case I thought off is not possible... > 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. I don't think that would be needed since SO_BINDTODEVICE always wins over IPV6_MULTICAST_IF, so even if they mismatch, SO_BINDTODEVICE is still used. > 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. > Ok, but I don't think your patch accomplishes that, as Brian pointed out. -vlad -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
