Re: Secondary FTP Server Help
WS-FTP Pro configured for implicit SSL running under Windows XP works for us to connect to z/VM 4.4. Mark At 01:36 AM 8/9/2006, Adam Thornton wrote: On Aug 8, 2006, at 9:32 PM, Alan Ackerman wrote: We got Bluezone (trial copy) to work doing SSL FTP. We did NOT get our WS -FTP PRO client to work. We DID open a PMR, but were told the problem is in WS-FTP PRO. That's whe re it sits. FWIW I have reports of success using WS-FTP Pro. Make sure Implicit mode is enabled. My customer also defined a proxy but that may be a vagary of his network. I have not yet been successful with Glub Tech Secure FTP for Mac OS X, but I have a report that the Windows version works OK. Adam -- Mark Bodenstein ([EMAIL PROTECTED]; 607-255-8059) Mainframe Systems Programming, Systems and Operations Cornell Information Technologies Cornell University Ithaca, N.Y. 14853
Re: Secondary FTP Server Help
On Aug 8, 2006, at 9:32 PM, Alan Ackerman wrote: We got Bluezone (trial copy) to work doing SSL FTP. We did NOT get our WS -FTP PRO client to work. We DID open a PMR, but were told the problem is in WS-FTP PRO. That's whe re it sits. FWIW I have reports of success using WS-FTP Pro. Make sure Implicit mode is enabled. My customer also defined a proxy but that may be a vagary of his network. I have not yet been successful with Glub Tech Secure FTP for Mac OS X, but I have a report that the Windows version works OK. Adam
Re: Secondary FTP Server Help
We got Bluezone (trial copy) to work doing SSL FTP. We did NOT get our WS -FTP PRO client to work. We DID open a PMR, but were told the problem is in WS-FTP PRO. That's whe re it sits. Of course, it may have been a totally different problem. On Fri, 4 Aug 2006 10:35:47 -0700, Adam Thornton <[EMAIL PROTECTED] t> wrote: >This is the bit that I'm suspecting. So, let's try a different >tactic: what FTP clients are known to do implicit SSL the *right* way >for the VM stack? If I can get one of *those* working, then it's >clear that the problem is in my client, not in the SSL implementation >or VM's handling of it. > >Adam > =
Re: Secondary FTP Server Help
On Friday, 08/04/2006 at 10:35 MST, Adam Thornton <[EMAIL PROTECTED]> wrote: > On Aug 4, 2006, at 9:47 AM, Alan Altmark wrote: > > If no one opens a PMR, it doesn't get fixed. (Stop me if I start > > repeating myself.) If no one calls it in, and the problem has been in > > existence for multiple releases, then the pressure to fix it in the > > "next" > > release is non-existent. It is frowned upon for us to open an APAR > > without a customer PMR. > > Fair enough. I am, of course, reluctant to open a PMR until I am > pretty sure that it's the fault of the VM side o' things. And from > what I can see...it may be the fault of the client not attempting SSL > on the data. A PMR has been opened. The game's afoot, Watson! Alan Altmark z/VM Development IBM Endicott
Re: Secondary FTP Server Help
On: Fri, Aug 04, 2006 at 10:35:47AM -0700,Adam Thornton Wrote: } This is the bit that I'm suspecting. So, let's try a different } tactic: what FTP clients are known to do implicit SSL the *right* way } for the VM stack? If I can get one of *those* working, then it's } clear that the problem is in my client, not in the SSL implementation } or VM's handling of it. Unless there is some quirk needed to get SSL on VM working properly and this app's author was aware of it and coded around it. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself & my dogs only.VM'er since CP-67 Canines:Val, Red & Shasta (RIP),Red, Zero & Casey, Siberians Owner:Chinook-L Retired at the beach Asst Owner:Sibernet-L
Re: Secondary FTP Server Help
Sign on my wall - If you don't call it in, it isn't broken. Our users get to read it often. [EMAIL PROTECTED] wrote: If no one opens a PMR, it doesn't get fixed. (Stop me if I start repeating myself.) If no one calls it in, and the problem has been in existence for multiple releases, then the pressure to fix it in the "next" release is non-existent. It is frowned upon for us to open an APAR without a customer PMR. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Secondary FTP Server Help
On Aug 4, 2006, at 9:47 AM, Alan Altmark wrote: If no one opens a PMR, it doesn't get fixed. (Stop me if I start repeating myself.) If no one calls it in, and the problem has been in existence for multiple releases, then the pressure to fix it in the "next" release is non-existent. It is frowned upon for us to open an APAR without a customer PMR. Fair enough. I am, of course, reluctant to open a PMR until I am pretty sure that it's the fault of the VM side o' things. And from what I can see...it may be the fault of the client not attempting SSL on the data. Right, and to initiate an SSL handshake on the data connection. Yeah, that's what: Thread Client_Socket_AddressServer_Socket_AddressConnection Cipher 1 192.168.253.18:50429 192.168.131.1:1075 1012 NONE Makes me suspicious of. Your trace indicates that your client is tried to use in-band FTP security techniques. Have you confirmed that it is performing an SSL handshake on the data connection? This is the bit that I'm suspecting. So, let's try a different tactic: what FTP clients are known to do implicit SSL the *right* way for the VM stack? If I can get one of *those* working, then it's clear that the problem is in my client, not in the SSL implementation or VM's handling of it. Adam
Re: Secondary FTP Server Help
On Thursday, 08/03/2006 at 12:47 MST, Adam Thornton <[EMAIL PROTECTED]> wrote: > My totally-without-a-good-reason-for-suspecting-this is that incoming > connections to the FTP server *look* like they're coming from the IP > address of the stack itself. This is also the case with tn3270 and > anything wrapped by SSLSERV, and we've been over this ground maybe a > year ago. I am unaware that there was ever an APAR or PTF that fixed > this. If no one opens a PMR, it doesn't get fixed. (Stop me if I start repeating myself.) If no one calls it in, and the problem has been in existence for multiple releases, then the pressure to fix it in the "next" release is non-existent. It is frowned upon for us to open an APAR without a customer PMR. > Correct me if I'm wrong--I'm not all that intimately familiar with > the FTP protocol--but what I get when I say PASV is that the server > tells me, on the control channel, "Dude, your data channel will be > [[this IP and this port]]"--then it's the responsibility of my client > to connect to that port, right? Right, and to initiate an SSL handshake on the data connection. > Clearly I can see what's going on on > the control channel, or login/CWD wouldn't succeed. Is it possible > that the message is not getting back through SSLSERV to the stack > that the FTP server wants to open port XYZ and have it wrapped by > SSLSERV? Your trace indicates that your client is tried to use in-band FTP security techniques. Have you confirmed that it is performing an SSL handshake on the data connection? If the VM stack shows that the CLIENT_HELLO arrived, and we didn't respond correctly, that would be a bug. Alan Altmark z/VM Development IBM Endicott
Re: Secondary FTP Server Help
On Aug 3, 2006, at 12:31 PM, Alan Altmark wrote: I believe you. No errors on the TCPIP console at initialization? None on the SSL server console? What do the SSL traces show you? You're showing classic symptoms of something blocking the client's data connection. Naturally, without a trace it is rather difficult ot confirm. The SSL trace is buffered, and therefore not immediately helpful. However, if I abort the connection and then start another one, I can see all of the prior transaction, and here it is. My comments are in [[ double square brackets ]] DTCSSL019I Connection received from Thread Client_Socket_Address Connection Label 0 192.168.253.18:50425 1003 TESTING DTCSSL020I Connection accepted by Thread Server_Socket_Address 0 192.168.131.1:990 DTCSSL021I Handshake successful Thread Client_Socket_AddressServer_Socket_AddressConnection Cipher 0 192.168.253.18:50425 192.168.131.1:9901003 RC4_128_SHA DTCSSL024I Data sent Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 150 Data: 220-FTPSERV2 IBM VM DTCSSL025I Data received Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 11 Data: USER adam DTCSSL024I Data sent Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 27 Data: 331 Send password pl DTCSSL025I Data received Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 11 Data: PASS [[Not so fast, Chuckie!]] DTCSSL024I Data sent Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 50 Data: 230 ADAM logged in; DTCSSL025I Data received Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 17 Data: CLNT Secure FTP ~)0 DTCSSL024I Data sent Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 29 Data: 500 Unknown command, DTCSSL025I Data received Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 14 Data: OPTS UTF8 ON A~)0 DTCSSL024I Data sent Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 29 Data: 500 Unknown command, DTCSSL025I Data received Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 8 Data: REST 0 A~% DTCSSL024I Data sent Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 56 Data: 500 REST is only all DTCSSL025I Data received Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 5 Data: PWD DTCSSL024I Data sent Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 37 Data: 257 "ADAM.191" is wo DTCSSL025I Data received Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 16 Data: CWD /ADAM.191/ A~)0 DTCSSL024I Data sent Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 35 Data: 250 Working director DTCSSL025I Data received Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 5 Data: PWD DTCSSL024I Data sent Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 37 Data: 257 "ADAM.191" is wo DTCSSL025I Data received Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 8 Data: PBSZ 0 A~% DTCSSL024I Data sent Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 29 Data: 500 Unknown command, DTCSSL025I Data received Thread Client_Socket_AddressServer_Socket_AddressConnection Bytes 0 192.168.253.18:50425 192.168.131.1:9901003 6 Da
Re: Secondary FTP Server Help
On Aug 3, 2006, at 12:31 PM, Alan Altmark wrote: I believe you. No errors on the TCPIP console at initialization? Only the usual ones about gateways that don't exist because the CTCs/ IUCVs on them aren't hooked up (TCPIP2 is our experimental stack that I can play with without worrying about our REAL network access). None on the SSL server console? What do the SSL traces show you? I'll get some of these and send 'em to you. You're showing classic symptoms of something blocking the client's data connection. Naturally, without a trace it is rather difficult ot confirm. My totally-without-a-good-reason-for-suspecting-this is that incoming connections to the FTP server *look* like they're coming from the IP address of the stack itself. This is also the case with tn3270 and anything wrapped by SSLSERV, and we've been over this ground maybe a year ago. I am unaware that there was ever an APAR or PTF that fixed this. Correct me if I'm wrong--I'm not all that intimately familiar with the FTP protocol--but what I get when I say PASV is that the server tells me, on the control channel, "Dude, your data channel will be [[this IP and this port]]"--then it's the responsibility of my client to connect to that port, right? Clearly I can see what's going on on the control channel, or login/CWD wouldn't succeed. Is it possible that the message is not getting back through SSLSERV to the stack that the FTP server wants to open port XYZ and have it wrapped by SSLSERV? Adam
Re: Secondary FTP Server Help
On Thursday, 08/03/2006 at 11:28 MST, Adam Thornton <[EMAIL PROTECTED]> wrote: > What firewall? Shall I send you a network diagram (off-list) ? > There ain't no such animal. There are a number of routers, granted, > but no firewalls. > > And I do have: > > 990 TCP FTPSERV2 SECURE TESTING ; SSLSERV > test 00229 > * TCP FTPSERV2 SECURE TESTING ; SSLSERV test > > In my PROFILE TCPIP I believe you. No errors on the TCPIP console at initialization? None on the SSL server console? What do the SSL traces show you? You're showing classic symptoms of something blocking the client's data connection. Naturally, without a trace it is rather difficult ot confirm. Alan Altmark z/VM Development IBM Endicott
Re: Secondary FTP Server Help
On Aug 3, 2006, at 11:09 AM, Alan Altmark wrote: On Thursday, 08/03/2006 at 09:55 MST, Adam Thornton <[EMAIL PROTECTED]> wrote: PASV 227 Data transfer will passively listen to 192,168,131,1,4,31 NLST 125 List started OK Encrypted, the firewall can't see the PASV command and so it isn't opening port (4,31). What firewall? Shall I send you a network diagram (off-list) ? There ain't no such animal. There are a number of routers, granted, but no firewalls. And I do have: 990 TCP FTPSERV2 SECURE TESTING ; SSLSERV test 00229 * TCP FTPSERV2 SECURE TESTING ; SSLSERV test In my PROFILE TCPIP Adam
Re: Secondary FTP Server Help
On Thursday, 08/03/2006 at 09:55 MST, Adam Thornton <[EMAIL PROTECTED]> wrote: > PASV > 227 Data transfer will passively listen to 192,168,131,1,4,31 > NLST > 125 List started OK Encrypted, the firewall can't see the PASV command and so it isn't opening port (4,31). Alan Altmark z/VM Development IBM Endicott
Re: Secondary FTP Server Help
On Aug 2, 2006, at 9:24 PM, Alan Altmark wrote: You can either activate the FTP server command exit and sample, or use TCPSNIFF to watch what's going on. A separate data connection is always used, even for passive FTP. An ephemeral port number is used. If passive FTP is really being used, then the problem is usually a firewall that only opens certain port ranges to the target host. And, no, there is not [yet] a way to control the ephemeral port numbers used by the FTP server. I guess I need to learn to use TCPSNIFF. I'm pretty sure there are no firewalls in the mix, since I built the network between here and there (the bits over the public Internet are over a VPN that I control, and it ends up looking exactly like a wide-open network). Unencrypted FTP gives me: PASV 227 Data transfer will passively listen to 192,168,101,110,14,63 NLST 125 List started OK 250 List completed successfully. Fair enough. Encrypted, I get PASV 227 Data transfer will passively listen to 192,168,131,1,4,31 NLST 125 List started OK ...and then nothing else ever comes back. Adam
Re: Secondary FTP Server Help
On Wednesday, 08/02/2006 at 06:04 MST, Adam Thornton <[EMAIL PROTECTED]> wrote: > I now have things apparently working, except that when I ask for a > list of files, I never get any data, and the connection times out. > > Which is strange, since I'm sure I'm in passive mode, and so the > server should just be using the same connection. You can either activate the FTP server command exit and sample, or use TCPSNIFF to watch what's going on. A separate data connection is always used, even for passive FTP. An ephemeral port number is used. If passive FTP is really being used, then the problem is usually a firewall that only opens certain port ranges to the target host. And, no, there is not [yet] a way to control the ephemeral port numbers used by the FTP server. Alan Altmark z/VM Development IBM Endicott
Re: Secondary FTP Server Help
On Aug 2, 2006, at 8:17 PM, Thomas Kern wrote: That is the problem I get with most clients that claim to support implicit FTPS. I will also check my settings for Secure_FTP client and let you know what they are. I think I also set the secured FTP server to do a unix style list of files. Tried Unix listings; it didn't help. I also tried using lftp, which *should* be straight-ahead command-line FTP, and it had the same behavior: I logged in fine, got to the target directory fine, asked for a file list, and nothing ever came back. Adam
Re: Secondary FTP Server Help
That is the problem I get with most clients that claim to support implicit FTPS. I will also check my settings for Secure_FTP client and let you know what they are. I think I also set the secured FTP server to do a unix style list of files. /Tom Kern /301-903-2211 --- Adam Thornton <[EMAIL PROTECTED]> wrote: > On Aug 2, 2006, at 5:54 PM, Thomas Kern wrote: > > > I am at home now, but will check my config stuff tomorrow at work > > and will > > bundle them together and send them to you. > > Thanks > > I now have things apparently working, except that when I ask for a > list of files, I never get any data, and the connection times out. > > Which is strange, since I'm sure I'm in passive mode, and so the > server should just be using the same connection. > > Adam > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Secondary FTP Server Help
On Aug 2, 2006, at 5:54 PM, Thomas Kern wrote: I am at home now, but will check my config stuff tomorrow at work and will bundle them together and send them to you. Thanks I now have things apparently working, except that when I ask for a list of files, I never get any data, and the connection times out. Which is strange, since I'm sure I'm in passive mode, and so the server should just be using the same connection. Adam
Re: Secondary FTP Server Help
I am at home now, but will check my config stuff tomorrow at work and will bundle them together and send them to you. /Tom Kern /301-903-2211 --- Adam Thornton <[EMAIL PROTECTED]> wrote: > So, I've set up ftpserv2, which I want to listen on port 990 of my > secondary stack, which is TCPIP2. z/VM 4.4. > > In his SNAVM5 DTCPARMS file (this is on node SNAVM5, natch), I've got > > :Nick.FTPSERV2 :Type.server :Class.ftp :Parms.port 990 > > Which seems to be what I want, according to p. 41 of my TCPIP > Planning and Customization for z/VM 4.4. > > DTCRUN1011I Server started at 15:18:29 on 2 Aug 2006 (Wednesday) > DTCRUN1011I Running "SRVRFTP PORT 990" > DTCFTS0018I VM TCP/IP Server-FTP Level 440 15:18:29 EDT WEDNESDAY > 2006-08-02 > DTCFTS0002I Using translate table STANDARD TCPXLBIN. > DTCFTS0310I Unable to find input file: PORT 990 * > > So clearly it's seeing the SNAVM5 DTCPARMS, but then it thinks > that :parms.port 990 means it's supposed to read that as a file name, > not just use port 990. > > What am I doing wrong? > > Adam > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Secondary FTP Server Help
Adam, Interesting. That little example is wrong (and it's still wrong in the 5.2.0 doc). See the information on the SRVRFTP CONFIG file in the chapter on configuring the FTP server. The PORT specification goes in there. Regards, Miguel Delapaz z/VM TCP/IP Development The IBM z/VM Operating System wrote on 08/02/2006 04:17:19 PM: > So, I've set up ftpserv2, which I want to listen on port 990 of my > secondary stack, which is TCPIP2. z/VM 4.4. > > In his SNAVM5 DTCPARMS file (this is on node SNAVM5, natch), I've got > > :Nick.FTPSERV2 :Type.server :Class.ftp :Parms.port 990 > > Which seems to be what I want, according to p. 41 of my TCPIP > Planning and Customization for z/VM 4.4. > > DTCRUN1011I Server started at 15:18:29 on 2 Aug 2006 (Wednesday) > DTCRUN1011I Running "SRVRFTP PORT 990" > DTCFTS0018I VM TCP/IP Server-FTP Level 440 15:18:29 EDT WEDNESDAY > 2006-08-02 > DTCFTS0002I Using translate table STANDARD TCPXLBIN. > DTCFTS0310I Unable to find input file: PORT 990 * > > So clearly it's seeing the SNAVM5 DTCPARMS, but then it thinks > that :parms.port 990 means it's supposed to read that as a file name, > not just use port 990. > > What am I doing wrong? > > Adam
Secondary FTP Server Help
So, I've set up ftpserv2, which I want to listen on port 990 of my secondary stack, which is TCPIP2. z/VM 4.4. In his SNAVM5 DTCPARMS file (this is on node SNAVM5, natch), I've got :Nick.FTPSERV2 :Type.server :Class.ftp :Parms.port 990 Which seems to be what I want, according to p. 41 of my TCPIP Planning and Customization for z/VM 4.4. DTCRUN1011I Server started at 15:18:29 on 2 Aug 2006 (Wednesday) DTCRUN1011I Running "SRVRFTP PORT 990" DTCFTS0018I VM TCP/IP Server-FTP Level 440 15:18:29 EDT WEDNESDAY 2006-08-02 DTCFTS0002I Using translate table STANDARD TCPXLBIN. DTCFTS0310I Unable to find input file: PORT 990 * So clearly it's seeing the SNAVM5 DTCPARMS, but then it thinks that :parms.port 990 means it's supposed to read that as a file name, not just use port 990. What am I doing wrong? Adam
