Re: Secondary FTP Server Help

2006-08-09 Thread Mark Bodenstein
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

2006-08-08 Thread Alan Ackerman
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

2006-08-08 Thread Adam Thornton

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

2006-08-04 Thread Adam Thornton

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

2006-08-04 Thread Stephen Frazier

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

2006-08-04 Thread Rich Greenberg
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

2006-08-03 Thread Adam Thornton

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

2006-08-03 Thread Adam Thornton

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

2006-08-02 Thread Miguel Delapaz

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 IBMVM@LISTSERV.UARK.EDU
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


Re: Secondary FTP Server Help

2006-08-02 Thread Thomas Kern
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

2006-08-02 Thread Adam Thornton

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

2006-08-02 Thread Thomas Kern
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

2006-08-02 Thread Alan Altmark
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