I am running vsftpd 2.2.1 on an Ubuntu 8.04 machine with a pretty straight-forward configuration and am experiencing a strange issue regarding uploads to the machine via FTP. If I upload text files the transfer speed is about 70 KB/s, if I upload binary data (zip file, etc.) the transfer speed is about 50 times as fast. I have used several different clients on different operating systems, different file sizes, etc. I have tried in both binary and ASCII modes for the text file transfer and nothing seems to make a difference. Has anybody seen this before or have any idea what might be causing this behavior?

Update: The FTP server is on a different subnet as the client machines that I previously tested with and have a Linux gateway in between, it appears that the issue is only occurring when machines on a different subnet connect through the gateway to the FTP server. When machines on the same subnet as the FTP server upload text files the issues doesn't seem to occur. This still doesn't make much sense but maybe there is an issue with the ip_conntrack_ftp module used on the gateway.

Update: It turns out that someone had set up Snort IDS on one side of the gateway which was breaking up FTP packets on approximately newline barriers which caused the lag for text files.

  • Thanks for providing the answer here. I ran into something similar a long time ago and solved it in the end, but even reading your question I had forgotten what the deal was.
    – Caleb
    Commented Oct 5, 2010 at 7:11
  • Please mark this as accepted.
    – Konrads
    Commented Nov 2, 2010 at 8:30

1 Answer 1


Maybe the line-ending conversions in vsftpd were written inefficiently, and since binary mode is most commonly used, no one has bothered to improve the algorithm used in vsftpd.

Or, it could just be that passing data from a tcp socket out to disk really is a lot faster than having to check every character for CR and LF. The check could introduce enough latency in the connection to reduce your transfer speed.

Are you running tests locally on Ethernet (low latency, would be affected greatly by additional latency) or across the Internet?

  • I tried both ASCII and binary mode and for text files it makes no difference. In binary mode, text files are still much slower so I don't think that the CR/CRLF conversions should even come into the picture. I am testing locally on a 100 Mbit local network. Commented Jul 16, 2010 at 17:28
  • Is it tied to file extension? Could a virus scanner or firewall on the server or client be adding overhead to certain extensions?
    – tomlogic
    Commented Jul 16, 2010 at 20:34
  • It doesn't appear to be, I tried with and without extensions, there is not virus scanner or anything else involved, I have reproduced this between a linux client machine, linux server, and linux firewall, all without AV or anything else that should be affecting anything. The gateway is just forwarding traffic between the subnets. Commented Jul 16, 2010 at 22:02
  • Time to install Wireshark (or use tcpdump) and do some packet captures. Compare the two transfers (binary file, text file) looking for differences.
    – tomlogic
    Commented Jul 16, 2010 at 22:33
  • Yeah, that is among the things on my list now. Commented Jul 17, 2010 at 5:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .