JDK-8134398 : MulticastSocket.setTimeToLive is broken on mac os X
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8u40
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: os_x
  • CPU: x86
  • Submitted: 2015-08-18
  • Updated: 2020-01-18
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

(also tested java 9 from source code)

ADDITIONAL OS VERSION INFORMATION :
Darwin mac2 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64


A DESCRIPTION OF THE PROBLEM :
This is the exact same bug as https://bugs.openjdk.java.net/browse/JDK-6250763, which was only fixed on Linux.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Join a multicast group on some other machine.

Then, use client code to specify time to live of zero, which should never leave the machine, but its completely ignored and does.

Or reuse tests from JDK-6250763

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
setTimeToLive should work
ACTUAL -
setTimeToLive is completely ignored. I Looked at the code, apparently it was coded for solaris, and then the linux case was ifdef'ed.

Guys, its solaris thats the wierd one, special case it instead :)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
  // join a multicast group on another machine to ensure you see the packets

  public static void main(String args[]) throws Exception {
    MulticastSocket socket = new MulticastSocket();
    socket.setTimeToLive(0); // has no impact unless jvm flag -Djava.net.preferIPv4Stack=true
    SocketAddress destination = new InetSocketAddress(InetAddress.getByName("224.2.2.4"), 44444);
    socket.joinGroup(destination, null);
    socket.send(new DatagramPacket("abcd".getBytes(), 4, destination));
    socket.close();
  }
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
-Djava.net.preferIPv4Stack=true is *not* really a workaround, as it totally prevents ipv6 from working. Its wrongly named, it should have been called -Djava.net.forceIPv4Stack


Comments
Michael has submitted an issue to Apple on this.
18-01-2020

Was there any follow-up with Apple on this issue? To my knowledge, the IPV6_MULTICAST_HOPS socket option only applies to IPv6 multicast datagrams, it does not set the TTL on IPv4 multicast datagrams (ditto for the other IPV6_MULTICAST_XX socket options). Also, IP_MULTICAST_TTL can't be used (as it is on Linux) on IPv6 sockets. The workaround is to run with preferIPv4Stack=true as suggested, or else move to DatagramChannel and create it with the protocol family INET so that the channel's socket is an IPv4 socket.
14-12-2019

ILW=MMM=P3 I could reproduce the bug in JDK 8u60. The test case is attached. -Run MulticastSender on a Mac OS. -Run MultiCastReceiver on another machine (I ran this on Windows 7, the receiving side may be any OS) -Expected Result: As the setTimeToLive is set to 0 , it is expected that the MulticastReceiver should not receive the sent message.("defc") -Actual result: The MulticastReceiver receives the message "defc". -When the MulticastSender is run with the argument "-Djava.net.preferIPv4Stack=true" , the MulticastReceiver does not receive the message. This bug was fixed for Linux in JDK-6250763. Moving it to dev team for fixing the case.
25-08-2015