Wow! Looks like HTML coming from an MVS dataset. I don't think I've
seen that in maybe 20 years.
On 5/6/2021 9:24 AM, Bill Godfrey wrote:
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
