https://www.ibm.com/docs/en/zos/2.4.0?topic=statements-port-statement
It should obviate the problem. Not yet tested. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Godfrey Sent: Thursday, May 6, 2021 9:24 AM To: [email protected] Subject: Re: Looking for help understanding an FTP problem On the listserv web interface, the link works only if I change the single quotes to percent27. I spell out percent27 here because if I use the percent sign, the listserv might render percent27 as a single quote., which would be confusing to read. For all I know, you may have used the percent27 in the link in your post, which is being rendered as a single quote. What is the "PORT list" you mentioned? Is this something that gets you around the problem? Bill On Thu, 6 May 2021 08:54:18 -0700, Charles Mills wrote: >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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
