On Fri, Sep 7, 2018 at 11:08 AM David Lloyd <david.ll...@redhat.com> 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
I should also mention that the recommended approach would be to send a not-RFC version of the patch and see how that goes. -- - DML
