topic Re: Serving Telnet Clients in Operating System - OpenVMS

Serving Telnet Clients

RF Thomas — Fri, 02 Feb 2007 14:09:08 GMT

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.

Re: Serving Telnet Clients

Hoff — Fri, 02 Feb 2007 14:27:12 GMT

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

Re: Serving Telnet Clients

RF Thomas — Fri, 02 Feb 2007 14:56:27 GMT

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.

Re: Serving Telnet Clients

RF Thomas — Fri, 02 Feb 2007 15:15:20 GMT

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?

Re: Serving Telnet Clients

Hoff — Fri, 02 Feb 2007 15:29:34 GMT

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. :-)

Re: Serving Telnet Clients

RF Thomas — Fri, 02 Feb 2007 15:45:10 GMT

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

Re: Serving Telnet Clients

STEPHEN CONWAY_1 — Sun, 04 Feb 2007 10:09:44 GMT

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

Re: Serving Telnet Clients

RF Thomas — Sun, 04 Feb 2007 10:47:06 GMT

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.

Re: Serving Telnet Clients

Hoff — Sun, 04 Feb 2007 15:35:34 GMT

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.

Re: Serving Telnet Clients

RF Thomas — Tue, 06 Feb 2007 15:50:26 GMT

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>

Re: Serving Telnet Clients

Walter Miller_1 — Tue, 06 Feb 2007 15:59:41 GMT

Be sure when you create the telnet device that you specify "/protocol=telnet" as the default is NONE.

Re: Serving Telnet Clients

RF Thomas — Tue, 06 Feb 2007 17:14:04 GMT

/protocol=telnet only made things worse.

/perm allows for a data connection. If we try to connect to another OpenVMS system there appears to be no flow control resulting in a lot of lost data or "data over-runs".

Connecting to a telnet enabled print server we see the same behavior.

Re: Serving Telnet Clients

Hoff — Tue, 06 Feb 2007 17:34:09 GMT

Do go for a bigger buffer as a start: SET TERMINAL /ALTYPAHD -- as for flow control, that's something that I'd expect from telnet, and it does appear that you have ttsync enabled. Bigger buffers definitely helps with data overruns.

If you're going host-to-host, I'd be looking at a different solution. Neither LAT nor telnet does particularly well at running protocols. DECnet over LAT sort of works, but not really, for instance. I'd probably be looking at DECnet over IP, as I know that works.

I don't know that anybody has tried a telnet enabled print server in quite this way, most folks use the telnet symbiont or lpr/lpd for printing. Are you queuing and spooling and copying print files directly to the LTAu: device?

Re: Serving Telnet Clients

RF Thomas — Tue, 06 Feb 2007 18:04:10 GMT

The application involves control, download, upload of data from RS-232-C machine tools connected through LTA devices and now need to transition to TNA (telnet) devices.

The data stream consists of 7-bit ASCII, 7-bit ASCII with even parity, 7-bit EIA with odd parity, various protocols needing , , , along with BCC and LCC, etc.

One device sort of implements DDCMP with that vendor's improvements :(

Additionally, we need to have captive terminals that in the LAT world were treated as printers.

The VMS defaults for ttyahd is much too small. We have set it to 4096 and most of the data over-runs have gone away. We still get some very strange characters when initiating the connection.