Frustrating ftp upload problem!

[KenOp]

Hi,

I don't know if this is the right place to ask such a question, but I've had some wonderful help here in the past, and hours of googling over the past year hasn't brought me an answer.

I have a problem when uploading larger files via ftp, regardless of the ftp client that I use (I've tried crossftp, filezilla, fireftp, and others). The files are uploaded ok, but the final acknowledgement from the server never seems to get processed. Most ftp clients start resending the file, while at least one simply stays at 99% done status, with 1 byte remaining. The problem isn't on the server end, because it happens with every server I upload to.

Since the problem isn't the server or the client, I assume it must be either my modem or router (or firewall?). I'm running Win 8.1, with Windows Firewall. My router is Asus RT-N66U (firmware AsusWrt-Merlin 378.55_0) and my modem is SB6183.

Has anyone heard of such a problem, and/or have an idea how to go about solving it?

Thanks,

Ken

 

[KenOp]

I did a little experimenting, and found that a file of 784MB that took 20:39 failed, whereas a file of 768MB that took 19:56 was successful. So I'm wondering if there might be something on my system with a 20:00 time limit?

 

[sfx2000]

depending on the server/client config, might run into issues with PASV mode in FTP...

Good resource here - http://www.slacksite.com/other/ftp.html

 

[Nullity]

I vaguely remember something similar ("1 byte remaining") but it was the foreign FTP server's problem rather than my FTP client's.

Are you trying to resume?

Try both passive & active. Like sfx mentions, FTP is ancient and crappy and often fails because of NAT, so you may need to manually input your external IP into the settings.

Binary, not ASCII.

If you can, "dumb" down your client to use the most basic of options.


Are you uploading to numerous FTPs, or are you only having problems with 1? Either way, you might try Googling info about the particular FTP server software you are trying to upload to.

 

[KenOp]

I'm trying active ('PORT') now, as I had always used PASV mode before.

Also binary transfer, not ASCII. I have the client set up for resuming, but they always start re-sending from the beginning.

There are numerous FTP sites, likely all running different server software. The one I'm trying right now did not identify itself this time, but I know last time it did. I'm not sure why it didn't do so this time. But I'll try to make a note of the names, and see if I can dig up any info on them.

Thanks. I am still suspecting my side, though, in particular the router (though I couldn't find any mention of a timeout-related setting in the firmware).

 

[Nullity]

I think that simply enabling the resume capability can mess with certain, basic FTP servers. For example, instead of using the basic "prepare for the following file <file>", a resume-capable FTP client will say "prepare for the following file -beginning <here> -ending <here> <file>", which confuses the non-resume-supporting FTP server.

Maybe try some command-line FTP programs (lftp?), in the hope that they will show/teach you something that GUI clients do not.

 

[KenOp]

The active (PORT) transfer acted identically.

I'm strictly Windows; I'm now trying the command prompt's ftp program. But even using debug mode, there doesn't seem to be much of interest so far (just the same messages I was already seeing in the ftp clients I had been using).

I will update this thread if/when I ever resolve this problem, in case someone else happens to encounter it (as unlikely as that seems).

 

[john9527]

Two things to check.....
- Make sure the Windows Firewall allows your ftp program
- If you are running a 3rd party Antivirus, it could be attempting to scan the file at the end of the download and timing out the transfer. See what options are available.

 

[KenOp]

Thanks, John. I'm pretty sure the firewall allows the ftp clients I've tried, as they are all successful as long as each file takes less than 20 minutes (based on what I noticed this morning). I can upload dozens of smaller files without any problems whatsoever.

No 3rd party AV; just Windows Defender.

The result of the command line ftp attempt was, at the end of the transfer it returned with:
"Connection closed by remote host"

Hmmm. I'm not sure I believe that, but it would be interesting if true. As with the Windows ftp client, the file was successfully (completely) uploaded.

The message I get when using a Windows ftp client is:
"Read timed out"

Oh, well. That's the last of the files I have to upload today. I'll play around with this some more when I next need to upload. And as I said, I will definitely post the solution, if I find it. (I think the next thing I may try is to go back to Asus's stock firmware, but I'm hesitant to do this as I don't know what else might break. Same for upgrading to the current version of Merlin.)

Ken