Connection failing with "Got reply 1004 to the command 1" but only at night
WinSCP Version 5.7.6 (Build 5874)
Windows Server 2008 R2 Standard - Service Pack 1
Transfer Protocol: FTP
Using Task Scheduler to trigger a cmd script that runs a .txt with a "put" (I'm also getting the same problem with a "get" so I don't think the "put" or "get" is a determining factor in success/failure).
Error:
. 2015-12-04 22:47:09.233 Connecting to [ftp server]:990 ...
. 2015-12-04 22:48:56.811 TLS layer changed state from unconnected to connecting
. 2015-12-04 22:48:56.811 TLS layer changed state from connecting to connected
. 2015-12-04 22:48:57.310 Connected with [ftp server]:990, negotiating TLS connection...
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 read server hello A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 read server certificate A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 read server done A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 write client key exchange A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 write change cipher spec A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 write finished A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 flush data
. 2015-12-04 22:49:42.301 Timeout detected. (control connection)
. 2015-12-04 22:49:44.813 Connection failed.
. 2015-12-04 22:49:45.811 Got reply 1004 to the command 1
I researched on the WinSCP Self help support site and it suggests that when there is a "Timeout detected" with an FTP protocol type connection "a reason is likely a firewall or NAT blocking a data connection." https://winscp.net/eng/docs/message_timeout_detected
However, in this case, if I schedule the same Task Scheduler job at a different time (in this case, in the morning after the failure), it works correctly.
Feedback from the Infrastructure Manager on the FTP server side: For the specified timeframe, I see two connection attempts which failed because the connection was created and no credentials were sent by the remote party and hence the idle login time was exceeded and our server closed the connection.
I'm afraid that because I cannot replicate the problem at will I'm wasting your time, but, since I'm out of ideas, I thought I'd share the situation in case there is any chance there is something I am overlooking. For instance, the put (and get) routines that are failing are run at night, and when I log in to check on and then manually reschedule them to run in the morning, perhaps there is some sort of FTP password that is being cached and allowing the rescheduled script to run successfully.
Windows Server 2008 R2 Standard - Service Pack 1
Transfer Protocol: FTP
Using Task Scheduler to trigger a cmd script that runs a .txt with a "put" (I'm also getting the same problem with a "get" so I don't think the "put" or "get" is a determining factor in success/failure).
Error:
. 2015-12-04 22:47:09.233 Connecting to [ftp server]:990 ...
. 2015-12-04 22:48:56.811 TLS layer changed state from unconnected to connecting
. 2015-12-04 22:48:56.811 TLS layer changed state from connecting to connected
. 2015-12-04 22:48:57.310 Connected with [ftp server]:990, negotiating TLS connection...
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 read server hello A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 read server certificate A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 read server done A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 write client key exchange A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 write change cipher spec A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 write finished A
. 2015-12-04 22:49:41.303 TLS connect: SSLv3 flush data
. 2015-12-04 22:49:42.301 Timeout detected. (control connection)
. 2015-12-04 22:49:44.813 Connection failed.
. 2015-12-04 22:49:45.811 Got reply 1004 to the command 1
I researched on the WinSCP Self help support site and it suggests that when there is a "Timeout detected" with an FTP protocol type connection "a reason is likely a firewall or NAT blocking a data connection." https://winscp.net/eng/docs/message_timeout_detected
However, in this case, if I schedule the same Task Scheduler job at a different time (in this case, in the morning after the failure), it works correctly.
Feedback from the Infrastructure Manager on the FTP server side: For the specified timeframe, I see two connection attempts which failed because the connection was created and no credentials were sent by the remote party and hence the idle login time was exceeded and our server closed the connection.
I'm afraid that because I cannot replicate the problem at will I'm wasting your time, but, since I'm out of ideas, I thought I'd share the situation in case there is any chance there is something I am overlooking. For instance, the put (and get) routines that are failing are run at night, and when I log in to check on and then manually reschedule them to run in the morning, perhaps there is some sort of FTP password that is being cached and allowing the rescheduled script to run successfully.
