[openjdk-x] Bind to a multicast address fails

Andre Naujoks nautsch2 at gmail.com
Fri Sep 14 06:39:00 UTC 2018


On 9/10/18 10:36 AM, Andre Naujoks wrote:
> On 9/8/18 11:49 AM, Andre Naujoks wrote:
>> 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.
> 
> I just reposted the patch. Fully automated this time. I couldn't find
> any changes in the IPv4 handling of the socket option, that was not
> there, when I first posted it.
> 
> Lets see, if this has more success.
> 
> https://marc.info/?l=linux-netdev&m=153656806202701&w=2

Hello all.

I just wanted to thank you again for the advice.

The patch just got accepted and is now in the net-next kernel git.

Regards
   Andre

> 
> 
> Regards
>   Andre
> 
>>
>> Regards
>>   Andre
>>
> 



More information about the net-dev mailing list