On Fri, Jul 21, 2000 at 04:36:02PM -0400, Greg A. Woods wrote:
> Ah, OK, so it seems like you're trying to do what is often called
> "reverse telnet" or similar, where you make a network connection of some
> sort to the system hosting the actual serial ports and you're instantly
> connected to a physical serial port.  I.e. you're building rather the
> opposite of what most people might think of as a traditional "terminal
> server".  :-)

Yep.  I need this to talk to some device programmers and other special
hardware I'm developing and testing.  I have several serial ports on my
NetBSD machines, but it would be easier to run a single Ethernet cable
across the room instead of having 5 or more serial cables (which are
always too long or too short).

> So far I've never seen any real terminal server that does exactly what
> you want to do though -- i.e. which mirrors to the real tty the settings
> from the pseudo-tty of the remote "client" host.  For example the real
> terminal servers I'm using, DECserver 90TL's and DECserver 900TM's,
> force you to either hard-code the port speed and similar parameters, or
> else to support auto-baud configuration.

I want everything to be automatic and transparent because I have several
programs that talk to external devices via serial ports and use custom
packet protocols.  While I _could_ change these programs to have some kind
of TCP or UDP support, I'd rather leave them alone and now it seems it
won't be too difficult to do that.

> I explored these issues briefly one time when I was thinking of building
> a "real" terminal server that would either be based directly on a unix
> kernel (just like the xylogics ones), or at least integrate well with
> unix.  I didn't see a simple solution at the time.

Well, I'll be using some custom hardware as a server.. I happen to have
a few suitable boxes lying around and I'll have to design one with eight
serial ports later.  (This one will need an nt driver (urgh) but I plan
to use it with NetBSD myself..)

> PTY Packet mode (TIOPKT), and the TIOCPKT_IOCTL flag as described in
> pty(4) should work to handle the kinds of changes you want to mirror
> onto the physical port.  It is used in rlogind and telnetd for various
> operations, eg. to communicate flow control happenings, such as when the
> user hits '^S', or when writes are flushed, or Window size changes
> (using the undocumented TIOCPKT_WINDOW flag hack).  Although the manual
> page says a complete copy of the new termios structure is available on
> the pty after a control packet with TIOPKT_IOCTL is received, rlogind
> doesn't (yet) do anything with the baud rate contained therein (and
> probably telnetd doesn't either).

Yep, I'll try using this method.  

> Of course either way you also have to write a little helper program to
> set up the pty on the client and to open the channel to the port server,
> as well as write/modify the server program so that it opens the physical
> port and mirrors the IOCTL settings it receives.  I would pick telnetd
> as the server to modify....

I'll need to write my own server code because it will be running on my own
OS.. :-)

> However there are a number of simple conventions you could employ to
> work around this, depending on how wedded you are to actually providing
> a local /dev/ttyp* thingy vs. just using telnet or rlogin directly.

I'd like the server to support both, actually.  Sometimes I need to talk to
devices which have a pure ASCII configuration menu - it would be easy to use
telnet to talk to them (via the terminal server).  But when I need those
packet protocols, I want to have a serial port look-a-like on NetBSD to be
able to run the protocols like before.

> Finally you could even implement a simple user interface that would
> allow the user to "escape" out to it and control the port parameters.

Yep, but this would not work with the packet protocols (but it would be
good for the ASCII stuff).

Ahh, so many good ideas, and so little time to get everything done.. :-I

  -jm