FTPClient yielding invalid IP6 address

[Thomas Griffith]

Hello. If you have a minute...

String server="ftp://blah.com/";
FTPClient ftpClient=new FTPClient();
ftpClient.connect(server);

Getting invalid IP6 address exception. I've tried all these for server...

ftp://blah.com/
ftp://blah.com
blah.com/
blah.com

EDIT...the last option seems to establish an FTPClient....

String server=blah.com;

But when I try...

server="blah.com/Folder";

I get unknownHostException.

[Tim Moores]

But when I try...

server="blah.com/Folder";

I get unknownHostException.

The error message really speaks for itself - the connect method expects a host name, not an URL, and not a directory. Once you have established a connection, the FTPClient has various methods for working with files and directories. Its javadocs have example code that should get you going.

[Thomas Griffith]

Hello. Thanks so much. I was able to FTP by chopping off the ftp://....using the following...

String server="blah.com";
FTPClient ftpClient=new FTPClient();
ftpClient.connect(server);

So my next step is to test second server with FTPS...

String server="blah2.com";
FTPSClient ftpsClient=new FTPSClient();
ftpsClient.connect(server);

But I am receiving "connection refused". I checked the FTPS settings on blah2 (via the network admin guy) and it has port 990 listed...confirmed 990 is listed and listening  via netstat -na | find "990" from the server command line...so although 990 is FTPS default, I tried to explicitly feed the port into the connect...and this times out...

String server="blah2.com";
int port=990;
FTPSClient ftpsClient=new FTPSClient();
ftpsClient.connect(server, port);

Does anybody have any suggestions? I know it's not the login credentials because the ftpsClient.getReplyStrong() would return invalid user or something like that. The code presumably isn't even getting to the authentication, bombing at the connect.

One other thing, the blah FTP site is on-prem Windows, the blah2 FTPS site has been created on a Windows instance moved into AWS (via CloudEndure). I don't think that should affect this but I've heard strange things happening with FTP and AWS. Any input would help. Thank you so much.

[Paul Clapham]

So to summarize: All of your tests are trying to connect to ports on "blah.com". (Clearly you have anonymized the name, which is no problem, as long as it's always the same host you're trying to connect to).

And FTPClient connects to port 21 on that server.

And FTPSClient doesn't connect to port 21 on that server -- "connection refused".

And FTPSClient doesn't connect to port 990 on that server -- times out.

Assuming that's all correct, then here's what it looks like to me: Port 21 on the server is running an FTP server, so FTPClient can connect to it. But if FTPSClient tries to connect to the FTP server, it must be the case that the FTP server (and not the network) is refusing the connection. I'm not sure why that would happen but perhaps it's normal. But anyway that isn't what you really need to do.

But if your FTPSClient tries to connect to port 990 on that server and times out, then either the server listening on port 990 is unresponsive or the network won't let you connect to port 990 because of a firewall or some similar issue. I could suggest you try to ping port 990 but it's probably better to get the network guy to help you work through the connection failure.

[Thomas Griffith]

Hi. Thank you. Close to that. blah.com and blah2.,com are separate servers, blah being an FTP site, blah2 was moved/mirrored to AWS and had FTPS installed. I heard some stuff about AWS refusing FTP/FTPS so I built code to connect to blah with regular FTP. Once I established that functionality (transferring a txt file to the site),  I converted the  FTPClient to FTPSClient and changed the server from blah to blah2 in the connect. Then I received connection refused.

After that, I added port 990 explicitly to the FTPSClient.connect(server, port) and received a timeout.

UPDATE...server admin guy said that FTPS was also installed on blah (non-AWS) over port 990. So I tried the same thing...

FTPSClient.connect("blah.com", 990)

and receive a timeout. So I don't think it's an AWS thing at this point.

I'm getting timeout over port 990 on both blah (non-AWS) and blah2 (AWS).

[Tim Holloway]

There are 3 basic reasons for not getting a connection via FTPS:

1. There's no available network path between client and server (no route to host).

2. There's no server listening at that port on that host.

3. There's a firewall blocking connections to that port on that host - either on the host itself or on one of the routing stages between client and host. It can even be on the client itself, but few clients firewall outgoing traffic.

Amazon has a webapp that can manage its firewall between you and your Amazon-based resources.

[Thomas Griffith]

Thank you. I think I can eliminate 1) as connect and upload to FTP works on blah via port 21 and 2) is out because netstat shows port 990 "listening". I asked admin guy if anything could be messing with 990.

I've read some stuff where FTPS uses 989 for data transfer and 990 for something else...content transfer or whatever its called But I don't think that is anything because admin guy listed 990 on the FTPS install wizard thing. 989 is not listed by netstat, but nor is 20 for working the FTP site.

[Tim Holloway]

Port 989 is only opened on-demand, I think, for active SFTP. For passive SFTP high-number ports are used. A similar arrangement to FTP ports 20 and 21. Don't ask me for explanations or details, I forgot most of what I used to know.

I've very rarely run FTP in recent years. Mostly I use SCP or rsync.

[Matthew Bendford]

As there's TLS involved, another option for the timeout could be some crypto issues. I once set up some crypto code myself and used SecureRandom.getInstanceStrong() on a Linux server - which results in both the seed as well as the random data both read from /dev/random only - and as my server somehow ran out of entropy it delayed all crypto stuff.
So, as there's no TLS_ALERT it doesn't seem to be a certificate or cert path chain issue but rather the server seem to not have sufficient entropy and hence causing the timeout.

@Tim
SFTP != FTPS - while FTPS is FTP over TLS ... SFTP is FTP over SSH - which comes closer to SCP

[Thomas Griffith]

Hi. Thanks to your input, I've been reading some stuff on TLS/SSL and implicit (FTPS) / explicit (FTPES). Seeing that port 990 was set up and is typical of implicit TLS, I noticed that FTPSClient defaults to explicit and overrode the constructor with the isImplicit boolen...

FTPSClient ftpsClient=new FTPSClient(true)

I also called ftpsClient.getEnabledProtocols and it returned TLSv1.2, just to confirm.

Good news is I get a User logged in return string back now. The bad is that the ftpsClient.storeFile(...) hangs...

[Matthew Bendford]

Aside from crypto: Using Wireshark can reveal if data are transmitted at all and hence your code "hangs in the I/O" - or if there're no data send.

As for implicit vs explicit: Yea, I forgot about that one. It's about if the connection is encrypted right away or if it's upgraded later like starttls for smtp/imap.

[Thomas Griffith]

I resolved it through a factor of two things. The first was Iwas looking at the wrong partition to check if the files were uploaded. Secondly, I added fcpsClient.enterLocalPassiveMode() and it seemed to work. thank you.

[Matthew Bendford]

Well, that's because how FTP was designed: There's an active mode and a passive mode.
Back then when FTP was designed there were hardly any attackers on the wire and hence firewalls weren'T a thing - let alone NAT. As by design, an active FTP connection the client sends the server a port and the server connects back to the client. This doesn't work unless you have an open connection without any firewall or NAT at all. Hence these days pretty much only passive FTP is used: By this the server opens a second port the client connects to for data transfer.

So, to sum up: Your solution is to
a) use passive mode FTP
b) use implicit TLS

Crypto most often isn't as easy as to add a TLS layer - although it's designed to be transparent.