Nickers52 wrote:

Sorry, Martin, I don't quite follow. Perhaps I didn't make my statements clear. I can tell you what would happen if I tried the Windows command line ftp client. I would see the TCP handshakes and the FTP handshakes and then the mainframe would reject it because ftp.exe does not support the TLS that our mainframe now requires.

Well, I would actually not expect that. I would expect the command-line ftp.exe client not to connect at all (if executed in the same SSIS environment as WinSCP), the same way WinSCP does not. If you get a different experience (e.g. the one you described), then it would be a useful information.

Sorry, Martin, I don't quite follow. Perhaps I didn't make my statements clear. I can tell you what would happen if I tried the Windows command line ftp client. I would see the TCP handshakes and the FTP handshakes and then the mainframe would reject it because ftp.exe does not support the TLS that our mainframe now requires. Your WinSCP.com is a command line version that does support TLS and I do see the TCP handshakes and the FTP handshakes and the FTP communication. It works, as does your WinSCP Windows client. What isn't working is the C# code in my SSIS Script Task. After it says "Connecting" it gets "Failed to connect" but there is not even any handshaking. When I point the same SSIS Script Task to an FTP server I set up on a windows machine I also see the TCP handshakes and the FTP handshakes followed by an FTP rejection message because I didn't request the same type security in both host and client. I am sure if I bother it will work fine. The mystery still remains with my attempt to connect to the mainframe with that SSIS package method, but I found somebody here that has solved the problem and will compare notes with him next week. I doubt he used WinSCP as he likes to write everything himself from scratch, but I know your WinSCP.dll works with two out of three methods I have tried. The only difference I could see is that two are interactive and one is automated, but the automated approach works with every other way we've tried.
Whatever problem I am having might occur for other customers of yours so I will be sure to let you know if I solve it.

Try any other command-line FTP client. E.g. the built-in Windows ftp.exe. Just a simple connection test to verify that you get the same problem.

Update: With WireShark I monitored the ftp host and port 21. With WinSCP.exe I see traffic (a couple TCP and then the FTP protocol messages). I also see traffic with WinSCP.com but not with the SSIS task. I switched the ftp host name to the IP address of an FTP server I set up on another Windows 7 machine. I run that SSIS task and I see traffic as well although I don't connect because I don't have tls on that server. So something is blocking (like you said) the connection from my SSIS task to the mainframe, even though I can connect just fine with WinSCP the two other ways. When I was younger I used to have nightmares dreaming in code. This just might make the nightmares come back.

martin wrote:

Nickers52 wrote:

I can connect just fine with WinSCP.exe and WinSCP.com but I am trying to execute an SSIS script task and I have never gotten a connection. I can't see the server (FTP HOST) log but maybe someone will provide that for me later.
I will upload my session log and also have a debug log if it helps but it doesn't appear to reveal any hints.

The local account you are using to run the script probably does not have a network connectivity privilege. Or some local or network policy intervenes.

Thank you for the quick reply, Martin, it sounds like you don't suspect too many, too few or an incorrect parameter in the mix. So, hmmm. I seriously doubt it is a privilege type error although it can't be ruled out at this point. When I first started programming we transferred data on punched cards and paper or magnetic tape (or just retyped it all again on a keyboard such as a teletype). I have developed enough SSIS packages to know that testing them in development, it is using my credentials not a test account. Once they are imported to Integration Services and run in a job using SQL Server Agent they use a service account UNLESS you set up Credentials and a Proxy. But you are not wrong in that there are ways the system can determine that my credentials are being used manually vs. automation, but if this kind of black is happening I am going to need to see it because I don't think that is the case.

I forgot to mention that I was connecting to an IBM (or equivalent) mainframe. If that gives you an idea of something to check, please let me know. Nobody on the other end has gotten back to me yet. Sometimes they respond 4 or 5 times in a day, other times it takes 4 or 5 days to respond.
I am not ready to give up yet, I will try listening to network links with WireShark and see if that helps me determine anything.

Nickers52 wrote:

I can connect just fine with WinSCP.exe and WinSCP.com but I am trying to execute an SSIS script task and I have never gotten a connection. I can't see the server (FTP HOST) log but maybe someone will provide that for me later.
I will upload my session log and also have a debug log if it helps but it doesn't appear to reveal any hints.

The local account you are using to run the script probably does not have a network connectivity privilege. Or some local or network policy intervenes.

I can connect just fine with WinSCP.exe and WinSCP.com but I am trying to execute an SSIS script task and I have never gotten a connection. I can't see the server (FTP HOST) log but maybe someone will provide that for me later.
I will upload my session log and also have a debug log if it helps but it doesn't appear to reveal any hints.

What was the answer to this problem?

martin wrote:

So can you at least share a WinSCP session log?

To generate log file, enable logging, log in to your server and do the operation and only the operation that causes the error. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.

So can you at least share a WinSCP session log?

I get the same failure but I have no chance to get the server log.

The error code means "Disconnected from server", as you can see in the log. You should check the server's log to find out what's wrong.

I get the 1004 Error to Command 1.

Is there a list of error codes that I can get my hands on to do some more indepth troubleshooting?

I used the *** to redact information that my superiors wish to keep private.

. 2011-09-27 15:13:30.374 --------------------------------------------------------------------------
. 2011-09-27 15:13:30.374 WinSCP Version 4.3.5 (Build 1463) (OS 6.1.7601 Service Pack 1)
. 2011-09-27 15:13:30.374 Configuration: HKEY_CURRENT_USER\Software\Martin Prikryl\WinSCP 2\
. 2011-09-27 15:13:30.374 Local account: *****\********
. 2011-09-27 15:13:30.374 Login time: Tuesday, September 27, 2011 3:13:30 PM
. 2011-09-27 15:13:30.374 --------------------------------------------------------------------------
. 2011-09-27 15:13:30.374 Session name: **********(Ad-Hoc session)
. 2011-09-27 15:13:30.374 Host name: ***.**.*.*** (Port: 4023)
. 2011-09-27 15:13:30.374 User name: *****TestingLogonFTPS (Password: Yes, Key file: No)
. 2011-09-27 15:13:30.374 Tunnel: No
. 2011-09-27 15:13:30.374 Transfer Protocol: FTP
. 2011-09-27 15:13:30.374 Ping type: C, Ping interval: 30 sec; Timeout: 60 sec
. 2011-09-27 15:13:30.374 Proxy: none
. 2011-09-27 15:13:30.374 FTP: FTPS: Implicit SSL/TLS; Passive: Yes [Force IP: No]
. 2011-09-27 15:13:30.374 Local directory: default, Remote directory: /*****TestingLogonFTPS/*****TestingFolderFTPS, Update: No, Cache: Yes
. 2011-09-27 15:13:30.374 Cache directory changes: Yes, Permanent: Yes
. 2011-09-27 15:13:30.374 DST mode: 1
. 2011-09-27 15:13:30.374 --------------------------------------------------------------------------
. 2011-09-27 15:13:30.436 Connecting to 133.29.5.180:4023 ...
. 2011-09-27 15:13:30.436 m_pSslLayer changed state from 0 to 1
. 2011-09-27 15:13:30.436 m_pSslLayer changed state from 1 to 2
. 2011-09-27 15:13:30.436 m_pSslLayer changed state from 2 to 4
. 2011-09-27 15:13:30.452 Connected with 133.29.5.180:4023, negotiating SSL connection...
. 2011-09-27 15:14:00.606 m_pSslLayer changed state from 4 to 5
. 2011-09-27 15:14:00.606 Disconnected from server
. 2011-09-27 15:14:00.606 Connection failed.
. 2011-09-27 15:14:00.606 Got reply 1004 to the command 1
* 2011-09-27 15:14:00.621 (ESshFatal) Connection failed.
* 2011-09-27 15:14:00.621 Disconnected from server
* 2011-09-27 15:14:00.621 Connection failed.

Any help is appreciated.