Fantastic! I'm glad to hear it. On Fri, Sep 14, 2018 at 1:39 AM Andre Naujoks <nauts...@gmail.com> wrote: > > 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 <nauts...@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 > >> > > >
-- - DML
