1

Problem

Connections on a Proftpd 1.3.6 (updated from 1.3.1 with same issue) are killed while transferring data with message:

421 No transfer timeout (3600 seconds): closing control connection

The time after logging in until getting the error varies, it can be from 5 seconds to some minutes. We examined the logs (excerpts listed below) and cannot find a clear reason for the behavior. The error may occur if only one user is connected and also if concurrent sessions from the same user are open.

Wireshark shows that the "421: No transfer timeout" is sent from the server as a reply to the client.

Proftpd is running on a rather old virtual openSuse system on an ESXi 4.1. Only the ftpusr account is used for FTP transfers.

Thanks for your help in advance.


Log excerpts

FTP client log:

{snip}
150 Opening ASCII mode data connection for xyz_XML_Interface-Rawdata_20171124_16
1300_43864.tmp (597 bytes)
226 Transfer complete
ftp: 611 bytes received in 0.00Seconds 611000.00Kbytes/sec.
200 PORT command successful
150 Opening ASCII mode data connection for xyz_XML_Interface-Rawdata_20171209_06
5800_63895.tmp (443 bytes)
226 Transfer complete
ftp: 456 bytes received in 0.00Seconds 456.00Kbytes/sec.
200 PORT command successful
150 Opening ASCII mode data connection for xyz_XML_Interface-Rawdata_20171230_09
2000_93119.tmp (277 bytes)
226 Transfer complete
ftp: 288 bytes received in 0.00Seconds 288000.00Kbytes/sec.
421 No transfer timeout (3600 seconds): closing control connection
Connection closed by remote host.
ftp> mget *
Not connected.

Proftpd debug output:

The following log has been taken from the screen output when starting proftpd with proftpd -d 5 -c /etc/proftpd.conf -n:

{snip}
2018-02-07 16:25:11,407 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): dispatching PRE_CMD command 'PORT 10,1,70,112,229,162' to mod_core
2018-02-07 16:25:11,407 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): dispatching PRE_CMD command 'PORT 10,1,70,112,229,162' to mod_core
2018-02-07 16:25:11,407 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): dispatching CMD command 'PORT 10,1,70,112,229,162' to mod_core
2018-02-07 16:25:11,407 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): dispatching LOG_CMD command 'PORT 10,1,70,112,229,162' to mod_log
2018-02-07 16:25:11,454 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): dispatching PRE_CMD command 'RETR xyz_XML_Interface-Rawdata_20171129_064100_50277.tmp' to mod_core
2018-02-07 16:25:11,454 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): dispatching PRE_CMD command 'RETR xyz_XML_Interface-Rawdata_20171129_064100_50277.tmp' to mod_core
2018-02-07 16:25:11,454 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): dispatching PRE_CMD command 'RETR xyz_XML_Interface-Rawdata_20171129_064100_50277.tmp' to mod_auth
2018-02-07 16:25:11,454 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): dispatching PRE_CMD command 'RETR xyz_XML_Interface-Rawdata_20171129_064100_50277.tmp' to mod_xfer
2018-02-07 16:25:11,454 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): dispatching CMD command 'RETR xyz_XML_Interface-Rawdata_20171129_064100_50277.tmp' to mod_xfer
2018-02-07 16:25:11,505 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): active data connection opened - local  : 10.15.87.17:20
2018-02-07 16:25:11,505 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): active data connection opened - remote : 10.1.70.112:58786
2018-02-07 17:38:29,580 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): Data transfer stall timeout: 3600 seconds
2018-02-07 16:25:11,566 Oracle2db proftpd[15663] 10.15.87.17 (10.1.70.112[10.1.70.112]): notice: user ftpusr: aborting transfer: Data connection closed

Wireshark screenshot:

Logged requests and responses


Configuration

proftpd.conf:

# This is a basic ProFTPD configuration file (rename it to
# 'proftpd.conf' for actual use.  It establishes a single server
# and a single anonymous login.  It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.

ServerName                      "3.0 Linux-FTP"
ServerType standalone
DefaultServer                   on
RequireValidShell off
ExtendedLog /var/log/ftp.log
UseReverseDNS off
IdentLookups off
TimeoutLogin 120
TimeoutIdle 3600
TimeoutNoTransfer 3600
TimeoutStalled 3600
MaxClientsPerHost 2 "Two clients by hostname max"
MaxClientsPerUser 5 "Only one connection per user allowed"
MaxClients 4 "Too many users, please try again later"
MaxHostsPerUser 5 "Only one host per user allowed"
MaxLoginAttempts 2 "You've reached the max. login attempts"
UseSendfile off

# Port 21 is the standard FTP port.
Port                            21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask                           022

# To prevent DoS attacks, set the maximum number of child processes
# to 30.  If you need to allow more than 30 concurrent connections
# at once, simply increase this value.  Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances                    30

# Set the user and group under which the server will run.
User                            ftpusr
Group                           ftpusers

# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
DefaultRoot /home/ftpusr/xml-export
# DefaultRoot ~

# Normally, we want files to be overwriteable.
AllowOverwrite          on

<Directory /home/ftpusr/xml-export>
Umask 022 022
</Directory>
  • Is the FTP directory local, or is it on a network filesystem? If it's local, is the drive OK? Do you see any messages in dmesg? Can you read the file from the console? I'm wondering if there might be some sort of lower-level issue that is contributing to the issue. – ErikF Feb 21 '18 at 9:59
  • The drive is local and we haven't seen any drive errors. I'll check dmesg and add a comment as soon as I got a result. Thanks anyway! – SaschaM78 Feb 21 '18 at 15:02
  • Is system time same between client and FTP server? – rajaganesh87 Feb 23 '18 at 2:22
  • Both are in the same time zone, but do not NTP sync against the same time source. – SaschaM78 Feb 23 '18 at 7:20
1

Looking at your wireshark, you seem to be using FTP active mode in the client. I would recommend FTP using passive mode.

Passive mode plays better with firewall rules.

see Active FTP vs. Passive FTP, a Definitive Explanation

see also How to check the Passive and Active FTP

In an active mode connection, when the client makes the initial connection and sends PORT, the server initiates the second connection back. In a passive connection, the client connects and sends the PASV command, which functions as a request for a port number to connect to.

  • Hi and thanks a lot for your answer. In our current setup, there is no firewall involved, not on the FTP host itself and not on the clients we used in our tests. We are not using proxies in between and there are no network components involved that may discard packets. The client that initially raised the problem is using PASV and experiences the same problems. – SaschaM78 Feb 7 '18 at 19:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.