Yup! The answer from Dallas is http://dtsc.dfw.ibm.com/MVSDS/'HTTPD2.DSN01.PUBLIC.SHTML(BLKPORTS)'
I think that is a public document. If it's not, well, sorry. I guess I will add all of these to the PORT list. Thanks everyone for your suggestions. No idea how blocking these improves system security. No idea what exactly is happening very occasionally at our customers. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Godfrey Sent: Thursday, May 6, 2021 7:42 AM To: [email protected] Subject: Re: Looking for help understanding an FTP problem 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
