Bug 174071 - TTL not updated when sending multicast message
TTL not updated when sending multicast message
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: java-1.4.2-ibm (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-24 05:12 EST by Bastien Nocera
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-30 17:08:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
mcast.java (730 bytes, text/plain)
2005-11-24 05:12 EST, Bastien Nocera
no flags Details
sendmulticast.java (1.11 KB, text/plain)
2005-11-24 05:13 EST, Bastien Nocera
no flags Details

  None (edit)
Description Bastien Nocera 2005-11-24 05:12:58 EST
java-1.4.2-ibm-1.4.2.2-1jpp_10rh

1. Create an interface:
sudo /sbin/ifconfig eth0:1 10.10.93.210 up
2. Start a tcpdump:
tcpdump -i eth0 -vvvv host 225.10.10.10
3. Start the listener:
java mcast 225.10.10.10 10010 <your IP>
4. Send something:
java sendmulticast 225.10.10.10 10.10.93.210 5

Running on RHEL3 (java-1.4.2-ibm-1.4.2.2-1jpp_9rh), it works fine, tcpdump shows
a TTL of 5. On RHEL4, tcpdump shows a TTL of 1. An strace will show that the
RHEL4 version is missing a setsockopt call, ltrace doesn't work (at all).

The problem might be a glibc one as Sun's JVM also shows the same problem (I do
not know how much code those JVMs share).
Comment 1 Bastien Nocera 2005-11-24 05:12:58 EST
Created attachment 121441 [details]
mcast.java
Comment 2 Bastien Nocera 2005-11-24 05:13:27 EST
Created attachment 121442 [details]
sendmulticast.java
Comment 6 Thomas Fitzsimmons 2006-01-11 15:58:14 EST
Adding Jakub to the CC list.  Jakub, is this a known glibc bug by any chance?
Comment 10 Bastien Nocera 2006-07-31 05:37:42 EDT
Sun also have this bug reported:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6347853
Comment 12 RHEL Product and Program Management 2006-08-23 17:41:18 EDT
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.
Comment 13 RHEL Product and Program Management 2006-08-23 17:41:28 EDT
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.
Comment 17 Thomas Fitzsimmons 2006-11-03 18:21:31 EST
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?
Comment 18 IBM Bug Proxy 2006-11-07 13:02:09 EST
----- Additional Comments From chavez@us.ibm.com (prefers email at lnx1138@us.ibm.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. 
Comment 19 IBM Bug Proxy 2006-11-13 11:54:36 EST
changed:

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




------- Additional Comments From chavez@us.ibm.com (prefers email at lnx1138@us.ibm.com)  2006-11-13 10:41 EDT -------
Returning as NOTABUG per previous explanation. 
Comment 20 Thomas Fitzsimmons 2007-01-30 17:08:35 EST
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.
Comment 21 Thomas Fitzsimmons 2007-01-30 17:28:55 EST
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.

Note You need to log in before you can comment on or make changes to this bug.