Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-1262624

InetAddress.getByName thows exception if address is not the machine running.

    XMLWordPrintable

    Details

    • Subcomponent:
    • CPU:
      sparc
    • OS:
      generic

      Description

      This
      1) is a duplicate of bug 1253518
      2) has been fixed in 1.1 for a while

      -brown



      The behavior of InetAddress.getByName is different between Solaris, Win32, and Mac
      versions of the jdk1.0.2. This must be fixed.

      THE CODE:

      import java.net.*;

      public class NetTest {
         NetTest () {}

         public static void main (String argv[]) {
          try { System.out.println(InetAddress.getByName("samnkona.eng.sun.com"));
      } catch (Exception e) { System.out.println("one"); }

             try { System.out.println(InetAddress.getByName("129.144.173.103"));
        } catch (Exception e) {System.out.println("two"); }

      try { System.out.println(InetAddress.getByName("129.144.173.150"));
      } catch (Exception e) {System.out.println("three"); }
         }
      }


      THE RESULTS:

      SunSolaris:
      samnkona.eng.sun.com/129.144.173.150
      129.144.173.103/129.144.173.103
      129.144.173.150/129.144.173.150

      Win32:
      samnkona.eng.sun.com/129.144.173.150
      two
      129.144.173.150/129.144.173.150

      Mac:
      samnkona.eng.sun.com/129.144.173.150
      129.144.173.103/0.00.29
      129.144.173.150/129.144.173.150




      This test was a response from the following mail to fp.bugs.

      >From: "Stephen R. Pietrowicz" <###@###.###>
      This does not look like form output to me.


      I submitted a bug report against 1.0.1's networking code. It was fixed
      under UNIX, but the fix was not applied to Win95/WinNT. I suspect the
      problem may exist under Mac as well, since this is a fix that has to
      be applied to the native library code.

      Here's a description of the problem that I submitted before:

      --------
       
      Basically, if you do:
                      
                      InetAddress.getByName("141.142.2.2");
       
      using some internet address (that one above is newton.ncsa.uiuc.edu)
      other than the machine you are running the test on, and exception is
      thrown.
       
      I just spent a few minutes looking for this, and found the problem.
       
      The problem is that the native library routine that handles the lookup.
      The routine getAllByName eventually will call the lookupAllHostAddr()
      method, which turns into the native call:

       java_net_InetAddress_lookupAllHostAddr()
       
      That call throws an exception if it sees a digit in the first place of a
      host's name:
       
      >From socket.c in src/solaris/net:
       
          javaString2CString(host, hostname, sizeof (hostname));
          if (isdigit(hostname[0])) {
              SignalError(0, JAVANETPKG "UnknownHostException", hostname);
              return 0;
          } else if ((hp = gethostbyname(hostname)) != NULL) {
       
       
      In the routine, java_net_InetAddress_lookupHostAddr(), it's handled
      correctly:
       
          javaString2CString(host, hostname, sizeof (hostname));
          if (isdigit(hostname[0])) {
              /*
               * This is totally bogus. inet_addr returns a 4-byte value
               * by definition, thereby making the transition to 64-bit IP
               * addresses much harder. It should instead write into a
               * user-supplied "struct in_addr"! We'll deal with this
               * later when 64-bit IP addresses are more of a reality -
               * csw.
               */
              unsigned long iaddr = inet_addr(hostname);
       
      [stuff to check and copy the iaddr deleted]
       
      As the comment says, once 64-bit addresses are around, this has to be
      revisited, but if java_net_InetAddress_lookupAllHostAddr() would
      attempt to decode the hostname using inet_addr, it will fix the bug
      until the net goes 64-bit.

      ------------
      This same code exists under win32/net/socket.c. As I said, the fix
      was applied to UNIX, but it wasn't applied to Windows 95/NT.

      Thanks for fixing this. This craters our stuff right now, and we're
      attempting to get a workaround together before our announced release of
      our project.

      Steve

      --

      fyi. The bug id 1243494 was assigned to Steve's first report of the problem

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              djbrown David Brown (Inactive)
              Reporter:
              duke J. Duke (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: