JDK-8039930 : java.net.NetworkInterface.getNetworkInterfaces() is not returning vni interfaces
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6u30,7u51,8
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: solaris_10
  • CPU: x86_64
  • Submitted: 2014-04-09
  • Updated: 2018-09-11
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.
Other
tbdUnresolved
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Server VM (build 24.51-b03, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
SunOS qa00.sol003 5.10 Generic_148889-01 i86pc i386 i86pc


A DESCRIPTION OF THE PROBLEM :
HI team,

our application is using java.net.NetworkInterface.getNetworkInterfaces()  to get all the network interfaces of a machine. we were using jdk6(java version "1.6.0_05") previously and the method is used to return all network interfaces( i.e virtual and server). now we are upgraded to jdk7(java version "1.7.0_51").

The same method is not returning virtual network interfaces.

Our application required to listen/bind to all addresses of a machine. And we use java.net.NetworkInterface.getNetworkInterfaces() to get all the addresses. Please let us know why its not working with jdk7. we are not able to upgrade to jdk7 because of this.

Thanks
Renuka M

REGRESSION.  Last worked in version 6u43

ADDITIONAL REGRESSION INFORMATION: 
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Server VM (build 24.51-b03, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :

below example not giving all network interfaces of a machine with jdk 7.

import static java.lang.System.out;

import java.net.InetAddress;
import java.net.NetworkInterface;
import java.net.SocketException;
import java.util.Collections;
import java.util.Enumeration;

public class TestNIC {

  /**
   * @param args
   * @throws SocketException
   */
  public static void main(String[] args) throws SocketException {

    Enumeration<NetworkInterface> nets = NetworkInterface.getNetworkInterfaces();

    for (NetworkInterface netIf : Collections.list(nets)) {

      Enumeration<InetAddress> inets = netIf.getInetAddresses();

      for (InetAddress inet : Collections.list(inets)) {
        out.println(inet.getHostAddress());
      }

      out.printf("\n");
    }
  }
}


java version "1.7.0_51"  returns below 2 IPs:

10.254.238.17
127.0.0.1



The same program with jdk6(java version "1.6.0_05"
) retruns belkow addresses:

10.199.1.10
173.0.82.55
10.201.1.253
10.254.199.253
10.254.238.17
127.0.0.1



Here 10.199.1.10,173.0.82.55,10.201.1.253,10.254.199.253 are vni interfaces of that machine.

Here is Ifconfig -a results of that machine:

-bash-3.2$ ifconfig -a
lo0:4: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0:5: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.254.238.17 netmask ffffffc0 broadcast 10.254.238.63
vni0:1: flags=20010100c1<UP,RUNNING,NOARP,NOXMIT,IPv4,VIRTUAL> mtu 0 index 4
        inet 10.254.199.253 netmask ffffffff
vni0:2: flags=20010100c1<UP,RUNNING,NOARP,NOXMIT,IPv4,VIRTUAL> mtu 0 index 4
        inet 10.201.1.253 netmask ffffffff
vni0:4: flags=20010100c1<UP,RUNNING,NOARP,NOXMIT,IPv4,VIRTUAL> mtu 0 index 4
        inet 173.0.82.55 netmask ffffffff
vni0:6: flags=20010100c1<UP,RUNNING,NOARP,NOXMIT,IPv4,VIRTUAL> mtu 0 index 4
        inet 10.199.1.10 netmask ffffffff
-bash-3.2$





REPRODUCIBILITY :
This bug can be reproduced always.


Comments
Possibly related to 8013140
30-09-2014

It started with 1.6.0_25 & 1.7.0-ea-b102, and is reproducible with 8 - it means a cause is JDK-6931566. Moving to Dev for evaluation.
16-04-2014

Behaviour change is reproducible with the latest jdk6 releases.
10-04-2014