[ On Friday, July 21, 2000 at 17:07:34 (+0300), Jukka Marin wrote: ]
> Subject: Re: pty and baud rate?
>
> It's a device I designed (and I need to design another one even more like
> a terminal server).  It will be used just like a serial port, but not for
> real dialling.. just to talk to various things which only have serial
> ports.  (But you could hook up modems to the box as well..)

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

I now use a real terminal server that supports "reverse telnet" in
exactly this way in order to connect to the console ports of the various
systems and devices that I'm not always able to, or desirous of, being
directly in front of.

However in the past I've done something very similar to what you want to
do, in a very primitive fashion, using scripts invoked from inetd and
using telnet to connect to the "server".  That only gave me line-mode,
of course, but it was just a quick hack at the time....

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 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.  I've also been
thinking of it a wee bit recently, at least of doing the client side so
that I could hook my UPS cables up to the terminal server too.

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

PTY TIOCUCNTL mode could also be used, but it is rather generic and
requires developing a custom protocol to make use of it.

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

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.

For example you could implement a custom rlogind/telnetd that uses the
authentication information for selecting the tty and the speed, etc., so
that the remote user would "rlogin -l tty01:9600 termserver.host" in
order to be connected to /dev/tty01 on termserver.host at 9600 baud.

Typically terminal servers implementing true reverse telnet use a unique
port number to specify the physical port to be connected to (as do my
DECs).  You could assign groups of ports to select the baud rate,
etc. if you want to use telnet as the connection protocol.

Finally you could even implement a simple user interface that would
allow the user to "escape" out to it and control the port parameters.
It would probably be easier to modify telnetd to do this than
rlogind....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>