Telnet session with fixed TNAnnn: name?
Wilm Boerhout
terminal device name (TNAnnn:) when a user on that PC uses a TELNET
client to login to VMS. In other words, IP-address 192.168.14.12 always
uses TNA12:, 192.168.14.13 always uses TNA13:, etc.
I use VAX VMS 7.3, TCPIP 5.1 with latest ECOs.
I know I can do a TELNET /CREATE host port unit /PROT=TELNET to create
an "outgoing" TELNET session to PC "host" associated with TNAunit:
Indeed, the terminal device TNAunit: appears after issuing this command.
Question: how to connect to that session from the PC side? I'd like to
use a TELNET client to send an unsolicited CR to the VAX, in the hope
that LOGINOUT.EXE responds on TNAunit:, allowing the user to log in.
My understanding of TELNET sessions is virtualy no-existant, so I may
have chosen the wrong path in creating the outgoing session?
--
Wilm Boerhout
w.boer...@PAINTplanet.nl
(remove OLD PAINT from reply address)
Larry Kilgallen
> I need to fix the relationship between a PCs IP-address and the VMS
> terminal device name (TNAnnn:) when a user on that PC uses a TELNET
> client to login to VMS. In other words, IP-address 192.168.14.12 always
> uses TNA12:
And what behavior would you expect for the _second_ Telnet connection
from 192.168.14.12 while the first one is still running ?
> I know I can do a TELNET /CREATE host port unit /PROT=TELNET to create
> an "outgoing" TELNET session to PC "host" associated with TNAunit:
> Indeed, the terminal device TNAunit: appears after issuing this command.
>
> Question: how to connect to that session from the PC side?
That implies a fully cooperative non-hostile PC user, which was not
part of the specification in your first paragraph (above).
JF Mezei
> I know I can do a TELNET /CREATE host port unit /PROT=TELNET to create
> an "outgoing" TELNET session to PC "host" associated with TNAunit:
> Indeed, the terminal device TNAunit: appears after issuing this command.
Problem is that the TELNET/CREATE will attempt to create a "pipe" between an
essentially random port number on the VMS side and port 23 on the PC. If the
PC doesn't have anything accepting the call on its port 23, the TELNET/CREATE
will fail. If the PC accepts the call, it will be connected to a device owned
by your process. If the link gets disconnected at any point in time, it won't
get automatically re-established.
There is a lexical function to optain the IP address associated with a TN
device. (use google to get it, it escapes me at the moment).
Perhaps if you explained why you would want to have a fixed TNA device
associated with each machine, we might be able to offer solutions.
Mike Naime
Wilm Boerhout <w.boer...@PAINTplanet.nl> wrote in message
news:bqb7ej$dmb$1...@reader10.wxs.nl...
> I need to fix the relationship between a PCs IP-address and the VMS
> terminal device name (TNAnnn:) when a user on that PC uses a TELNET
> client to login to VMS. In other words, IP-address 192.168.14.12 always
> uses TNA12:, 192.168.14.13 always uses TNA13:, etc.
You might want to investigate SET PROCESS/NAME= to identify the terminal
instead of attempting to assign a device. This is easier to assign, and
does not walk all over the correct way that the system is supposed to run.
When the user logs in, you can set the process name. Note: VMS already does
this. If you have unique logins, then the process is always the username.
> I use VAX VMS 7.3, TCPIP 5.1 with latest ECOs.
>
> I know I can do a TELNET /CREATE host port unit /PROT=TELNET to create
> an "outgoing" TELNET session to PC "host" associated with TNAunit:
> Indeed, the terminal device TNAunit: appears after issuing this command.
>
> Question: how to connect to that session from the PC side? I'd like to
> use a TELNET client to send an unsolicited CR to the VAX, in the hope
> that LOGINOUT.EXE responds on TNAunit:, allowing the user to log in.
>
> My understanding of TELNET sessions is virtualy no-existant, so I may
> have chosen the wrong path in creating the outgoing session?
There are also Virtual Terminals that you could re-connect to if the
connection was dropped, but that would not help you if a user logged out
normally.
David J. Dachtera
>
> I need to fix the relationship between a PCs IP-address and the VMS
> terminal device name (TNAnnn:) when a user on that PC uses a TELNET
> client to login to VMS. In other words, IP-address 192.168.14.12 always
> uses TNA12:, 192.168.14.13 always uses TNA13:, etc.
Since that's not really possible, perhaps if you said what problem
you're trying to solve, someone could post a suggestion or two.
If it has something to do with the AutoLogin Facility (ALF), perhaps the
docset and the FAQ may be of some help.
--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Michael Austin
You have described how you would like to have a user connect, but you
really have not identified the problem you are trying to solve. There
may be an easier way to do what you really need.
to reply to part of your problem, Virtual Terminals also have a timeout
value set to where they will also eventually "disconnect".
Michael Austin
Wilm Boerhout
>
> If it has something to do with the AutoLogin Facility (ALF), perhaps the
> docset and the FAQ may be of some help.
>
In reply to all sofar: OK, this loose pipe floating around isn't going
to connect anywhere useful. I told you I'm ignorant on TCPIP.
The problem I'm trying to solve has to do with a very old application
that uses autologin sessions (from trusted workstations on the local
network) with TXAn: devices. Station names are encoded via the 4
character TXAn device name, that is also used in SYSALF.DAT (SYSMAN ALF).
The application source is no longer avaiable, but the tables defining
the station names may be modified. My plan was to create TNAn device
names and using these in the tables (I need only 7 stations)
I know ALF can use port names to define autologin from LAT, using the
TT_ACCPORNAM structure. However -and this may be a missing feature in
TCPIP Servcies-, the TT_ACCPORNAM structure for incoming TELNET contains
spaces ("Host: whatever Port:1234") and SYSMAN ALF will not allow me to
enter that structure (spaces not allowed apparently). Even if it would,
I do not need the remote port name there as I would like incoming TELNET
from that PCs IP address -from any port- to autologin.
By the way, they all need to autologin to the same username. I know, it
sounds silly, but the application has been working that way since 1986,
and I'm not going to change it know. And, It's in COBOL, and in German.
I'm Dutch, and speak only Fortran anyway.
Wilm Boerhout
$ MC SYSMAN ALF ADD "Host: whatever Port:1234" SYSTEM /PORT
$ MC SYSMAN ALF SHO *
%SYSMAN-I-ALFFIL, contents of ALF database on node VAXPWR
Terminal/Port Name Username
-------------------------------------- --------
Host: SYSTEM
$ type sys$system:sysalf.dat
Host: zeus Port: 1234 SYSTEM
Still need to lose the Port: part for this autologin to work, though...
>
> I know ALF can use port names to define autologin from LAT, using the
> TT_ACCPORNAM structure. However -and this may be a missing feature in
> TCPIP Servcies-, the TT_ACCPORNAM structure for incoming TELNET contains
> spaces ("Host: whatever Port:1234") and SYSMAN ALF will not allow me to
> enter that structure (spaces not allowed apparently). Even if it would,
> I do not need the remote port name there as I would like incoming TELNET
> from that PCs IP address -from any port- to autologin.
JF Mezei
> $ MC SYSMAN ALF ADD "Host: whatever Port:1234" SYSTEM /PORT
Some telnet clients do allow one to specify which local port number to use for
the outbound call.
So, if the VMS host is told to accept an ALF for an inbound call from machine
X.Y.Z from port yyyy, perhaps that could work.
Another possibility would be to define a new service, mapped to a different
port from telnet. You can then restrict inbound calls to only a specific set
of IP adresses. And you could point to the command procedure and common
username to use to start your application.
Wilm Boerhout
JF Mezei wrote:
> Some telnet clients do allow one to specify which local port number to use for
> the outbound call.
>
> So, if the VMS host is told to accept an ALF for an inbound call from machine
> X.Y.Z from port yyyy, perhaps that could work.
Yes, that would help. I have searched for, but have not yet found a PC
telnet client that has this feature.
>
> Another possibility would be to define a new service, mapped to a different
> port from telnet. You can then restrict inbound calls to only a specific set
> of IP adresses. And you could point to the command procedure and common
> username to use to start your application.
Again, my understanding of TCPIP is lacking here. So, I would define a
TELNET service on VMS on, say, port 2323, and only allow precisely those
7 PC stations' IP addresses. An incoming telnet call to port 2323 would
create a process and associated TNAnnnn: terminal for the user THISUSER,
specified in the TCPIP TELNET service setup.
In my opinion, this would constitute an "autologin", but the
LOGINOUT.EXE is never activated. Right?
Larry Kilgallen
>
>>
>> If it has something to do with the AutoLogin Facility (ALF), perhaps the
>> docset and the FAQ may be of some help.
> I know ALF can use port names to define autologin from LAT, using the
> TT_ACCPORNAM structure. However -and this may be a missing feature in
> TCPIP Servcies-, the TT_ACCPORNAM structure for incoming TELNET contains
> spaces ("Host: whatever Port:1234") and SYSMAN ALF will not allow me to
> enter that structure (spaces not allowed apparently). Even if it would,
That seems like it might be your choice of TCP/IP package or the
configuration thereof.
Multinet running on DECUServe produces the following (obfuscated by me):
$ write sys$output f$getdvi("tt","tt_accpornam")
p123456789q89.subsubdomain.subdomain.example.com
> I do not need the remote port name there as I would like incoming TELNET
> from that PCs IP address -from any port- to autologin.
If this were on Alpha, you could change the supplied username by writing
your own ACME Agent, effective with VMS V7.3-2.
> By the way, they all need to autologin to the same username. I know, it
> sounds silly, but the application has been working that way since 1986,
So I guess your application is not on Alpha.
There is a slight possibility you could do something with LGI_CALLOUTS,
but you would need to use the source listings to get that working, if
indeed it is possible at all.
Peter Weaver
>...
> I know ALF can use port names to define autologin from LAT,
using the
> TT_ACCPORNAM structure. However -and this may be a missing
feature in
> TCPIP Servcies-, the TT_ACCPORNAM structure for incoming
TELNET
> contains spaces ("Host: whatever Port:1234") and SYSMAN ALF
will not
> allow me to enter that structure (spaces not allowed
apparently).
> Even if it would, I do not need the remote port name there
as I would
> like incoming TELNET from that PCs IP address -from any
port- to
> autologin.
While I'm sitting here on a sunny Sunday afternoon waiting for
a 3rd party hardware supplier to bring in a disk to replace
the one that died 3:00 this morning because SOMEBODY DIDN'T
REPLACE THE SPARE AFTER THE LAST DISK FAILED! I thought I
would throw in my two cents. You did not mention the IP stack
you are running, but we had this problem using TCPWare until
we put the PC names into DNS. Once the PC names were in DNS
the TT_ACCPORNAM showed the fully qualified PC name without
the Port. SYSMAN ALF had no problem dealing with it then.
Maybe your IP stack will do the same thing if the PC is listed
in DNS?
--
Peter Weaver
Weaver Consulting Services Inc.
Canadian VAR for CHARON-VAX
www.weaverconsulting.ca
Wilm Boerhout
>
> While I'm sitting here on a sunny Sunday afternoon waiting for
> a 3rd party hardware supplier to bring in a disk to replace
> the one that died 3:00 this morning because SOMEBODY DIDN'T
> REPLACE THE SPARE AFTER THE LAST DISK FAILED! I thought I
> would throw in my two cents. You did not mention the IP stack
I know what you're feeling Peter.
> you are running, but we had this problem using TCPWare until
> we put the PC names into DNS. Once the PC names were in DNS
> the TT_ACCPORNAM showed the fully qualified PC name without
> the Port. SYSMAN ALF had no problem dealing with it then.
> Maybe your IP stack will do the same thing if the PC is listed
> in DNS?
>
I run the Compaq/HP TCPIP Services 5.1 stack. I know I can switch
between TELNET reporting the IP address or the host name, but as far as
I can see the port is always included in TT_ACCPORNAM. Do you expect a
difference between specifying the PC host names in DNS and entering them
in the local "hosts" database (via TCPIP SET HOST xxxx /ADDR=n.n.n.x) ?
Chris Moore
be identified uniquely by the system as "node.domain.com;nn" where 'nn' was
the port # connected to (and couldn't be counted on to be constant) Once
the source was resolved from DNS, the port # didn't interfere. I don't
explain 'em, just report 'em. I did try this successfully with UCX (4.2
ECO10 iirc) a few years back, but we avoid that product (UCX, TCP/IP
Services .... call it what you will) like the plague it is.
(btw Peter just needed to look in the right place for the replacement drive,
it was at SOMEBODY's desk --- perfect spares filing system......lol)
"Wilm Boerhout" <w.boer...@PAINTplanet.nl> wrote in message
news:bqdfo6$c5b$1...@reader10.wxs.nl...
Wilm Boerhout
the choices there-.
It looks like I can use the ALF facilty after all - will report back
sometime next week.
Thanks
Chris Moore wrote:
> Putting them in HOSTS. wasn't enough to get this working. They would still
> be identified uniquely by the system as "node.domain.com;nn" where 'nn' was
> the port # connected to (and couldn't be counted on to be constant) Once
> the source was resolved from DNS, the port # didn't interfere. I don't
> explain 'em, just report 'em. I did try this successfully with UCX (4.2
> ECO10 iirc) a few years back, but we avoid that product (UCX, TCP/IP
> Services .... call it what you will) like the plague it is.
--
Bob Koehler
> I need to fix the relationship between a PCs IP-address and the VMS
> terminal device name (TNAnnn:) when a user on that PC uses a TELNET
> client to login to VMS. In other words, IP-address 192.168.14.12 always
> uses TNA12:, 192.168.14.13 always uses TNA13:, etc.
You better tell us what problem you're trying to solve by doing this
as you're likely not to be successfull at this.
Wilm Boerhout
UCX 4.1 ECO 10. I reconfigured the BIND stuff and the rest of the core,
go the VAX a new name and address that is in the central DNS store.
Result: TT_ACCPORNAM still is filled with
"Host: node.dom.ain Port: 1234"
so no luck with ALF. I've not been able to find terminal emulators that
allow me to specify the local (outgoing) port number. SYSMAN ALF doesn't
allow wildcarding.
BTW I would consider upgrading to UCX 4.2, but I already know that TCPIP
SVCS 5.1 and onwards exhibit the same behaviour.
Still looking for a way to autologin terminal sessions based on
IP-address / DNS name using UCX / TCPIP SVCS
$WITS_END:
$ GOTO WITS_END
Wilm
Larry Kilgallen
> I just returned from another experiment. Turns out that the system runs
> UCX 4.1 ECO 10. I reconfigured the BIND stuff and the rest of the core,
> go the VAX a new name and address that is in the central DNS store.
>
> Result: TT_ACCPORNAM still is filled with
>
> "Host: node.dom.ain Port: 1234"
>
> so no luck with ALF. I've not been able to find terminal emulators that
> allow me to specify the local (outgoing) port number. SYSMAN ALF doesn't
> allow wildcarding.
>
> BTW I would consider upgrading to UCX 4.2, but I already know that TCPIP
> SVCS 5.1 and onwards exhibit the same behaviour.
Would you consider upgrading to Multinet/PMDF, which exhibits
your desired behavior on EISNER:: ?
Wilm Boerhout
> Would you consider upgrading to Multinet/PMDF, which exhibits
> your desired behavior on EISNER:: ?
I would if the supplier of Multinet offered a "competitive upgrade" from
UCX at nearly zero cost. I will seriously look into it though, me
being at wit's end...
Larry Kilgallen
> Larry Kilgallen wrote:
>
>> Would you consider upgrading to Multinet/PMDF, which exhibits
>> your desired behavior on EISNER:: ?
>
> I would if the supplier of Multinet offered a "competitive upgrade" from
> UCX at nearly zero cost.
If things* were free, I would be running a GS1280.
*including electricity.
Wilm Boerhout
Larry Kilgallen wrote:
> There is a slight possibility you could do something with LGI_CALLOUTS,
> but you would need to use the source listings to get that working, if
> indeed it is possible at all.
I have a cunning plan...
The documented interface to LOGINOUT callout *suggests* that it is a
possible route for me. The CALLOUT / CALLBACK environment appears to
have access to the ACCPORNAM structure. The example code doesn't look
too complicated, and I have used callout/callback routines before,
albeit for the VMS print symbionts (I wrote an X.25 print symbiont when
that was considered useful, 1988 or thereabouts).
I suggest a very small LOGINOUT callout that modifies the ACCPORNAM
structure during initialization phase, so that by the time the autologin
is checked, it will find the modified structure, from which I have
deviously and cunningly removed the "Port: 1234" part.
Is this worth looking into?
Security is not an issue, otherwise I would not consider autologin at
all from PCs. It's simple operational expedience that caused autologin
from TXAn: ports in the first place.
Wilm