multicast join problems (source specific)

[Mark Geib]

Thank you John for information and references. This application runs on Linux, so I can see if maybe something is mis-configured. I also considered trying to create virtual interfaces and use a different interface for each multicast join, just have not had the time to test.

Mark.

> On Jan 21, 2021, at 4:06 AM, John Högberg <john.hogberg@REDACTED> wrote:
> 
> > After digging into the details of multicast by reading in "UNIX Network Programming” the problem may be that joining multicast groups is done at the IP level in the network stack and apparently all sockets on a network interface will receive the datagrams for all multicasts when there is more than one, so a bind() needs to be done to create a “filter” for each socket so that only datagrams from the configured multicast are sent to each socket.
> 
> Yes, this is how IGMPv2 and earlier works. RFC 3367 (IGMPv3) has a paragraph that summarizes it nicely:
> 
>      Filtering of packets based upon a socket's multicast reception
>      state is a new feature of this service interface.  The previous
>      service interface [RFC1112] described no filtering based upon
>      multicast join state; rather, a join on a socket simply caused the
>      host to join a group on the given interface, and packets destined
>      for that group could be delivered to all sockets whether they had
>      joined or not.
> 
> > Maybe the {add_membership…} option includes this bind(), but of course the {raw…} does not.
> 
> The problem isn’t the lack of bind(2) – gen_udp:open/1-2 does that for you – I believe it’s that your OS doesn’t implement RFC 3367 which states that a socket should only receive datagrams from the SSM groups it has joined. RFC 4607 further clarifies this in section 2:
> 
>    The source-specific multicast service is defined as follows:
> 
>       A datagram sent with source IP address S and destination IP
>       address G in the SSM range is delivered to each host socket that
>       has specifically requested delivery of datagrams sent by S to G,
>       and only to those sockets.
> 
> Since your OS apparently doesn’t do this, I’m afraid you might have to filter the unwanted datagrams out after the fact. :-(
> 
> /John
> 
> From: erlang-questions <erlang-questions-bounces@REDACTED> On Behalf Of Mark Geib
> Sent: Wednesday, January 20, 2021 17:33
> To: Sergej Jurečko <sergej.jurecko@REDACTED>
> Cc: Erlang Questions <erlang-questions@REDACTED>
> Subject: Re: multicast join problems (source specific)
> 
> Yes, this suggestion is the method to join a any-source, or legacy, multicast. And this does work correctly.
> 
> The problem I am having is trying to join a IGMPv3 source-specific multicast where the IP of the source producing the multicast must be included, which is the purpose of the {raw..} option. The normal {add_membership…} does not work with source-specific multicast.
> 
> After digging into the details of multicast by reading in "UNIX Network Programming” the problem may be that joining multicast groups is done at the IP level in the network stack and apparently all sockets on a network interface will receive the datagrams for all multicasts when there is more than one, so a bind() needs to be done to create a “filter” for each socket so that only datagrams from the configured multicast are sent to each socket. Maybe the {add_membership…} option includes this bind(), but of course the {raw…} does not.
> 
> I am thinking the way to address this problem will be using the new socket module, which provides a bind() function.
> 
> Thanks.
> 
> 
> 
> On Jan 20, 2021, at 1:54 AM, Sergej Jurečko <sergej.jurecko@REDACTED <mailto:sergej.jurecko@REDACTED>> wrote:
> 
> Try connecting to multicast like so (Mc is multicast IP, Src is local IP):
> 
> {ok, SockSrc} = gen_udp:open(Port, [{reuseaddr,true},
> {ip, {0,0,0,0}}, {add_membership, {Mc, Src}},{active,true}, binary,{recbuf, 1024*1024}]);
> 
> Or maybe
> 
> {ok, SockSrc} = gen_udp:open(Port, [{reuseaddr,true},
> {ip, Src}, {multicast_ttl, 1}, {multicast_loop, false}, binary]),
> inet:setopts(SockSrc, [{add_membership, {Mc, Src}}]);
> 
> On Mon, Jan 18, 2021 at 10:20 PM Mark Geib <mark.geib.44@REDACTED <mailto:mark.geib.44@REDACTED>> wrote:
> I have a problem when joining more than one source specific multicast group. The first gen_udp:open() works as expected, I start receiving datagrams sent to the specified multicast address, and coming from the specified source. However, in another gen_server if I try to do the same, but on a different multicast and source address, I start receiving the datagrams on both the new socket as well as the first socket and from both multicast groups. The open looks like:
> 
> Port = 3100,
> Bin = << <<239,0,0,1>>/binary, <<0,0,0,0>>/binary, <<10,0,1,1>>/binary >>,
> {ok, _Socket} = gen_udp:open(Port,
>                              [binary,
>                               {active, true},
>                               {reuseaddr, true},
>                               {multicast_ttl, 30},
>                               {raw, 0, 39, Bin}]), %% 0 - IPPROTO_IP, 39 - IP_ADD_SOURCE_MEMBERSHIP
> 
> I am able to join multiple multicasts, non source specific, and receive only datagrams from the correct group by using an open like:
> 
> Port = 3100,
> {ok, _Socket} = gen_udp:open(Port,
>                              [binary,
>                               {active, true},
>                               {reuseaddr, true},
>                               {multicast_ttl, 30},
>                               {add_membership, {239,0,0,1}, {0,0,0,0}}]),
> 
> Any suggestions or help would be appreciated.
> 
> Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210121/e69156b5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: Message signed with OpenPGP
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210121/e69156b5/attachment.bin>