I am not an expert, but from what little I know, the "lower ports"
(<1024) were considered to be "privileged". The convention was that if
the originating port was <1024, then the remote end could __assume__
that the originator was "authorized" in some special way. And so, by
convention, the "lower ports" were considered to be more "secure" than
the "higher ports". Silly, but this dates from a long time ago.
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
-----Original Message-----
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of RPN01
Sent: Friday, March 07, 2008 2:44 PM
To: [email protected]
Subject: Using UDP port 514 in z/VM TCPIP...
I was going to ask what I was doing wrong... But I figured that
out just a moment ago.
My question now is what is the logic behind requiring a user to
be in TCPIP's Obey list to allow it to use certain TCP/IP ports and
protocols. It isn't everything, because things like FTP work, and I
think you can play fairly fast and loose with higher numbered ports. But
trying to connect to port 514 on another virtual machine wasn't allowed
until I put the user in the Obey list in the PROFILE TCPIP file.
Also: If I violate this using Pipe and the UDP stage, why don't
I get a non-zero return code? The UDP stage quietly accepts records, and
the pipe returns a zero return code, but no data is actually sent.
There's no errors in the TCPIP console log either; the data is just
ignored and not sent anywhere. Shouldn't there be an indication
somewhere that the data wasn't sent? Or (and I confess I haven't tried
to decode anything in the output string yet) is there something in the
output of the UDP stage that would indicate that the message failed to
send?
--
Robert P. Nix Mayo Foundation .~.
RO-OE-5-55 200 First Street SW /V\
507-284-0844 Rochester, MN 55905 /( )\
----- ^^-^^
"In theory, theory and practice are the same, but
in practice, theory and practice are different."
