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
