Solaris 9: PASV mode: FTP client fails after 1.5/2 hrs

Question

Hi,

We are experiencing a strange problem whereas the edtFTPj FTPclient when run against Solaris 9 ftp daemon (out of the box), exits after roughly 1.5 to 2 hrs.

The client is using PASV mode for all the interaction with the FTP server and is able to do activities in this mode for first 1.5/2 hrs.

The error reported by the edtFTPj client when exiting is:

"425 Can't open passive connection: Permission denied."

Has anyone faced similar to this? Would really appreciate any pointers to locate the problem.

thanks,
Anand

Answer 1

Are you doing lots of transfers? The server could run out of sockets if you are

Hi,

We are experiencing a strange problem whereas the edtFTPj FTPclient when run against Solaris 9 ftp daemon (out of the box), exits after roughly 1.5 to 2 hrs.

The client is using PASV mode for all the interaction with the FTP server and is able to do activities in this mode for first 1.5/2 hrs.

The error reported by the edtFTPj client when exiting is:

"425 Can't open passive connection: Permission denied."

Has anyone faced similar to this? Would really appreciate any pointers to locate the problem.

thanks,
Anand

Answer 2

We tried both: doing lots of transfers, and also by waiting for a long time (30 mins/1 hr) before doing the next transfer.

This has not been a problem with Solaris 8.

Anything else we should try?

Answer 3

Use netstat on Solaris to confirm that there aren't too many sockets in TIME_WAIT. The default is 4 minutes (I think) so waiting for 30 minutes should clear them all up though ...

Perhaps your sysadmin will have an idea of what permissions or kernel parameters are different?

We tried both: doing lots of transfers, and also by waiting for a long time (30 mins/1 hr) before doing the next transfer.

This has not been a problem with Solaris 8.

Anything else we should try?

Answer 4

Here's something to add: One client (a native Windows client - Core FTP Lite) when run for a long time against the same Solaris 9 server, did not crash.

How would one know, when exactly the server will have "too many sockets" open, so that it can't open a new PASV connection (and apparently denies the permission).

Use netstat on Solaris to confirm that there aren't too many sockets in TIME_WAIT. The default is 4 minutes (I think) so waiting for 30 minutes should clear them all up though ...

Perhaps your sysadmin will have an idea of what permissions or kernel parameters are different?

We tried both: doing lots of transfers, and also by waiting for a long time (30 mins/1 hr) before doing the next transfer.

This has not been a problem with Solaris 8.

Anything else we should try?

Answer 5

Just found this:

http://sunportal.sunmanagers.org/piperm ... 02020.html

This talks about some 2 hrs of timeout value. But then it should crash every client which has the same behavior (say opening too many sockets).
I am just wondering as to what is different in edtFTPj that crashes it... :?

Answer 6

The other clients are probably connecting in active (PORT) mode - where the server initiates the connection to the client

Just found this:

http://sunportal.sunmanagers.org/piperm ... 02020.html

This talks about some 2 hrs of timeout value. But then it should crash every client which has the same behavior (say opening too many sockets).
I am just wondering as to what is different in edtFTPj that crashes it... :?

Answer 7

No, the other client was also made to use Passive mode.

The other clients are probably connecting in active (PORT) mode - where the server initiates the connection to the client

Just found this:

http://sunportal.sunmanagers.org/piperm ... 02020.html

This talks about some 2 hrs of timeout value. But then it should crash every client which has the same behavior (say opening too many sockets).
I am just wondering as to what is different in edtFTPj that crashes it... :?

Answer 8

You could log the output from the other client and edtFTPj and compare (if the other client permits logging).

I would think it unlikely that SO_KEEPALIVE is affecting this.

Also, does the FTP server log anything useful?

No, the other client was also made to use Passive mode.

The other clients are probably connecting in active (PORT) mode - where the server initiates the connection to the client

Just found this:

http://sunportal.sunmanagers.org/piperm ... 02020.html

This talks about some 2 hrs of timeout value. But then it should crash every client which has the same behavior (say opening too many sockets).
I am just wondering as to what is different in edtFTPj that crashes it... :?