Archived Forum PostQuestion:
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.