vsftpd: 421 Data timeout. Reconnect. Sorry
 

I have vsftpd up and running and one client I'm observing is having problems restarting a session. Enclosed below is the ftp protocol log. This host has been doing this all night. Everyone of these ends with a 421 timeout. I have both passive and active ftp enabled. I do not know what client the users using nor do I know how it's config'ed. I can't get ahold of him. Anyone ever experience anything like this? Sure seems like everything is set up right on my side.

Thanks,

-e

Thu May 08 10:20:21 2003 [pid 25699] FTP command: Client "64.XXX.9.164", "AUTH TLS"
Thu May 08 10:20:21 2003 [pid 25699] FTP response: Client "64.XXX.9.164", "530 Please login with USER and PASS."
Thu May 08 10:20:22 2003 [pid 25699] FTP command: Client "64.XXX.9.164", "USER XXXXX"
Thu May 08 10:20:22 2003 [pid 25699] [XXXXX] FTP response: Client "64.XXX.9.164", "331 Please specify the password."
Thu May 08 10:20:22 2003 [pid 25699] [XXXXX] FTP command: Client "64.XXX.9.164", "PASS <password>"
Thu May 08 10:20:22 2003 [pid 25698] [XXXXX] OK LOGIN: Client "64.XXX.9.164"
Thu May 08 10:20:22 2003 [pid 25700] [XXXXX] FTP response: Client "64.XXX.9.164", "230 Login successful. Have fun."
Thu May 08 10:20:22 2003 [pid 25700] [XXXXX] FTP command: Client "64.XXX.9.164", "CWD /uploads/tab2002-06-04.shnf/tab2002-06-04d1.shnf"
Thu May 08 10:20:22 2003 [pid 25700] [XXXXX] FTP response: Client "64.XXX.9.164", "250 Directory successfully changed."
Thu May 08 10:20:22 2003 [pid 25700] [XXXXX] FTP command: Client "64.XXX.9.164", "TYPE I"
"TYPE I"
Thu May 08 10:20:22 2003 [pid 25700] [XXXXX] FTP response: Client "64.XXX.9.164", "200 Binary it is, then."
Thu May 08 10:20:23 2003 [pid 25700] [XXXXX] FTP command: Client "64.XXX.9.164", "PORT 64,233,9,164,135,58"
Thu May 08 10:20:23 2003 [pid 25700] [XXXXX] FTP response: Client "64.XXX.9.164", "200 PORT command successful. Consider using PASV."
Thu May 08 10:20:23 2003 [pid 25700] [XXXXX] FTP command: Client "64.XXX.9.164", "REST 205934081"
Thu May 08 10:20:23 2003 [pid 25700] [XXXXX] FTP response: Client "64.XXX.9.164", "350 Restart position accepted."
Thu May 08 10:20:23 2003 [pid 25700] [XXXXX] FTP command: Client "64.XXX.9.164", "STOR tab2002-06-04d1t04.shn"
Thu May 08 10:20:23 2003 [pid 25700] [XXXXX] FTP response: Client "64.XXX.9.164", "150 Go ahead make my day^W^W^Wsend me the data."

I'm having the same problem! Is this issue on your server only isolated to a particular client or do other clients experience this as well?

People using DSL or Cable, don't seem to have a problem with this when connecting to my server. This issue seems to isolated to dial up connections. Now, I don't know if the Cable/DSL crowd doesn't experience this since their connection doesn't have time to time out (most of them only upload 3 to 4 MB files) or the time between TCP commands sent to the server is short enough to let it know that the connection is still alive?!

In any case if anyone stumbles on a solution, or even a clue, PLEASE, PLEASE let us know!

Thanks in advance.

My solution was to get rid of vsftpd.

Found some reference in Bugzilla about vsftpd having this problem.

I switched to proftpd and have been up and running for 21 days and served over 200 GB's.

Get rid of vsftpd and install proftpd

Contact me if you need any config help for proftpd.

vsftpd update
 

I had the same problem.
The REST command did cause a non answer of the server, and thus the communication failed and filezilla tried to connect over and over to resume the file transfer which was already started.

This happened with vsftpd version 2.0.1-5 for RHEL4. Using the update version 2.0.1-8 did solve the problem. Now the resume functionnality of FileZilla works like a charm.
I cannot see this change done in the changelog of vsftpd, but maybe it is a problem which was introduced by redhat and thus it would have been fixed in V2.0.1-8.

So just update to V2.0.1-8 if you have the 2.0.1-5 installed. Versions in between I have no idea.

HTH
Regards,
Daniel

lsakhvoruk

I realise this is a extremely old thread so i am not holding out too much for a response. However did you ever get the the bottom of your issue? I am currently going through the same as you were, Cable/ADSL customers are all collecting & delivering files absolutely fine. However there is still one customer that still delivers the data via a dial up connection. Over the past 6 months or so we have seen the data transfer time out about 40% of the time. Just curious as to whether you found a resolution to you problems with the dial up data transfers.