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
