Question:
Trying to figure out what the problem is with transferring a file with the ftp2 .NET Not problems with other ftp sites and works when using CuteFTP client to send a file to the problem ftp site.
I could use some help figuring out what the problem is and getting this work.
ChilkatLog: PutFile: DllDate: May 8 2014 ChilkatVersion: 9.5.0.39 UnlockPrefix: MATTHEFTP Username: KGBD010:mwilkinson Architecture: Little Endian; 32-bit Language: .NET 4.0 VerboseLogging: 0 LocalFilename: C:\Users\mwilkinson.GARFFAD\Documents\Visual Studio 2013\Projects\SendDataToVendor\SendDataToVendor\bin\Release\utahcountysupersonic_20140508.csv RemoteFilename: utahcountysupersonic_20140508.csv ProgressMonitoring: enabled: yes heartbeatMs: 0 sendBufferSize: 65536 --ProgressMonitoring IdleTimeoutMs: 60000 ReceiveTimeoutMs: 60000 ConnectTimeoutSeconds: 240 uploadFromLocalFile: localFileSize: 52623 uploadFromDataSource: initialGreeting: 220-Welcome to Alexanders FTP! 220 CrushFTP Server Ready! restartNext: 0 modeZ: 0 binaryMode: 0 setupDataConnection: passive transfer mode setupPassiveDataSocket: sendCommand: sendingCommand: EPSV --sendCommand readCommandResponse: replyLineQP: 229 Entering Extended Passive Mode (|||2606|) commandResponse: 229 Entering Extended Passive Mode (|||2606|) statusCode: 229 --readCommandResponse dataConnect: hostname: 76.8.215.233 port: 2606 connect2: ConnectFailReason: Connection rejected --connect2 dataConnectSuccess: 0 --dataConnect setupPassiveDataSocket dataConnect failed.. --setupPassiveDataSocket Failed to setup passive data socket for upload --setupDataConnection --uploadFromDataSource --uploadFromLocalFile TotalTime: Elapsed time: 21029 millisec Failed. --PutFile --ChilkatLog
Try setting the PassiveUseHostAddr property = true.
Also, see this: http://www.cknotes.com/determining-ftp2-connection-settings/
Was there a resolution to this? My client has an application that is returning the exact same log entries. We have a Sonicwall firewall and have done everything we can to the firewall to minimize the risk of invasive packet interruption, but disabling deep packet inspection, etc, and cannot find a solution.