sscott@fwhnm02.fwrdc.rtsg.mot.com (Steve Scott) (04/05/91)
On my current work assignment, software development is split between a U.S. site and an international site. There is an existing IP ethernet connectivity between the two development sites. Here is what I would like to do: In the US site, I have a "box" which must be controlled via a 2400 baud RS232 port. In the international site, I have an SysVR3.2-based Unix box which wants to control this "box" via a 2400 baud serial port. Trouble is, they are multiple thousands of miles apart. The obvious solution is to use a couple of 2400 baud modems with MNP (for noise pollution protection). The problem is that we do not know for sure how often (or how long) these connections would have to be made. The long distance charges could eat us up. What I have been asked to evaluate is this: Could we connect the "box" to a Unix computer sitting in the US lab via a serial port and let the US Unix computer and the international Unix computer communicate via the existing TCP/IP network? This seems like a complicated matter to me (but I HOPE I am wrong ;-) +------------+ +-----------+ +----------+ | Controlled |---------| US Unix | |Int. Unix | | Box | | Computer| | Computer| +------------+ +-----------+ +----------+ ^ | | | |--------------------------| | 2400 baud ^ RS232 | Existing TCP/IP connection network connection So, is this possible: Could the Int. Unix computer telnet to the US Unix computer, run cu (or tip) to connect to the Controlled box AND once completed, have that whole "chain of communications" inherited by the application running on the Int. Unix computer (which is expecting to talk to a local /dev/tty type of a connection)? I presume that a dumb terminal emulation would have to be used during the telnet session so that terminal control codes are eliminated (or at least minimized ;-). My biggest problem is: How would I get one application in the Int. Unix box (the one expecting to talk to the serial port) to "attach" itself to the telnet session input/output? To the application, I want the standard in/standard out file descriptors associated with the telnet session to appear to be the input/output via a serial port. So, in general, how does one application take over the standard in/ standard out of another application? Is this possible? Can it be done with "standard" Unix programs (tee, et al.) in a shell script? Or will it require some sort of a (dup/close/execl) type of a C program? OR am I all washed up and there is a better way? Any hints, tips, pointers, etc. would be VERY MUCH appreciated. Thanks, -- +------------------------------------------------------------------------------+ | Steve Scott | Internet: sscott@mot.com | | Fort Worth Research and Development Center | UUCP: csccat!camdev!sscott | | Cellular Infrastructure Group | Internal: TX14/1D | | Radio Telephone Systems Group | Voice: (817) 232-6317 | | Motorola, Inc. | Fax: (817) 232-6081 | | The opinions contained herein are STRICTLY my own | +------------------------------------------------------------------------------+
jik@athena.mit.edu (Jonathan I. Kamens) (04/08/91)
It seems to me that something like this would work: 1) Write a program to run on the US machine, either constantly listening on a particular TCP port or run by inetd when a connection is received on that port. Once this program starts up, it sends all input from the network connection to the serial port of the box, and all output from the serial port of the box to the network connection. You might want to do some sort of authentication (e.g. a password as the first thing sent over the port from the remote connection) to prevent just anyone from connecting to the box over the network. 2) On the International host, write a short program which connects to the port on the US host, sends the password if necessary, dup2()s the socket file descriptor over file descriptors 0, 1, and 2, and then exec()s the program that has to be able to talk to the remote device. Presto, that program thinks it's talking directly to the remote device; it doesn't have to know that it's over a network socket instead of over a serial line. You could probably accomplish the same thing without writing any source code of your own (i.e. only writing scripts) using the expect package (see the comp.unix.questions FAQ for information about getting the sources to it). You might also be able to do it with the pty package (again, see the FAQ), but your system might need to be able to support named pipes in order to do it that way. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710