United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6402758 Linux: Problem with multicast socket on dual stack (ipv4 and ipv6) on the loopback interface
6402758 : Linux: Problem with multicast socket on dual stack (ipv4 and ipv6) on the loopback interface

Details
Type:
Bug
Submit Date:
2006-03-23
Status:
Closed
Updated Date:
2010-04-02
Project Name:
JDK
Resolved Date:
2006-03-31
Component:
core-libs
OS:
linux_redhat_4.0
Sub-Component:
java.net
CPU:
x86
Priority:
P3
Resolution:
Duplicate
Affected Versions:
5.0
Fixed Versions:

Related Reports
Duplicate:
Relates:
Relates:

Sub Tasks

Description
The Java ES monitoring framework implements a discovery mechanism.

This discovery (local to the node) is implemented using a Multicast channel bound to 
either the loopback (recommended) or the default interface (greatly inspired from the 
JDMK discovery mechanism).

Linux RH4.X automatically enables IPV6 interfaces.
On this boxes, our discovery mechanisnm does not work.
If we disables IPV6 interfaces (lo and eth0) using the command :
ifconfig lo del <address>
ifconfig eth0 del <address>
the discovery works fine.


The attached test program illustrate the problem.
To reproduce:
=============
All Scenario PRE-REQUISITE: make sure ipv6 is enabled on the loopback, for example:
# ifconfig lo0 inet6 plumb

Scenario 1: Default <-> Default: BREAK
--------------------------------------

start the 1st & 2nd instance:
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack 
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack 
-> none of the instances receive each other packet.
-> in this case only the loopback interface is forced

Scenario 1: IPv4 <-> IPv4: WORKS
--------------------------------

start the 1st & 2nd instance:
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack -4
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack -4
-> both instances receive each other packet.
-> in this case we use System.setProperty("java.net.preferIPv4Stack", "true");

Scenario 2: IPv4 <-> IPv6: WORKS
--------------------------------

start the 1st & 2nd instance:
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack -4
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack -6
-> both instances receive each other packet.

Scenario 3: IPv6 <-> IPv6: BREAK
--------------------------------

start the 1st & 2nd instance:
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack -6
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack -6
-> none of the instances receive each other packet.
-> in this case we use System.setProperty("java.net.preferIPv6Stack", "true");


Disabling the loopback in all the scenario make them work.
This can be achieved using:
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack -l
or
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack -4 -l
or
/usr/lang/JAVA/jdk1.5/bin/java TestMulticastLoopBack -6 -l

                                    

Comments
WORK AROUND

The previous statement is not precise enought. The solution would be:

1) Always use IPv4 mutlicast address and set java.net.preferIPv4Stack to true.

or

2) If that can't be done, like in a container environment, try to use IPv6 multicast address such as FF01::1 if IPv6 is enabled in the machine. Also add following route table entry as Linux doesn't have it by default:
    route -A inet6 add FF01::1 dev lo

Either way should work.
                                     
2006-03-28
SUGGESTED FIX

See work around.
                                     
2006-03-27
EVALUATION

The Linux kernel doesn't listen for multicast package on loopback interface by default. A new route table entry needs to add to make this happen. But be warned that it will also break multicast applications trying to use other interfaces.

The simpler way would be just use default interface. Will close this CR by 'not a defect'.
                                     
2006-03-27
WORK AROUND

Add a new toute table entry:
    route add -net 224.0.0.0 netmask 240.0.0.0 dev lo

Be cautious: this will break all multicast applications trying to use any other interface.
                                     
2006-03-27



Hardware and Software, Engineered to Work Together