Active FTP Bug On Machines With Multiple IP Addresses.

[support2]

[support2]

[EDT Support]

In fact, we have anticipated that someone would one day have the problem you are having, but in the five years since the first release noone else has ever reported it, so we have seen no reason to address it. We have a wish-list as long as a railway and are necessarily ruthless in deprioritising low-impact items.

We have considered adding a property similar to your ControlIPAddress but are concerned that it would needlessly confuse the 99.99% (literally) of users who don't need it.

Having said that, we may still do it, but I don't understand why the solution my colleague proposed won't solve your particular problem.

Bruce is not proposing "just checking that an IP address chosen by Windows is on the local machine", which would clearly be pointless. He is proposing checking if ActiveIPAddress (which you set yourself) is on the local machine, and if it is then binding to that address. This is what you proposed yourself initially, but with the additional safeguard that we are checking if ActiveIPAddress is actually on the local machine.

- Hans (EnterpriseDT)

Doing as suggested, and checking to see if the IP address is on the local machine would help for some situations. Especially when Windows chooses the loopback address to listen on. But this does not work when you have several NIC's. If the control socket is created on the wrong interface, you may not be able to initially connect to the FTP server. If you happen to be able to connect to the server, you may not be able to establish the active data connection. The simple property on FTPClient to set the control sockets IP address handles both cases without using logic to enumerate the interfaces on the local machine.

If you think the new property will confuse someone, call it something like "MultipleNicIP" and add a line in the docs describing what it does and when you need to use it.

All you got to do is add a new parameter to FTPControlSocket's constructor to pass the local address, optionally bind to the value before the call to Initialize. In FTPClient all you need is a private variable, and simple property, and pass the private variable to the new constructor. All in all just 10 minutes of work for a slow coder.

[support2]

I realize that this thread is two years old but I recently ran across the same problem.

I tried using passive FTP to connect to the remote server, but that server was returning a port number greater than 42000. For some reason my Windows 2003 server could not connect out over that port. It was not a firewall issue, since I was able to connect using FileZilla from a Windows 7 workstation from behind the same firewall. It was something strange with Windows 2003. The following Microsoft KB article (http://support.microsoft.com/kb/196271) failed to correct the problem. So, I punted to active FTP mode.

Well, that had problems too and it wasn't the firewall either, since FileZilla from the same machine was able to connect using active mode without a problem. I dived into the source code and located the same issue reported by jschafer, i.e. the NewActiveDataSocket method creates an enpoint that's listening to 127.0.0.1, not the fixed 192.168.x.x. IP address on my network card that I specified with the PublicIPAddress property. This 192.168.x.x address is what the NAT on my firewall is expecting. I implemented the fix that jschafer suggested and everything worked perfectly.

So, was there ever any resolution to this issue?

Thanks in advance for any information.

[support2]

So you added a new property to specify the interface that the control socket binds to?

[support2]