JDK-8134989 : java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_11
  • CPU: x86_64
  • Submitted: 2015-09-02
  • Updated: 2021-05-31
  • Resolved: 2017-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 8 Other
10 b23Fixed 8u311Fixed openjdk8u312Fixed
Related Reports
Relates :  
JDK-8179559 - Solaris MulticastSocket issues
Relates :  
JDK-8179559 - Solaris MulticastSocket issues
Relates :  
JDK-8157499 - Mark several tests from jdk_net as intermittently failing
Description
This test failure was spotted in an Aurora Adhoc run.

java/net/MulticastSocket/TestInterfaces.java

    This test failed due to:

MulticastSocket.getInterface returned: /0:0:0:0:0:0:0:0%net0
Failed! Expected: /10.128.64.222
java.lang.Exception: 1 test(s) failed!!!
Comments
URL: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4276a5e50032 User: xiaofeya Date: 2017-09-05 01:09:41 +0000
05-09-2017
A note on this issue ... The general failure scenario for this test is where a host is configured for both IPv6 and IPv4. With this configuration the network interfaces are configured with an IPv4 address but not with an IPv6 address. The IPv6 address for the interface is unassigned, and this looks like a wildcard address. The latter may have something to do with dynamic (DHCP type) IPv6 assignment. This test will fail in JDK9 for the above configuration scenario, but will pass in jdk10 where it was fixed by https://bugs.openjdk.java.net/browse/JDK-8179559 has fixed this issue this takes into account the scope id when returning an interface's address in the MulticastSocket::getInterface call flow. In particular the NetworkInterface::getByInetAddress for an unassigned IPv6 address As such, on a host with multiple network interfaces configured, such that they each have a bona fide IPv4 address configured , but an unassigned IPv6 address, the MulticastSocket::getInterface (a slight misnomer) method call is returning the unassigned IPv6 address, and the test registers a failure The root cause for this is due, to the algorithm for retrieving the interface address. In this scenario, the first issue is that the getOption was returning an unassigned IPv6 address and then NetworkInterfaces.getByInetAddress, with the unassigned IPv6 address as input, is used to retrieve a network interface and from that its address. However, this didn't take into account the scop id and the network interface being returned was the "other" network interface with an unassigned IPv6 address, and hence no match to the address set on the MulticastSocket. .
01-09-2017
I suggest to make an enhancement to ease troubleshooting if "bad" configuration comes again: 1. check isUp() and supportsMulticast() may not help from history errors, but no harm. 2. If reproduce failures as above, check if there are interfaces with dup addresses.
01-09-2017
yes, the configuration is the issue I think in this scenario isUp() will return true when considering the problematic net0 and net4 as they have IPv4 config which are UP and RUNNING I'd guess that these types of configuration are not what would be expected for a "proper" configuration, but could be indicative of a partially complete configuration, where possibly an automated script fails without sufficient checks in place. a question that may arise wrt deprecating {set|get)Interface is how much of a convenience are they? But removing them addresses some potentially anomalous behaviour.
03-04-2017
Mark, it is possible to bring net1 and net4, the two ::0 interfaces, UP (in terms of IPv6)? Or is this just a situation that can be modeled, but not really used? The reason I ask is that should the test check that the interface isUp() ? I understand that there may be a product bug here too, but the network configuration seems almost pathological, no? Additionally, should the [set|get]Interface methods that operate on InetAddress' be deprecated in favor of the variants that operate on NetworkInferface types?
03-04-2017