Reverse TELNET and modem control signals

[Max Bruno Jarvis]

I'm driving some serial lines from an Integrity server with OpenVMS 8.3H1, using a Lantronix EDS32PR terminal server via TCP/IP and a reverse TELNET connection. Software written in C. For reading and writing data it all works fine using QIOs specified in the IO Users Reference manual under 'Terminal Driver'. But, I now need to drive the RTS signal output from the terminal server port. I've tried doing it using a QIO IO$_SETMODE!IO$_M_SET_MODEM!IO$M_MAINT, as specified in the same manual, but it doesn't seem to work. There is a comment in the manual to the effect that this method doesn't work for LAT connections: maybe it doesn't work for reverse TELNET connections either? Maybe there's some special message (in TELNET protocol?) to control the RTS output? Does anybody have any experience of this?

Thanks in advance... Max.

[P Muralidhar Kini]

Hi Max,

Check the following link,
http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1276437717171+28353475&threadId=1315022

Hope this helps.

Regards,
Murali

[John Gillings]

Max,

>Does anybody have any experience of this?

Yes, lots. You're not using the terminal driver. Reverse TELNET has ONE purpose and ONE purpose only. It's there to support printers ONLY. If the device at the other end is not a printer, don't waste your time trying to make it work. It won't.

Please give some more detail on the "big picture" problem you're trying to solve. There may be other mechanisms.

[Max Bruno Jarvis]

John: I think you may be unduly pessimistic. The item at the other end of the serial link is not a printer, and it works fine. I use read, write and read-after-prompt QIOs on the TNAxxx device. I can send and receive messages containing every hex value from 00 to FF. The only thing I can't do is drive the RTS output pin on the terminal server, which I need for controlling a modem. Up to now I've been satisfied with the fact that the RTS pin is always asserted, but now I need to control it.

The reverse TELNET connection is created with /protocol=RAW, so all data passes through unaltered. Have you any experience with create session/protocol=TELNET?

[Jon Pinkley · Accepted solution]

Max,

While I agree that reverse telnet connections are useful for more than printers, it is not equivalent to a functionality provided by a VMS terminal port driver. It has less functionality than LAT, and LAT is not transparent from a programmers point of view. What it sounds like you are asking for is something like the Lantronix COM port redirector, but for VMS. And as far as I know, nothing like that exists. There is an "experimental" RFC 2217 that is an extension to the TELNET protocol to enhance the Com Port Control capabilities, but I don't know if any TCP/IP TELNET implementations for VMS support this.

http://www.lantronix.com/pdf/EDS16PR-32PR_PB.pdf EDSxxPR Family - Product Brief

http://www.lantronix.com/pdf/EDS16PR-32PR_QS.pdf EDSxxPR Family - Quick Start Guide

http://www.lantronix.com/pdf/EDS_UG.pdf EDS - User Guide

http://www.lantronix.com/pdf/EDS_CR.pdf EDS - Command Reference

http://www.lantronix.com/device-networking/utilities-tools/com-port-redirector.html Describes Windows utility to redirect a virtual com port to a EDS port. As far as I know, nothing like this exists for VMS.

Perhaps you could ask Lantronix how a non-windows O/S can control/monitor modem control signals on the EDS32PR ports.

http://www.faqs.org/rfcs/rfc2217.html RFC2217 - Telnet Com Port Control Option (Category: Experimental)

I have no idea if an VMS TCP/IP Telnet software supports this experimental RFC. I tried (without much success) a Google search for RFC 2217 +openvms

http://www.columbia.edu/kermit/ck80.html This claims "C-Kermit now supports RFC 2217: Telnet Com Port Control. When dialing out from an access (reverse terminal) server that supports this option (such as a Cisco 2509 or a Linux-based sredird or telnetcpcd server), and that was contacted using Telnet protocol, C-Kermit can now set and examine the port's serial communications parameters: speed, flow control, modem signals, etc, and can send BREAK signals from the server's serial port." Whether this is supported on VMS, I don't know. I don't have C-Kermit 8.0 loaded.

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1290292 LAT would probably work for you, but the EDS32PR does not support LAT. Getting a LAT capable terminal server and using LAT may still be the cheapest option, if your time is worth much.

Good luck,

Jon

[abrsvc]

I will also state that we use reverse telnet for more than printers without problems.

I second the request for the overall picture though. If we have a better understanding of what is trying to be accomplished here, better guidance can be provided.

Dan

[Max Bruno Jarvis]

Well, here's the full picture, though I don't think it'll help much. The device I'm talking to (called an 'RTU') has one modem, and there is one comms line to it (copper). The master computer (OpenVMS plus Lantronix EDS32PR) has a choice of two modems via which it can talk to each RTU, in case one fails. Each modem is on a separate terminal server port. The two comms lines on the audio side of these two modems meet in a device called a 'hybrid' - you can think of it as a transformer with two primaries (from the master computer's two modems) and one secondary (the comms line to the RTU's modem). So, it's important that only one of the two modems emits carrier at once, otherwise the two carriers will get mixed together and data will be garbled. NB these modems are simple V24 fixed-line modems, no dialling or anything like that, just digital-to-audio and vice versa. They turn on their output carrier only when fed with an RTS signal.

I asked the question of Lantronix yesterday, but no reply yet.

[John Gillings]

Max,

1>and it works fine

2>The only thing I can't do is drive
2>the RTS output pin

Contradictory statements. It doesn't "work fine" because you can't drive the RTS pin.

I assert that there's nothing you can do from the OS perspective to fix your issue in this situation because reverse TELNET was not designed to control modem signals.

That's the story you're going to hear from HP engineering if you raise a support case.

You can request that HP change their software to do what you want/need, but even if they accept your request (good luck!) you won't see anything useable for a very long time, if ever.

If you need to run your modems and control RTS anytime soon, you'll need to find a different mechanism. You could use LAT, but that will require a fairly significant change in your code, or you can find a different hardware device that provides the controls you require, by presenting the modem to OpenVMS as a real terminal.

Note that saying that something "works" and saying it's "supported" can be very different. If Dan (abcsrv) is successfully using reverse telnet for some purpose other than its designed intent, that's great, and good luck! But, as soon as you find some wrinkle that doesn't work (such as inability to drive modem control signals), you're stuck.

Been there, done than, hit several brick walls, given up and implemented it using a different mechanism.

[abrsvc]

John,

I agree with your assessment of HP's response (as former DEC/HP employee I said it many times too). However, i took a look at the doc for the Lantronix and I believe that there is a way to do what is required WITHOUT violating the use of reverse Telnet.

The Lantronix allows for direct control as would a DECserver from a command line as well as from direct programming. I will look more into this, but I believe that turning the ports on/off or enabling modem control or disabling it MAY provide the functionality that is required.

More to follow...

Dan

[Jeremy Begg]

Hi Max,

Just a thought ... can the terminal server be configured so that it doesn't assert RTS unless a host has a TCP/IP connection to the port?

If so, then so long as your program doesn't open connections to both ports simultaneously, you shouldn't have any conflicts on the wire.

Regards,
Jeremy Begg

[Max Bruno Jarvis]

Can't be bothered with shades of meaning of 'works', 'is supported', etc. Here's what I've heard from Lantronix: (1) The RTS pin on the EDS32PR can't be controlled at the moment, but they plan to introduce support for a protocol named RFC 2217, probably at end of 2011 which is too late for me. (2) The DTR output pin, which I could connect to the RTS input on my modems, can be set up to be asserted only when the port is connected. I'm not sure at this stage what exactly is meant by 'the port is connected' but I will be experimenting. Sounds like a bit of a software redesign will be needed so this may take me some time, will report back when possible.

[Max Bruno Jarvis]

Later.... early experiments seem to show that 'the port is connected' just means that an OpenVMS application has a VMS channel assigned to the reverse Telnet device (e.g. TNA101). This may be not be too bad after all. Thanks to all for your help.

[Hoff]

If you're not locked into that network connection and that terminal server as part of your implementation, then a USB modem or USB serial might be an option.

http://labs.hoffmanlabs.com/node/512

Unsupported, but might well work for your needs.

Another option is to use a different operating system as a gateway, and connect (in or out) via that. (If an operating system doesn't provide what you need, use one that does.)