Bug 174071

Created attachment 121441 [details]
mcast.java

Created attachment 121442 [details]
sendmulticast.java

Adding Jakub to the CC list.  Jakub, is this a known glibc bug by any chance?

Sun also have this bug reported:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6347853

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

QA has confirmed that this bug has not been fixed in java-1.4.2-ibm SR6. 
Assigning to Mark Wisner at IBM.  Mark, will this be fixed in SR7?

----- Additional Comments From chavez.com (prefers email at lnx1138.com)  2006-11-06 14:59 EDT -------
This seems related to IPV6 enabled in RHEL4. I ran the testcase supplied on a
RHEL 4.4 system and got the following:

[root@lola ~]# IBMJava2-amd64-142/bin/java sendmulticast 225.10.10.10 9.3.191.199 5
name:eth0 (eth0) index: 2 addresses:
/fe80:0:0:0:214:5eff:fe0b:931c;
/9.3.191.199;

eth0

You can see that two addresses are shown with the IPV6 address first. The tcdump
did show ttl = 1 for the above attempt.

I found a previous RHEL 4 bug reported to us by the IBM Java team on the same
subject. Here is the last entry in the bug before it was closed as NOTABUG:

    I found this information  in the rfc doc at the following link 
   ftp://ftp.isi.edu/in-notes/rfc2460.txt 
   "Maximum Packet Lifetime 
      Unlike IPv4, IPv6 nodes are not required to enforce maximum packet 
      lifetime.  That is the reason the IPv4 "Time to Live" field was 
      renamed "Hop Limit" in IPv6.  In practice, very few, if any, IPv4 
   implementations conform to the requirement that they limit packet 
   lifetime, so this is not a change in practice.  Any upper-layer 
   protocol that relies on the internet layer (whether IPv4 or IPv6) 
   to 
   limit packet lifetime ought to be upgraded to provide its own 
    mechanisms for detecting and discarding obsolete packets." 
   There fore the JVM is working according to the specs.We dont set the 
   TTL value if the node is IPV6 enabled ,instead the Hop Limit is set. 
   When you set -Djava.net.preferIPv4Stack=true ,the IPV6 protocol stack 
   is disabled and therefore TTL value is set. 

So, with the following information I ran both the mcast and sendmulticast
programs with the -Djava.net.preferIPv4Stack=true and got the following output:

[root@lola ~]# IBMJava2-amd64-142/bin/java -Djava.net.preferIPv4Stack=true
sendmulticast 225.10.10.10 9.3.191.199 5
name:eth0 (eth0) index: 2 addresses:
/9.3.191.199;

eth0

And the ttl on the packet was not 1 but a higher number as expected (I got 5).

So, please confirm that restricting java to use IPV4 addresses gives you the
expected results as seen in RHEL 3 so we can close this bug. 

changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |REJECTED
         Resolution|                            |NOTABUG




------- Additional Comments From chavez.com (prefers email at lnx1138.com)  2006-11-13 10:41 EDT -------
Returning as NOTABUG per previous explanation. 

Here is a workaround for what seems to be a bad interaction between Linux IPv6
support and the JVM:

http://forum.java.sun.com/thread.jspa?forumID=42&threadID=587596

Closing as NOTABUG.

I should elaborate:

IBM showed this is not a bug in the JVM and that it's some interaction between
the Linux IPv6 stack and the JVM.  I think it's OK to close this particular bug
(against java-1.4.2-ibm) with a workaround to avoid the IPv6 interaction. 
Hopefully Sun will address this problem in a future JDK release so that
subsequent IBM JDK releases will properly support Linux IPv6.