Random timeouts after successful FTP file upload

0 votes
asked Jan 10, 2013 by MerliN (260 points)
edited Jun 7, 2013

We are using Rebex FTP component for FTP upload in our project. Unfortunately, few our users are reporting issues with uploading. The upload goes to 100% and then after set timeout, FtpException happens with Status = Timeout and message = Timeout exceeded. This happens NOT always (seems random) and the file usually gets uploaded actually (if you check FTP server directory). I thought there is some problem with either internet connection or the server, but FileZilla uploads same file to same server just fine without any delays or timeouts in the end.

Any ideas about how to troubleshoot this further?

Applies to: Rebex FTP/SSL
commented Jan 10, 2013 by Lukas Pokorny (85,170 points)
edited Jan 10, 2013

How long do the failed transfers take to complete, on average? This might be cause by a firewall silently dropping the control connection - see http://forum.rebex.net/questions/668/file-timeout-exceeded for a workaround - but it's not certain at this point. Anyway, please give this a try!

commented Jan 10, 2013 by Lukas Pokorny (85,170 points)
edited Jan 10, 2013

Also, unlike FileZilla, Rebex FTP doesn't try to resume a failed upload or connections automatically and this might explain the difference - if possible, please ask your users to check out their FileZilla logs for errors.

commented Jan 10, 2013 by MerliN (260 points)
edited Jan 10, 2013

It takes as long as the upload process (it goes to 100% uploaded first) + the timeout (it waits for the timeout after whole file is uploaded). I also made sure that user disabled all the firewalls on both the OS and the router. FileZilla does not stop nor report any error. It just uploads the file and reports success immediately.

commented Jan 11, 2013 by Lukas Pokorny (85,170 points)
edited Jan 11, 2013

Would it be possible to create 1) a log of the communication leading to the error using Ftp object's LogWriter property (as described at http://www.rebex.net/kb/logging.aspx) and 2) a FileZilla log showing a successful transfer session and mail both logs to support@rebex.net for analysis? It's possible we are doing something differently and the logs might make it possible to tell. Thanks!

commented Jan 13, 2013 by MerliN (260 points)
edited Jan 13, 2013

Thank you, I've just sent a letter containing both logs and few more details.

commented Jan 14, 2013 by Lukas Pokorny (85,170 points)
edited Jan 14, 2013

Thanks for the logs! I just replied to your e-mail.

1 Answer

+1 vote
answered May 10, 2013 by Jan Sotola (16,540 points)
edited Jun 7, 2013
Best answer

A summary of our e-mail discussion:

  • The timeout errors were occurring, when the transfer was taking more than 60 seconds.
    We think this is caused by a faulty router/firewall device along the way that drops TCP sessions that were inactive for more than 60 seconds. Usually that timeout is much longer than 60 seconds.
  • There is a workaround for this issue using the following code: ftp.Settings.KeepAliveDuringTransfer = true; ftp.KeepAliveDuringTransferInterval = 30; // 30 seconds Since you never know, how long is the required time interval, we recommend to start with the default of 10 minutes and if it doesn't help, check whether you can actually see the "NOOP" commands in the log while the transfer is in progress – if not, try lowering the KeepAliveDuringTransferInterval value.
  • If the FTP server does not support a KeepAlive option, you can just reconnect (in case of timeout) and check the uploaded file size. Or you can upload the file in chunks of smaller size.
commented May 10, 2013 by MerliN (260 points)
edited May 10, 2013

I am sorry for forgetting to mail you when I found the real cause of the problem. The real cause was the faulty IP camera the user had connected in the same local network (behind router). I don't know how can it be possible but when he disconnected the camera the problem has gone away. May be someone will find this information useful.

commented Jun 7, 2013 by Lukas Pokorny (85,170 points)
edited Jun 7, 2013

Thanks for letting us know! :-) This seems to have been yet another of those problems where the cause turns out to be something totally different than anyone would have guessed.