[the text from the user is reformatted and more explanations
are added after exchanging e-mail (  xxxxx@xxxxx  ]

The problem appears when a machine that has more than one
IP addresses tries to use a ftp URL to get something. The two
IP addresses are not routable one to another - this situation
is normal for a machine connected to an internal LAN with some
unroutable addresses (example 10.1.1.1) and with a dial up
connection.

When the ftp protocol binds a server socket for receiving data
from the server it send the socj`ket IP and port to the server
so that the server can connect to it. The address sent to the server
is the one returned by InetAddress.getLocalHost().getAddress(). 
When the host has multiple addresses there is no way to reliably
tell which one should be returned  - the internal one will not
wrok when connecting to an external host and the external one
will not work when connecting to an internal host.

A possible suggested fix is to use the local address from the
client socket already connected to the server - if the server can
talk to it and the server socket is bound with inAddrAny then
this should work. The question is wether the getLocalAddress()
[acctually getsockname() in the C library] will return the  customer 
address for a connected socket in the case of multiple IP addresses.

Here is the test case sent by the user:

import java.io.*;
import java.net.*;

/**
 *
 * Program to snarf files from a random website.
 *
 */
public class Snarf {
  public static void main(String[] args) {
    InputStream inStream = null;
    OutputStream outStream = null;

    try {
      // Check args.
      if (args.length < 2) {
	throw new IllegalArgumentException("Wrong number of arguments.");
      } else {
	String urlRoot = args[0];
	for (int i = 1; i < args.length; i++) {
	  URL turl = new URL(urlRoot + args[i]);
	  System.out.println("Snarfing " + turl + " via " +
			     turl.getProtocol() + " on port " +
			     turl.getPort() + ".");
	  String protocol = turl.getProtocol();
	  int port = turl.getPort();
	  String host = turl.getHost();
	  String file = turl.getFile();
	  turl = null;
	  URL url = new URL(protocol, host, port, file);
	  URLConnection urlConnection = url.openConnection();
	  inStream = urlConnection.getInputStream();
	  outStream = new FileOutputStream(args[i]);
	  byte[] buffer = new byte[1096];
	  int bytes_read = 0;
	  while((bytes_read = inStream.read(buffer)) != -1) {
	    outStream.write(buffer, 0, bytes_read);
	    System.out.print(".");
	  }
	  System.out.println("\nDone with " + url);
	  inStream = null; outStream = null; buffer = null; url = null;
	}
      }	// Args were OK.
    } catch(Exception e) {
      // Bail informatively.
      System.err.println(e);
      System.err.println("Usage: java Snarf URL files ...");
    } finally {			// Always close streams!
      try {
	inStream.close();
	outStream.close();
      } catch(Exception e) {
	/* NOTHING */
      }
    }
  }
}
(Review ID: 22303)
======================================================================

N/A

The suggested fix of obtaining the local address of the connected
socket seems like a good one. We should also implement PASV mode
(bugid 4191863) which will eliminate the need to use the PORT command
most of the time and thereby avoid this issue entirely.

  xxxxx@xxxxx   1998-11-25

I also encountered this problem when writing an FTP client.  My client had to
work on laptops that had ethernet cards and modems.  When I used the ethernet
card everything worked fine, because only one IP address was returned as
localhost and it was the correct one.  However, when dialed in I would get the
IP address for the ethernet card instead of the one for the PPP adapter.
I tried the fix suggested above and it did NOT work.  However, I was able to
figure out a workaround.  I found that getAllByName() would return BOTH IP
addresses when the computer was dialed in, and it always returned them in the
same order.  I gave the user a way to specify which IP address belonged to the
PPP adapter, and whenever getAllByName returns more than one IP address the
program knows which one to use.
I am not happy with this workaround, but it is better than nothing until this
bug is fixed.

It's ludicrous this bug hasn't been fixed in over two years.  It requires
changing one line of code in sun.net.ftp.FtpClient.  I'm I really supposed to
believe that Sun is developing robust networking software in Java, when a
trivial bug like this is ignored for two years?

This problem remains in JDK1.3 - what's the point of a fix
nobody can use? This is causing a real annoyance for me.

I seem to be getting this problem but on a linux machine
which only has a dial up adaptor. Its giving out 127.0.0.1
as its address! 

And has this finally been fixed in 1.4?

This bugfix must be put back into previous Java releases
(e.g. 1.2.3, 1.3.2) or it makes them largely unusable for
many network operations.

This problem hangs my whole application, which is designed
to handle communication failures gracefully, but can't
handle this gracefully because there's no exception thrown
and no timeout (well, maybe after 2 hours or so it might.)

Several people have put a lot of time into detailing 
EXACTLY what is wrong with this and how to fix it. WHAT IN 
THE NAME OF GOD IS GOING ON AT SUN. To those that have put 
all the effort. Now I at least know what is wrong with the 
software. Thank You. SUN: ->FIX THIS BUG<-

I wasted 10 hours tracking this down. I need to trust that 
when I call a Java method, it doesn't lie to me. Not good 
enough - must try harder.