[openjdk-x] Bind to a multicast address fails

[Andre Naujoks]

On 9/7/18 6:08 PM, David Lloyd wrote:
> On Fri, Sep 7, 2018 at 6:56 AM Andre Naujoks <nautsch2 at gmail.com> wrote:
>> On 9/7/18 1:15 PM, Alan Bateman wrote:
>>> On 07/09/2018 10:49, Decke, Hendrik (K-GERFA/A) wrote:
>>>>
>>>> Hello,
>>>>
>>>> it seems one of our external developers (Andre Naujoks, CC) found a
>>>> bug while binding a IPv6 multicast UDP-socket for one of our projects.
>>>>
>>>>
>>>>
>>>> Since this seems to be a fundamental bug (from our perspective), we
>>>> address this directly to this mailing list.
>>>>
>>>> (reproducible in OpenJDK 8-11, Windows and Linux)
>>>>
>>> This bug was submitted this week on this issue:
>>>   https://bugs.openjdk.java.net/browse/JDK-8210493
>>>
>>> Have you tried joining the mullticast group, specifying the network
>>> interface, rather than binding to the multicast address?
>>
>> Hi Alan.
>>
>> First of all, thank you for the quick reply. I was not aware, that there
>> was actually a bug opened for that issue.
>>
>> The join is not the problem at this point. We need to bind the socket to
>> the address to avoid receiving traffic from all multicast groups, that
>> are joined on the system. Since a join joins the system (not the socket)
>> to the group, all sockets bound to a port, which receive multicast
>> traffic will receive all of that traffic, no matter the destination
>> address. The bind prevents that. IP_MULTICAST_ALL sadly only works for
>> IPv4 and the patch I tried to get IPV6_MULTICAST_ALL upstream into the
>> kernel was even more sadly (almost) ignored. see
>> https://marc.info/?l=linux-netdev&m=152344460530252&w=2
> 
> Hi Andre,
> 
> I spoke with a colleague about this kernel patch.  They said first of
> all that multicast filtering is pretty complex in the kernel with a
> lot of subtle behaviors.  But, they also said that it may have been
> ignored because of the format of the patch, perhaps even
> accidentally/automatically.  The proposed patch has an "RFC" tag, and
> such patches apparently need to be in "git-format-patch" mode.
> Lastly, they said that since the time that the post was made,
> IP_MULTICAST_ALL (for IPv4 only of course) has changed a little bit in
> that "it only allows receipt of all multicast groups if a specific
> list of multicast groups has not already been set", so it may need to
> be updated accordingly.  FWIW they didn't mention seeing any actual
> problems with the content of the patch, though I'm not sure how
> thoroughly they reviewed it.
> 
> So, while I myself am not a Linux kernel contributor, I do suspect
> that if you reposted an updated version of the patch, in the correct
> format, it will enter the patch queue and may be more actively
> discussed.  For more information, see [1].
> 
> [1] https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#the-canonical-patch-format
> 

Hi David

Thanks for the advice. The patch was actually generated with 'git
format-patch' I just added some explanatory text, which I did not see as
part of the commit message. The RFC tag was intentional because I am not
that deeply familiar with the networking code in the kernel to "just
send a patch", if you know what I mean. As far as I know, there is no
automatic handling of those e-mails except for the patchwork stuff.

I need to take a look at the IP_MULTICAST_ALL changes and see, if there
is anything that needs to be changed in the IPV6_MULTICAST_ALL addition
to accommodate for that. But, as you said, the multicast filtering is
pretty complex.

I'll try and re-post the patch on Monday, leave out all the extra stuff
and see if it changes anything or at least if it gets any more replies.

Regards
  Andre