Timeout While Retrieving Directory Listing

[Whaley, Jason]

Here's another problem I've been beating my head over.

Per the instructions on the VirtualUsers Readme, I created a user and
group for virtual users (ftpuser:ftpgroup). I've created a virtual user
using the following command:

pure-pw useradd jtwhaley2 -u ftpuser -d /path/to/dir -m

I've started pure-ftpd with the following command:

pure-ftpd -Eb -j -A -lpuredb:/etc/pureftpd.pdb

The user gets authenticated, but I receive the following error at the
end of the connection:

Error: Timeout detected!
Error: Could not retrieve directory listing

I've ensured the directory above the home directory I'm assigning has
rwx for both ftpuser and ftpgroup.

Any ideas?

Here's the rest of the ftp request/response:

Response: 220---------- Welcome to Pure-FTPd ----------
Response: 220-You are user number 3 of 50 allowed.
Response: 220-Local time is now 13:10. Server port: 21.
Response: 220-This is a private system - No anonymous login
Response: 220-IPv6 connections are also welcome on this server.
Response: 220 You will be disconnected after 15 minutes of
inactivity.
Command: USER jtwhaley2
Response: 331 User jtwhaley2 OK. Password required
Command: PASS ********
Response: 230-User jtwhaley2 has group access to: 99
Response: 230 OK. Current directory is /
Command: FEAT
Response: 211-Extensions supported:
Response: EPRT
Response: IDLE
Response: MDTM
Response: SIZE
Response: REST STREAM
Response: MLST
type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
Response: MLSD
Response: TVFS
Response: ESTP
Response: PASV
Response: EPSV
Response: SPSV
Response: ESTA
Response: 211 End.
Command: SYST
Response: 215 UNIX Type: L8
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is your current location
Command: TYPE A
Response: 200 TYPE is now ASCII
Command: PASV
Response: 227 Entering Passive Mode ($IPAddressOfServer)
Command: LIST
Response: 150 Accepted data connection
Response: 226-Options: -l
Response: 226 0 matches total
Error: Timeout detected!
Error: Could not retrieve directory listing




---------------------------------------------------------------------
To post a new message, e-mail: ***@pureftpd.org
To unsubscribe, e-mail: list-***@pureftpd.org
For additional commands, e-mail: list-***@pureftpd.org

[DervishD]

Hi Jason :)

Post by Whaley, Jason
The user gets authenticated, but I receive the following error at the
Error: Timeout detected!
Error: Could not retrieve directory listing

I've had the same problem with ProFtpd server due to the EPSV
command. If I don't disable EPSV mode in my client, it hangs forever
while doing a directory listing (for example). Your problem looks
different, anyway, and I cannot reproduce here, but just in case try
to do "epsv off" in your client (or whatever command does the same in
your client).

Otherwise, I can try to test if you create an account for me so I
can test from my machine.

Raúl Núñez de Arenas Coronado

[Whaley, Jason]

Hello Again Raul,

I disabled passive connections in Filezilla (my test ftp client), and I am receiving the same timeout.

Ideally I want my users (very technically unsavvy) to connect through IE so I will need to get this working without having clients adjust any settings.

I used ftp from the command line from my work machine and I could connect and be placed in the chroot'ed directory for the ftp user. However, an issuance of dir or ls takes 60 seconds exactly everytime to complete from the command line ftp, but does work. The behavior of ls and dir is that the output is shown, but hangs for 60 seconds, then the report is shown.

For instance:

ftp> dir
200 PORT command successful
150 Connecting to port 3047
-rw-r--r-- 1 99 99 82 Jan 19 08:14 ezreg.dat

//WAIT FOR 60 SECONDS

226-Options: -l
226 1 matches total
ftp: 67 bytes received in 60.00Seconds 0.00Kbytes/sec.


Using put works fine and as expected. Using get works but again, takes exactly 60 seconds to complete for only a <1kb sized file.

I tried ftp from localhost and everything worked well, ls and dir commands worked in milliseconds, as expected.

Could this be a port issue when connecting from a client? It seems to me it may be something network related since ftp'ing from localhost works flawlessly.

Thanks,
Jason

-----Original Message-----
From: DervishD [mailto:***@dervishd.net]
Sent: Wednesday, January 18, 2006 2:38 PM
To: Whaley, Jason
Cc: ***@pureftpd.org
Subject: Re: [pureftpd] Timeout While Retrieving Directory Listing

Hi Jason :)

Post by Whaley, Jason
The user gets authenticated, but I receive the following error at the
Error: Timeout detected!
Error: Could not retrieve directory listing

I've had the same problem with ProFtpd server due to the EPSV
command. If I don't disable EPSV mode in my client, it hangs forever
while doing a directory listing (for example). Your problem looks
different, anyway, and I cannot reproduce here, but just in case try
to do "epsv off" in your client (or whatever command does the same in
your client).

Otherwise, I can try to test if you create an account for me so I
can test from my machine.

Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...



---------------------------------------------------------------------
To post a new message, e-mail: ***@pureftpd.org
To unsubscribe, e-mail: list-***@pureftpd.org
For additional commands, e-mail: list-***@pureftpd.org

[DervishD]

Hi Jason :)

Post by Whaley, Jason
I disabled passive connections in Filezilla (my test ftp client),
and I am receiving the same timeout.

My problem was not with passive connections, but with *extended*
passive connections. Anyway, this problem doesn't seem to be related
with that.

Post by Whaley, Jason
I used ftp from the command line from my work machine and I could
connect and be placed in the chroot'ed directory for the ftp user.
However, an issuance of dir or ls takes 60 seconds exactly
everytime to complete from the command line ftp, but does work.
The behavior of ls and dir is that the output is shown, but hangs
for 60 seconds, then the report is shown.

I had exactly the same problem with the default ftp server (I
don't remember which one) under SuSE five years ago. I don't remember
if I finally solved it.

Post by Whaley, Jason
Could this be a port issue when connecting from a client? It seems
to me it may be something network related since ftp'ing from
localhost works flawlessly.

You have to make sure that you're using the correct range of
ports for passive mode (the same that your OS says you can use. Under
Linux, you can find those under /proc/sys/net/ipv4/ip_local_port_range).

I must confess that I'm completely lost with your problem. If I
were you, I would try, in this order:

- Try a few ftp clients. Some of them are extremely dumb and may
need workarounds in the server (since fixing proprietary clients is
impossible).

- Try another ftp server in the machine to see if the problem is
pure-ftpd's fault or network's fault.

- Try a precompiled version (or a prepackaged one, if you happen
to be using a distribution instead of a DIY box).

- Locate where the heck the server is spending those 60 seconds
(or the client, if the delay is client's fault).

- Sniff the network traffic when the delay occurs, just to make
sure the problem is not an obvious one (cabling, devices, etc.).

If other ftp servers work OK, then the problem is related to
pureftpd (at least partially) and then you should try to track down
where the server is sleeping, or use the other ftp server if time is
an issue.

If you want me to try your server, just tell. On the other hand,
if you need to test your clients against a working pureftpd, just
tell me and I'll give you a disposable account in my pureftpd so you
can test if the problem exists too.

Raúl Núñez de Arenas Coronado

[Whaley, Jason]

Well, for some strange reason it now works! The only action I took in between the tests before I sent the last email and this one was rebooting my local machine and restarting pure-ftpd on the server.

Very strange. Unfortunately I wasn't logging anything from pure-ftpd, so I'm not sure what might have occurred differently.

At this point, I'm just going to cross my fingers and hope it continues to work.

Again, thanks for your help.

--Jason

-----Original Message-----
From: DervishD [mailto:***@dervishd.net]
Sent: Thursday, January 19, 2006 10:35 AM
To: Whaley, Jason
Cc: ***@pureftpd.org
Subject: Re: [pureftpd] Timeout While Retrieving Directory Listing

Hi Jason :)

Post by Whaley, Jason
I disabled passive connections in Filezilla (my test ftp client),
and I am receiving the same timeout.

My problem was not with passive connections, but with *extended*
passive connections. Anyway, this problem doesn't seem to be related
with that.

Post by Whaley, Jason
I used ftp from the command line from my work machine and I could
connect and be placed in the chroot'ed directory for the ftp user.
However, an issuance of dir or ls takes 60 seconds exactly
everytime to complete from the command line ftp, but does work.
The behavior of ls and dir is that the output is shown, but hangs
for 60 seconds, then the report is shown.

I had exactly the same problem with the default ftp server (I
don't remember which one) under SuSE five years ago. I don't remember
if I finally solved it.

Post by Whaley, Jason
Could this be a port issue when connecting from a client? It seems
to me it may be something network related since ftp'ing from
localhost works flawlessly.

You have to make sure that you're using the correct range of
ports for passive mode (the same that your OS says you can use. Under
Linux, you can find those under /proc/sys/net/ipv4/ip_local_port_range).

I must confess that I'm completely lost with your problem. If I
were you, I would try, in this order:

- Try a few ftp clients. Some of them are extremely dumb and may
need workarounds in the server (since fixing proprietary clients is
impossible).

- Try another ftp server in the machine to see if the problem is
pure-ftpd's fault or network's fault.

- Try a precompiled version (or a prepackaged one, if you happen
to be using a distribution instead of a DIY box).

- Locate where the heck the server is spending those 60 seconds
(or the client, if the delay is client's fault).

- Sniff the network traffic when the delay occurs, just to make
sure the problem is not an obvious one (cabling, devices, etc.).

If other ftp servers work OK, then the problem is related to
pureftpd (at least partially) and then you should try to track down
where the server is sleeping, or use the other ftp server if time is
an issue.

If you want me to try your server, just tell. On the other hand,
if you need to test your clients against a working pureftpd, just
tell me and I'll give you a disposable account in my pureftpd so you
can test if the problem exists too.

Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...



---------------------------------------------------------------------
To post a new message, e-mail: ***@pureftpd.org
To unsubscribe, e-mail: list-***@pureftpd.org
For additional commands, e-mail: list-***@pureftpd.org

[DervishD]

Hi Whaley :)

Post by Whaley, Jason
Well, for some strange reason it now works! The only action I took
in between the tests before I sent the last email and this one was
rebooting my local machine and restarting pure-ftpd on the server.

Probably your local machine had some networking problems that
vanished when rebooting (a damaged driver, a stunned network card,
etc.)

I have VERY weird networking problems a couple of months ago with
a network card that was dieing: network transfers were OK *except*
for NetBIOS, which was painfully slow (well, it's always painfully
slow...). Few days and a few reboots later, the card just stopped
working: the lights flashed like crazy even when no transmissions
were taking place, etc. Check your network card ;)

Post by Whaley, Jason
Very strange. Unfortunately I wasn't logging anything from
pure-ftpd, so I'm not sure what might have occurred differently.

If it works, don't worry about that right now. Probably it was
just a transient problem, or a network interface which is dieing.

Post by Whaley, Jason
Again, thanks for your help.

You're more than welcome ;) And well, I'm not helping much, I'm
afraid O:)

Raúl Núñez de Arenas Coronado

[Chris Prew]

I was running PureFTPD 1.0.20 fine on 10.4.3. I upgraded to
10.4.4, and it worked fine until I started to get a little bit of
traffic. Then, all my users would connect (via Active FTP),

My secure.log shows the process authorized the user, but then the FTP
log just shows everybody sitting idle until the FTP client would time
them out. Eventually, the server stops accepting connections and
locks up.

So the log looks like this:

Jan 20 22:01:4 myserver pure-ftpd (?@clientip) [INFO] New connection
from cleintip
Jan 20 22:01:40 myserver pure-ftpd: (?@clientip) [DEBUG] Command
[user] [username]
Jan 20 22:01:41 myserver pure-ftpd: (?@clientip) [DEBUG] Command
[pass] [<*>]

Five minutes later they time out. Let me reiterate that the server
was working properly for a little while before this occurred.

I rebooted, and got the same behavior after about 20 minutes. The
same a third time. I finally restored back to an image of Mac OS X
Server 10.4.3 and now everything is OK again.

Anybody else seen this? Any idea what might be causing it?

I run standalone using -AEBHdx4 -o -I 5 -c 999 -L 50000:10 -U
027:027 -p 5000:5999. I authenticate to the OS X Server via PAM,
which seems to work with or without -l pam, so maybe I just _think_
I'm using PAM.

Any thoughts appreciated

Chris



---------------------------------------------------------------------
To post a new message, e-mail: ***@pureftpd.org
To unsubscribe, e-mail: list-***@pureftpd.org
For additional commands, e-mail: list-***@pureftpd.org

[Frank Denis (Jedi/Sector One)]

Post by Chris Prew
I was running PureFTPD 1.0.20 fine on 10.4.3. I upgraded to
10.4.4, and it worked fine until I started to get a little bit of
traffic.

Hi Chris,

I'm running 10.4.4, too, I'll have a look tomorrow.