There's nothing I can really help you with, atm. There's something with your/their network that breaks the connection.
Anyway, I have improved logging of WinSCP. What might help to understand the problem better.

Can you send me an email, so I can send you back a dev version of WinSCP to track the problem? Please include link back to this topic in your email. Also note in this topic that you have sent the email. Thanks.

Anonymous wrote:

Anonymous wrote:

martin wrote:

• The general timeout issue you raised. I am going to attach our FTP connectivity troubleshooting guide. There is something in your logfile that definitely indicates a firewall issue:
2015-01-27 18:23:42.650 TLS connection established
2015-01-27 18:31:44.330 Timeout detected.
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed. The attached will give you some useful things to try.

We recommend that you try the following things in order and see if any of them resolve your issue.
1. Change active vs. passive mode. FTP clients and libraries have two modes of operation: Active mode and Passive mode. If the default doesn't work for you, try the other mode. As you try the other suggestions below, make sure to try each suggestion under both Active and Passive mode. Different firewalls work with different modes.
2. Try SSL. If you aren't using SSL, try switching to FTP-over-SSL on port 990 (implicit) or port 21 (explicit). In many cases, using SSL will get around any firewall blocking.
3. Try alternate ports. BrickFTP offers port 3021 as an alternate port for FTP. Often times, simply using port 3021 will allow your connection to work through your firewall.

Their analysis of the timeout issue is wrong.

Particularly this does not make any sense:

This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed.

The connection is obviously already opened. The TLS handshake occurs on the connection.
The timeout happended only 7 minutes (!) later, when the transfer completed and WinSCP timeouted waiting for the FTP server to acknowledge the transfer. So it's unlikely that any of his suggestion will make a difference (and you are using SSL/TLS already). It still can be a firewall (or router or proxy) issue though. If the firewall is stupid enough to close the FTP control connection due to an inactivity, during a long file transfer.

Thanks Martin. I have communicated this info to the ftp people.

I am attaching a log for today, as it failed todya with a similar but little different error. But, interestingly, in all of the timeouts, the file is eventually being ftped to the site -- Just my program is sending me error however (rightfully so). So the file is there in the ftp site. Is it because the Winscp is trying multiple times after the intial timeouts?

Thanks a lot for your help!

Paul

This is the response from the FTP server people for the log that I've attached:

***
Looking at this most recent log, the timeouts seem to happen at different phases of the process. i.e. it looks like it timed out during a transfer, then when it tried reconnecting, it could not even authenticate. Next time as soon as this occurs, can you try connecting to
<invalid hyperlink removed by admin> and also https://www.speedtest.net/

And see if it looks like you have lost internet connectivity at that particular point in time? Can you try to replicate the problem from a different physical network connection? Also I encourage you to try as many of the different Ports and Protocols as you can, from the troubleshooting document. For example I see you have PASV turned on, can you try it with that disabled? Can you try SFTP?

***

I have attached todays failure. As you can see there is that 10 min time gap where it detects a timeout. Interestingly, when I re-run the process, it executes fine. Thanks for your help.

Anonymous wrote:

martin wrote:

• The general timeout issue you raised. I am going to attach our FTP connectivity troubleshooting guide. There is something in your logfile that definitely indicates a firewall issue:
2015-01-27 18:23:42.650 TLS connection established
2015-01-27 18:31:44.330 Timeout detected.
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed. The attached will give you some useful things to try.

We recommend that you try the following things in order and see if any of them resolve your issue.
1. Change active vs. passive mode. FTP clients and libraries have two modes of operation: Active mode and Passive mode. If the default doesn't work for you, try the other mode. As you try the other suggestions below, make sure to try each suggestion under both Active and Passive mode. Different firewalls work with different modes.
2. Try SSL. If you aren't using SSL, try switching to FTP-over-SSL on port 990 (implicit) or port 21 (explicit). In many cases, using SSL will get around any firewall blocking.
3. Try alternate ports. BrickFTP offers port 3021 as an alternate port for FTP. Often times, simply using port 3021 will allow your connection to work through your firewall.

Their analysis of the timeout issue is wrong.

Particularly this does not make any sense:

This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed.

The connection is obviously already opened. The TLS handshake occurs on the connection.
The timeout happended only 7 minutes (!) later, when the transfer completed and WinSCP timeouted waiting for the FTP server to acknowledge the transfer. So it's unlikely that any of his suggestion will make a difference (and you are using SSL/TLS already). It still can be a firewall (or router or proxy) issue though. If the firewall is stupid enough to close the FTP control connection due to an inactivity, during a long file transfer.

Thanks Martin. I have communicated this info to the ftp people.

I am attaching a log for today, as it failed todya with a similar but little different error. But, interestingly, in all of the timeouts, the file is eventually being ftped to the site -- Just my program is sending me error however (rightfully so). So the file is there in the ftp site. Is it because the Winscp is trying multiple times after the intial timeouts?

Thanks a lot for your help!

Paul

This is the response from the FTP server people for the log that I've attached:

***
Looking at this most recent log, the timeouts seem to happen at different phases of the process. i.e. it looks like it timed out during a transfer, then when it tried reconnecting, it could not even authenticate. Next time as soon as this occurs, can you try connecting to
<invalid hyperlink removed by admin> and also https://www.speedtest.net/

And see if it looks like you have lost internet connectivity at that particular point in time? Can you try to replicate the problem from a different physical network connection? Also I encourage you to try as many of the different Ports and Protocols as you can, from the troubleshooting document. For example I see you have PASV turned on, can you try it with that disabled? Can you try SFTP?

***

martin wrote:

• The general timeout issue you raised. I am going to attach our FTP connectivity troubleshooting guide. There is something in your logfile that definitely indicates a firewall issue:
2015-01-27 18:23:42.650 TLS connection established
2015-01-27 18:31:44.330 Timeout detected.
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed. The attached will give you some useful things to try.

We recommend that you try the following things in order and see if any of them resolve your issue.
1. Change active vs. passive mode. FTP clients and libraries have two modes of operation: Active mode and Passive mode. If the default doesn't work for you, try the other mode. As you try the other suggestions below, make sure to try each suggestion under both Active and Passive mode. Different firewalls work with different modes.
2. Try SSL. If you aren't using SSL, try switching to FTP-over-SSL on port 990 (implicit) or port 21 (explicit). In many cases, using SSL will get around any firewall blocking.
3. Try alternate ports. BrickFTP offers port 3021 as an alternate port for FTP. Often times, simply using port 3021 will allow your connection to work through your firewall.

Their analysis of the timeout issue is wrong.

Particularly this does not make any sense:

This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed.

The connection is obviously already opened. The TLS handshake occurs on the connection.
The timeout happended only 7 minutes (!) later, when the transfer completed and WinSCP timeouted waiting for the FTP server to acknowledge the transfer. So it's unlikely that any of his suggestion will make a difference (and you are using SSL/TLS already). It still can be a firewall (or router or proxy) issue though. If the firewall is stupid enough to close the FTP control connection due to an inactivity, during a long file transfer.

Thanks Martin. I have communicated this info to the ftp people.

I am attaching a log for today, as it failed todya with a similar but little different error. But, interestingly, in all of the timeouts, the file is eventually being ftped to the site -- Just my program is sending me error however (rightfully so). So the file is there in the ftp site. Is it because the Winscp is trying multiple times after the intial timeouts?

Thanks a lot for your help!

Paul

• The general timeout issue you raised. I am going to attach our FTP connectivity troubleshooting guide. There is something in your logfile that definitely indicates a firewall issue:
2015-01-27 18:23:42.650 TLS connection established
2015-01-27 18:31:44.330 Timeout detected.
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed. The attached will give you some useful things to try.

We recommend that you try the following things in order and see if any of them resolve your issue.
1. Change active vs. passive mode. FTP clients and libraries have two modes of operation: Active mode and Passive mode. If the default doesn't work for you, try the other mode. As you try the other suggestions below, make sure to try each suggestion under both Active and Passive mode. Different firewalls work with different modes.
2. Try SSL. If you aren't using SSL, try switching to FTP-over-SSL on port 990 (implicit) or port 21 (explicit). In many cases, using SSL will get around any firewall blocking.
3. Try alternate ports. BrickFTP offers port 3021 as an alternate port for FTP. Often times, simply using port 3021 will allow your connection to work through your firewall.

Their analysis of the timeout issue is wrong.

Particularly this does not make any sense:

This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed.

The connection is obviously already opened. The TLS handshake occurs on the connection.
The timeout happended only 7 minutes (!) later, when the transfer completed and WinSCP timeouted waiting for the FTP server to acknowledge the transfer. So it's unlikely that any of his suggestion will make a difference (and you are using SSL/TLS already). It still can be a firewall (or router or proxy) issue though. If the firewall is stupid enough to close the FTP control connection due to an inactivity, during a long file transfer.

Anonymous wrote:

martin wrote:

It's a request to modify file timestamp. WinSCP does that to update the remote file to match that of source local file. Otherwise the file will have timestamp of the upload.

If you do not need that, you can turn this off using put -nopreservetime ...
See https://winscp.net/eng/docs/scriptcommand_put

I have let the FTP site know of this.

But, thanks for the suggestion to turn it off. I will consider to put it in the script. So in doing this, the 450 error (or the timeout detected) will not be there anymore? And btw, I did change the timeout to 45 secs.

Thanks for your help Martin.

Paul

Martin,

I have communicated and got response from our FTP provider. Here is what they are saying:

****
We have looked at your logfiles, and there appear to be 2 separate issues you brought up
• The MFMT requests failing. Our server does not honor file date/time modification requests. The reason is because of how our virtual filesystem is implemented. We update date/time stamps when a file is uploaded. So when you see this
> 2015-01-27 18:32:16.267 MFMT 20150127182335 ****.bak
< 2015-01-27 18:32:16.455 450 Could not perform action on file ****.bak.
That means that our server understood the MFMT request, but it is just not honoring it. That shouldn't pose a problem, and is unrelated to the timeouts.
• The general timeout issue you raised. I am going to attach our FTP connectivity troubleshooting guide. There is something in your logfile that definitely indicates a firewall issue:
2015-01-27 18:23:42.650 TLS connection established
2015-01-27 18:31:44.330 Timeout detected.
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed. The attached will give you some useful things to try.

We recommend that you try the following things in order and see if any of them resolve your issue.
1. Change active vs. passive mode. FTP clients and libraries have two modes of operation: Active mode and Passive mode. If the default doesn't work for you, try the other mode. As you try the other suggestions below, make sure to try each suggestion under both Active and Passive mode. Different firewalls work with different modes.
2. Try SSL. If you aren't using SSL, try switching to FTP-over-SSL on port 990 (implicit) or port 21 (explicit). In many cases, using SSL will get around any firewall blocking.
3. Try alternate ports. BrickFTP offers port 3021 as an alternate port for FTP. Often times, simply using port 3021 will allow your connection to work through your firewall.

***


Please let me know your thoughts.

Paul

It helps with the 450 error only, not with the timeout. Btw, I was not able to reproduce the timeout issue, from my side.

martin wrote:

It's a request to modify file timestamp. WinSCP does that to update the remote file to match that of source local file. Otherwise the file will have timestamp of the upload.

If you do not need that, you can turn this off using put -nopreservetime ...
See https://winscp.net/eng/docs/scriptcommand_put

I have let the FTP site know of this.

But, thanks for the suggestion to turn it off. I will consider to put it in the script. So in doing this, the 450 error (or the timeout detected) will not be there anymore? And btw, I did change the timeout to 45 secs.

Thanks for your help Martin.

Paul

It's a request to modify file timestamp. WinSCP does that to update the remote file to match that of source local file. Otherwise the file will have timestamp of the upload.

If you do not need that, you can turn this off using put -nopreservetime ...
See https://winscp.net/eng/docs/scriptcommand_put

martin wrote:

Actually, I take it back.
I did test against brickftp.com myself.
They just fail every MFMT request. It's on their side. Please report it.

Btw, now I assume that you see the error in the log only, correct?
I'm not getting any error in GUI.

Thanks Martin.

I only see the error in the log only. Just so that I understand when I report it, what is an MFMT request?

Actually, I take it back.
I did test against brickftp.com myself.
They just fail every MFMT request. It's on their side. Please report it.

Btw, now I assume that you see the error in the log only, correct?
I'm not getting any error in GUI.

What happens is that WinSCP has not received confirmation from the server, when upload finished. This is actually quite common problem. So WinSCP reconnected to the server, verified that the file upload was indeed complete and tried to update a timestamp of the uploaded file. That failed, with 450 error. Likely because the FTP server has the file still locked from the previous attempt. Do you get the timeout with every upload? If you are, can you please try the upload with any other FTP client (FileZilla) to check if it is a client- or server-side problem.

paultp12 wrote:

martin wrote:

I do not see any "Could not perform action on file" errors in the log.

Hi Martin,

Sorry. But here is the file. This is for the failure today.

When I re-run, it works ok.

Thanks for your help.

Paul

One additional thing: There is also a "Timeout detected, connection failed" in the log. Thanks.

martin wrote:

I do not see any "Could not perform action on file" errors in the log.

Hi Martin,

Sorry. But here is the file. This is for the failure today.

When I re-run, it works ok.

Thanks for your help.

Paul

I do not see any "Could not perform action on file" errors in the log.

Hello:

For the past few days this error kept on occuring: "450 Could not perform action on file ..."

Nothing was changed in any of the processes. I had to re-run the task several times, and then it went ok.

Can anyone please shed some light. Thanks!

Paul