1753521 Members
5728 Online
108795 Solutions
New Discussion юеВ

Serving Telnet Clients

 
SOLVED
Go to solution
RF Thomas
Frequent Advisor

Serving Telnet Clients

We are currently using Decservers and LAT to communicate with VTxxx terminals and various machinery. The devices are setup as printers on the servers.

We would like to transition to Telnet devices.

How does one set-up static connections to telnet devices? We currently have several printers connected using the telnet print symbiot.
13 REPLIES 13
Hoff
Honored Contributor

Re: Serving Telnet Clients

Look in the old OpenVMS Ask The Wizard (ATW) area -- pull down the wizard.zip archive that is available on the http://www.hp.com/go/openvms/wizard web page -- and unpack it.

There were a number of discussions in the ATW area around moving from LAT to telnet, and from LAT printers to lpr/lpd or telnetsym or raw printing, around IP printing in general (start with ATW topic 1020 for that), and around reverse LAT and reverse telnet connections.

The wizard.zip archive contains most everything that was posted at ATW over the years, and you can unpack and search it locally. And this material -- and a whole lot more -- is most definitely buried in that archive.

This particular network protocol migration is not a direct drop-in replacement. You will loose certain functions. You will gain routing, and such. Some applications -- such as those that use the LAT $qio operations -- will require re-coding. And AFAIK no transparent magic drop-in translating gateway exists.

Stephen Hoffman
HoffmanLabs
RF Thomas
Frequent Advisor

Re: Serving Telnet Clients

How the software currently works is to have each individual device have a terminal, either a direct serial connection, e.g. through the system console or a multiplexor, or through a directly setup LAT port (LTAnnn).

We know that for the communications required a telnet connected device should work. There is bi-directional ASCII and binary traffic.

So far none of the aticles address this requirement of creating some form of static connection. The connected device would only be communicating with one program that front ends the devices and provides local management.

For some devices a file could be created and "spooled" to a device, but for slaved terminals and other devices such would not work.
RF Thomas
Frequent Advisor

Re: Serving Telnet Clients

The Wizard information is very circuitous but eventually pointed to VMS FAQ that came up with proper term: Reverse Telnet

It appears to do exactly what we need. We will have to work with it to learn it capabilities and limitations. Anyone have experience with this capability?
Hoff
Honored Contributor
Solution

Re: Serving Telnet Clients

What you appear to be describing -- this static serial device connection -- would appear to be the so-called reverse telnet.

LAT calls this reverse LAT. Sometimes known as LAT/Master, if you're into arcane and ancient names.

In typical environments, a telnet TN device is on the destination or target of the connection, and you use some client to communicate with the telnet device on the far end. The client initiates this, and the TN device appears in response to the incoming connection.

Reverse telnet allows you to establish a TN device on the host, and link it with what would normally be a telnet client. To reverse the process, and instantiate the TN device and back-connect it to a client IP port on some terminal server somewhere and somewhere closer to the target serial device.

You probably set up the LAT LT devices in a command procedure and specify the target for the connection. Probably some DECserver port. Usually LTLOAD or LAT$SYSTARTUP. Reverse telnet is basically the same set-up and same "commands stuffed into some startup procedure" configuration, though the port creation command required is different.

Yes, reverse telnet works. There will be some differences in timing between IP and LAT as would be expected, and there will be some differences in capabilities. If you use the LAT $qio interface, you can definitely see a requirement to adjust some source code.


--

"15.2.5 How can I set up reverse telnet (like reverse LAT)?

Though it may seem obvious, Telnet and LAT are quite different-with differing capabilities and design goals.

Please see the documentation around the TCP/IP Services for OpenVMS TELNET command CREATE_SESSION. This command is the equivilent of the operations performed in LTLOAD.COM or LAT$SYSTARTUP.COM. There is no TELNET equivilent to the sys$qio[w] control interface for LTDRIVER (as documented in the I/O User's Reference Manual) available, though standard sys$qio[w] calls referencing the created TN device would likely operate as expected."

--

I'll fix the spelling of "equivilent" for the next edition of the FAQ. At least it was consistently wrong. :-)
RF Thomas
Frequent Advisor

Re: Serving Telnet Clients

We are going to start experimenting with this now. Hopefully everything will work.

Re: Serving Telnet Clients

Hoff:

re: "There is no TELNET equivilent to the sys$qio[w] control interface for LTDRIVER"

The interface is documented in the Sockets API, section "TELNET Port Driver I/O function Codes".

Steve
RF Thomas
Frequent Advisor

Re: Serving Telnet Clients

We setup the ports to static "fixed" devices. We have written our own LAT_CONFIG.COM that reads a file and configures the ports and resulting terminals. We have created a TELNET_CONFIG.COM that does the equivalent.
Hoff
Honored Contributor

Re: Serving Telnet Clients

Stephen, I am well aware of the telnet API. It's not equivalent to the LAT $qio API -- telnet and LAT are different, simply put, and there is stuff that simply isn't available. (I should have phrased that better.) Code changes will be required.



RF Thomas
Frequent Advisor

Re: Serving Telnet Clients

I have a telnet printer server that I am able to connect to using telnet by entering its IP address. When try to us reverse telnet things don't work as desired:

ASTC04> @telnet_config
CREATING TELNET DEVICE TNA4.
%TELNET-S-CRSES, Session created on TNA4
Terminal: _TNA4: Device_Type: VT500_Series Owner: No Owner
Remote Port Info: 192.48.157.31:23

Input: 9600 LFfill: 0 Width: 80 Parity: None
Output: 9600 CRfill: 0 Page: 24

Terminal Characteristics:
Interactive Echo Type_ahead No Escape
No Hostsync TTsync Lowercase Tab
Wrap Scope No Remote Eightbit
Broadcast No Readsync No Form Fulldup
No Modem No Local_echo No Autobaud Hangup
No Brdcstmbx No DMA No Altypeahd Set_speed
No Commsync Line Editing Overstrike editing No Fallback
No Dialup No Secure server No Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters No Printer Port
Numeric Keypad ANSI_CRT No Regis No Block_mode
Advanced_video Edit_mode DEC_CRT DEC_CRT2
DEC_CRT3 DEC_CRT4 DEC_CRT5 No Ansi_Color
VMS Style Input
ASTC04> set host/dte tna4:

%REM-I-TOQUIT, connection established

Press Ctrl/\ to quit, Ctrl/@ for command mode



%REM-E-PORTRXERR, port receive error
-SYSTEM-F-HANGUP, data set hang-up

%REM-S-END, control returned to node ASTC04
%SYSTEM-F-DEVOFFLINE, device is not in configuration or not available
ASTC04>