Port 2710 is SSO and WAS (Websphere) optionally implements SSO ... sounds like you have WAS configured for single signon.
On Thu, May 6, 2021 at 4:13 AM Charles Mills <[email protected]> wrote: > I have been seeing intermittent FTP failures in a particular environment > and > when they occurred I was always up to my butt in some other mess of > alligators so I just moved on from the FTP problem at the time. Yesterday > and today I set out to try to nail it down and I am looking for help in > understanding what I am seeing. All FTP clients and servers in the > discussion below are on recent versions of z/OS. > > In a non-passive FTP environment, the FTP client specifies that the server > connect back to the client on the client's IP address and some indicated > port. That specification looks like > > EZA1701I >>> PORT 204,90,***,***,10,153 > > 204,90,***,*** is the IP address (more familiarly presented as > 204.90.***.***) and the 10,153 is the port in "binary octet value" format: > you interpret 10,153 as (10*256)+153 = 2713. > > The FTP client apparently (I would appreciate any clarification on this) > asks the IP stack for a port, and the IP stack responds with a port number. > On the first call after TCPIP is started it responds with 1025, then 1026 > and so forth. (I would assume it goes through 65535 and then recycles back > to 1025). Is my understanding of this process correct? > > My FTP client succeeds when the port is 1025, 1026, 1027, ... etc. until it > gets to port 2240, when the dialog looks like > > EZA1736I GET 'dsname' > EZA1701I >>> PORT 204,90,***,***,8,192 > > 200 Port request OK. > > EZA1701I >>> RETR 'dsname' > EZA2589E Connection to server interrupted or timed out. Waiting for reply > > EZA1721W Server not responding, closing connection. > > EZA1735I Std Return Code = 16200, Error Code = 00009 > > It also fails for ports 2710 and 3391, but no other ports between 1025 and > 3392. (I have not tested significantly beyond 3392.) MOST SIGNIFCANTLY my > FTP client fails on the identical ports for two completely unrelated > (different owners, different geographies, different sysprogs) z/OS servers, > so I guess the problem must be at the client end. Any have any other > possible interpretation? > > What should I be looking for? Is this problem familiar to anyone? FWIW, the > client is running on IBM Dallas. I doubt that their firewalls are blocking > random ports, but of course I could be wrong. NETSTAT shows nothing on the > failing ports. > > Thank you for any clarification, > > Charles > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
