FTP problem: connection going idle or missing; takes a minute to refresh

Question

Level 1

0 points

FTP problem: connection going idle or missing; takes a minute to refresh

Hi, i hope i explain myself, please forgive me my lack of tech-language and if i'm redundant:

In my office we got a G5 dual that we turn into a server (Mac OS Server 10.5.7) for a couple of websites (for external use). I need this guys to have FTP access for some file sharing. Server is up, websites and databases are running fine, remote administration in local and external network is flawless, everything seems fine, except for the FTP: When i connect with cyberduck or any other FTP app, the authentication is done quickly but then, the connection goes idle (like it didn't exists) so the folder listing takes about a minute. Then, as soon as you get the listing, if you try to put something (i.e, a big file of 50mb, using the local network), the app makes a quick login but then it goes idle again (same, about a minute) and when the connections appears, the transfer goes really fast, after the transfers ends connection goes idle again a minute before managing the folder listing. I know that the connection "goes idle" or "disappears" because i started using little snitch to take a look at it. It appears like if the ftp app wasn´t even trying to connect, then suddenly, it´s there and connects/transfers. Every operation takes this minute to get going. If i try it with a browser, well, it times out. This is happening in both, local and external connection. But every other service is working cool.

Can you give me any ideas about this matter?

Message was edited by: rdlfo

G5 Dual, Mac OS X (10.5.7), Server

Posted on Jul 16, 2009 8:08 PM

Reply

Answer 1

Jul 16, 2009 8:48 PM in response to rdlfo

Have you tried another FTP client app? Like Filezilla?:

http://filezilla-project.org/

Reply

Answer 2

rdlfo Author

Level 1

0 points

Jul 17, 2009 8:38 AM in response to rdlfo

Hi, the problem is not the FTP app -thanks Mabel- (every app has the same results, i even tried with the Terminal), it's something in the server or in the network. At night I turned off the welcome message (which consisted of only 4 words) and the conection seemed to go ok. But now, the problem is going again, it takes 80 seconds to get a transfer intitated (once initiated it won´t stop, i just put a 200mb file in 70 seconds). Every listing, every refreshing, every folder entry, every petition takes this (aprox) 80 seconds to get going. It's not a fluid connection, it's more like if one has to wait for his turn in a queue.

any ideas? Thanks in advance!

Reply

Answer 3

Jul 17, 2009 10:36 AM in response to rdlfo

Does anything appear in the System log, FTP error log, or in the FTP transfer log that might give a clue as to the slowdown? You said that you have a database and a few websites running on the same server. Is there any issue with CPU load? Those transfer times look a bit slow. A test upload of a 240MB file from a Win XP client took 42 seconds and 287MB file upload took the same time from a Mac -both using Filezilla 3.2.6.1. I'd take a look at the server processes and your network as causes.

Reply

Answer 4

rdlfo Author

Level 1

0 points

Jul 17, 2009 4:46 PM in response to Mabel O'Farrell

Hi, thanks for your time! CPU load seems ok (almost nothing, currently i'm the only user). It's going kind of weird, i don't know if it sends a message or something, because now (from 5 hours to this posts' date), in Terminal and Transmit, first listing takes the 80 seconds lapse, then it works nice. That cannot be said about Cyberduck, takes 80 seconds to start anything. But on CUTEFtp, even the first listing goes fast. I managed to get my work done using Transmit and the Terminal, but i wonder why this is happening. I checked the system logs, and it looks like this:

(STARTING CONNECTION, goes "ghost-idle" for first listing)
ftpd: XXX.XXX.XXX.XXX: connected: IDLE [43770]: USER_PROCESS: 43769 ftp43769

(MANAGES to get FIRST LISTING)
ftpd: XXX.XXX.XXX.XXX: connected: IDLE [42286]: DEAD_PROCESS: 42285 ftp42285

Then, i tried a second listing on a subfolder while watching the log. Nothing recorded in the minute i asked for the listing. Took a little less than the 80 secs i've been mentioned to get the subfolder listed but nothing was recorded into the log.

Thanks!

Reply

Answer 5

rdlfo Author

Level 1

0 points

Jul 17, 2009 4:47 PM in response to rdlfo

By the way, Filezilla goes "Timeout" on first listing. It connects, authenticates, but cannot manage to list anything.

Reply

Answer 6

MrHoffman

Level 10

146,533 points

Jul 18, 2009 6:04 AM in response to rdlfo

Ok, rather than going for the most problematic protocols known to modern networking, try with something simple.

Don't test with ftp, test with sftp.

I would initially suspect you're running into issues with firewalls here; beyond transmitting your credentials in cleartext, the design of ftp is inherently extremely allergic to firewalls, and particularly to transfers over connections that involve both local and remote firewalls.

ftp is funky here in that it needs two connections between the client and the server, and the second connection tends to get blocked. An ftp active-mode connection has a back-connect from the ftp server to an ephemeral port on the client; traversing firewalls from server to client. An ftp passive-mode connection has a forward connection; a second parallel connection from the client to a specified (usually) ephemeral port on the ftp server; traversing the firewalls.

Ignoring explicit transfer-mode selection, various clients can (transparently) try to switch between active and passive, too.

My preferred approach is to avoid ftp. At all. Use sftp. sftp is far easier to punch through firewalls. And sftp doesn't transmit your username and password in cleartext, for that matter.

The other part of this effort is around ensuring proper file protections and ownership in the web server directories. The web-facing file ownership should be user:www (often root:www) and the www user (the web server) should be able to read its web files, but (in general) should not be able to write to the web files or directories. This is defensive.

Reply