Michael Anderson wrote:
 
> Here we have security at the LDEV level. To achieve this LDEV level of
> security all applications here hit a dataset of LDEV's an associated
> items.  I'm currently looking into switching to VT sessions and networked
> access. I'm not panning on a re-write of anything, I plan on using the
> NSINFO intrinsic to see if the caller is a VT session, or a serial ATP
> session.  [snip]
 
On 5.0 with appropriate NS patch you get two variables for VT sessions:
  HPSTDIN_NETWORK_NODE = FOO.BAR.COM
  HPSTDIN_NETWORK_ADDR = 123.145.167.189
 
On 5.5, you get HPREMIPADDR/HPREMPORT and HPLOCIPADDR/HPLOCPORT.  If the
session originates from the new Telnet/iX server then HPLOCPORT=23 and
the origin IP address/port are in the HPREM@ variables.  If the session
originates from NS/VT, HPLOCPORT=[1537 or 1570] and HPREM@ variables
give
the origin address.  For DTC connections, HPLOCPORT=0.  There is no
clear way to identify a DTC TAC telnet connection other than examining
the HPDTCPORTID variable for your particular DTC to see if the origin is
a
TAC.  To do this, you must know the MAC address of the DTC and the slot
number of your TAC(s) and check HPDTCPORTID against this pattern:
 
                              slot number
                              vv
   HPDTCPORTID = 080009008595 0505
                 ^^^^^^^^^^^^   ^^ port number (pseudo)
                 Mac address
 
There is currently absolutely, positively no way that I know of,
privileged or otherwise, to determine the origin IP address of a TAC
session from the host.  The DTC Manager can display them, and knows
about them, but can't
filter them (unlike the similar X.25 security lists).
 
And finally (whew!) in a follow-up by Bruce Senn the topic of ethernet
addresses (MAC addresses) was brought up.  I don't think NSINFO or it's
friends will give you this information either as it is (a) buried way on
down there somewhere and (b) only meaningful within the confines of a
single network.  For those of us who can't fit on one class C address
but can't swing a class B address, your connections may very well pass
through
a router (which strips the MAC address).
 
Jeff Kell <[log in to unmask]>