1. Create an interface:
sudo /sbin/ifconfig eth0:1 10.10.93.210 up
2. Start a tcpdump:
tcpdump -i eth0 -vvvv host 22.214.171.124
3. Start the listener:
java mcast 126.96.36.199 10010 <your IP>
4. Send something:
java sendmulticast 188.8.131.52 10.10.93.210 5
Running on RHEL3 (java-1.4.2-ibm-184.108.40.206-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).
Created attachment 121441 [details]
Created attachment 121442 [details]
Adding Jakub to the CC list. Jakub, is this a known glibc bug by any chance?
Sun also have this bug reported:
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
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 firstname.lastname@example.org (prefers email at email@example.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 220.127.116.11 18.104.22.168 5
name:eth0 (eth0) index: 2 addresses:
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
"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)
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 22.214.171.124 126.96.36.199 5
name:eth0 (eth0) index: 2 addresses:
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.
What |Removed |Added
------- Additional Comments From firstname.lastname@example.org (prefers email at email@example.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:
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.