If a port is in use, I would not expect that port number to be returned when requesting the next available port number, and I would expect it to show up in a netstat command.
I think a firewall is blocking the ports you are having a problem with. In the IP Configuration Reference https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc273651?OpenDocument it says the default for EPHEMERALPORTS is 1024 - 65535. Perhaps you can get the EPHEMERALPORTS changed to 49152 - 65535, based on what I see in https://en.wikipedia.org/wiki/Registered_port Ports 0–1023 – system or well-known ports Ports 1024–49151 – user or registered ports Ports 49152–65535 – dynamic / private / ephemeral ports Bill On Wed, 5 May 2021 15:25:33 -0700, Charles Mills wrote: >As far as I know we are not running WAS or any SSO product. How would they >show up if we were? What would the name most likely be in SDSF DA? > >As I said in my post, "NETSTAT shows nothing on the failing ports." > >Charles > > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On >Behalf Of Attila Fogarasi >Sent: Wednesday, May 5, 2021 3:16 PM >To: [email protected] >Subject: Re: Looking for help understanding an FTP problem > >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. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
