(usagi-users 03629) Re: IPv6 multicast socket specific binding bug

David Stevens wrote:
>  > If you use source filtering API and do include mode with (S,G), then I
>> assume you would not receive from another source for the same group.
>> Would/should you still receive multicast for other groups (if say some
>> other group is joined on another socket and the bind address/port
>> matches...)?
> 
>         The per-socket filters are applied by group, so an 
> INADDR_ANY-bound
> socket would receive from any source allowed for filters for that group.
> If there is no join (& filter) on that socket, then the default (per-RFC)
> is "{EXCLUDE, empty}" meaning it would be delivered.
>  

Right, so this means that if you filter to only receive from S for G,
you might still receive any packets for other groups G1, G2... That's
what I expected, but wasn't sure.

>> Would a possible work-around be to use source filtering API and join a
>> non-existent source to prevent receiving packets on the other socket? :)
>> I suppose you can't set an include mode source filter with no sources to
>>  block everything.
> 
>         I expect that would work. "{INCLUDE, empty}" is identical to a
> "leave group", which results in no filter at all on that socket. So,
> packets would still be delivered for that group from others, if the
> binding allows it. But you can always create a filter for "{INCLUDE, X}",
> as you said. It's just that you have to do that for all groups that
> someone on the machine might have joined and that might have traffic
> to your port.
>         So, that is a bit of a hack.

Yes :) Well, this behaviour is also what I expected.
> 
>         These aren't the same as making a join per-socket, which is
> what the original discussion was about. Because a per-socket join

I know, it just made me think about it. And BTW, I have some code myself
where I do all joins on one socket, and have several other sockets where
I receive packets for different groups...

Thanks, I think it was useful to see that your interpretation of socket
filtering matches my thinking, and I then know what behaviour I should
expect from Linux too :)

Stig

> (if it existed :-) ) wouldn't restrict based on source of the sender,
> but on the destination. That's the same as binding to the multicast
> group address. The only issue there, really, is that you can only
> bind to one address, so you can't use a single socket to receive
> 2 different multicast groups and nothing else. But you also can't
> do that with multiple unicast addresses.
> 
>         I think it comes down to asking when designing the program
> what you really want. If you want only multicasts for a particular
> group from any source, the you should bind to the multicast group.
> That still doesn't restrict it to a particular interface, but on
> Linux you can also do an SO_BINDTODEVICE to get that.
> If you want all packets to the port, whether multicast or unicast,
> then you should bind to INADDR_ANY. If you want unicast-only, then
> you should bind to an individual unicast address (with a new socket
> for each unicast address). And if you want to further restrict
> the source for multicasts, then you can add source filtering to
> one of the above strategies.
>         These rules aren't any different than they are for unicast
> addresses. Nobody is suggesting that an INADDR_ANY-bound socket
> should only receive local IP unicasts if the unicast address was
> added via SIOCSIFADDR on that very socket you're doing the I/O on!
> A "join" is really the same, in sockets, as adding a new unicast
> address to an interface; it has nothing whatever to do with what
> packets that particular socket receives, aside from affecting
> what packets are delivered to the machine.
>         Multicast filters, unfortunately, muddy the water, because
> those *are* per-socket. It matters what socket you do the filter
> ioctl()'s on, but it doesn't for the joins.
> 
>                                                 +-DLS
> 
>