5

On my home Kubuntu 11.10 machine I have discovered that I cannot upload via FTP any single files that is larger than 5791 bytes. I have tried to two different FTP servers (not anonymous rather my employer's FTP servers) using Konqueror, GFTP, and Krusader. Also, to both of those servers other people can upload larger files just fine. I do not know if the issue is my Kubuntu desktop or possibly my router / ISP blocking. I tried changing the MTU as per this question however it did not resolve the issue. How might I troubleshoot that? I don't have any other computers here at home to FTP to / from.

I have no problem uploading larger files via SSH from this same machine, the problem only manifests with FTP. Note also that I can only connect with passive mode (-p on the CLI).

Here is example output:

ftp> put smallFile.txt 
local: smallFile.txt remote: smallFile.txt
227 Entering Passive Mode (50,63,78,1,198,219)
150 Accepted data connection
226-File successfully transferred
226 0.837 seconds (measured here), 48.98 bytes per second
41 bytes sent in 0.00 secs (494.3 kB/s)
ftp> put largeFile.txt 
local: largeFile.txt remote: largeFile.txt
227 Entering Passive Mode (50,63,78,1,198,224)
150 Accepted data connection
421 Service not available, remote server has closed connection
7785 bytes sent in 0.00 secs (62315.9 kB/s)
ftp>

At the line 150 Accepted data connection I will wait for quite some time before the 421 Service not available message appears.

Community
  • 1
dotancohen
  • 15,494
  • 26
  • 80
  • 116
  • 3
    It would help to explain what happens when you try. Does the connection time out, does it abort mid-way and claim successful, does the connection terminate, any error messages, etc... – phemmer Aug 26 '12 at 23:44
  • I just tried to upload a 5792 byte file to the server with Netbeans, it complains that the connection is reset. I reduce the file to 5790 bytes and it transfers fine. Completely reproducible. – dotancohen Aug 27 '12 at 00:35
  • Thank you, I added the output of the `ftp` command on the CLI. – dotancohen Aug 27 '12 at 00:51
  • 1
    If it hangs for some time, have you tried running it under `strace` to see what system call is hanging? That may lead to something useful. – Aaron D. Marasco Aug 27 '12 at 01:17
  • 2
    Try turning off passive mode. – bahamat Aug 27 '12 at 03:13
  • 1
    Also `tcpdump` or `wireshark`/`tshark` – Alan Curry Aug 27 '12 at 07:54
  • 1
    You can also set up a test where the remote FTP server listens on some high non-standard port. Maybe it really is your ISP. – Bananguin Aug 29 '12 at 14:37

1 Answers1

2

I've seen this before with vsftpd as the server (but here it's pureftpd), when the server was accepting the DATA connection but could not write a lock for the uploaded file. The client could only send as much as its send buffer + receive window of the server. I don't recall the details, but that would add up to more than 5791 bytes though.

5791 looks more like 4 full size packets, which is the initial TCP congestion window. It's as if the TCP ACK packets (except for the SYN+ACK) were lost in transit. I would guess a transparent proxy issue and/or a firewall issue. We don't see the first part of the FTP handshake. Are you using TLS by any chance (as I can see it's supported by the server).

I would run a "tshark -i any host 50.63.78.1" so see what's going on.

Stéphane Chazelas
  • 522,931
  • 91
  • 1,010
  • 1,501