pty and baud rate?
Jukka Marin
I want to create a "driver" for a "terminal server" in NetBSD. This box
has an Ethernet interface and 8 serial ports. Can I use pty's and a userland
daemon or do I need to create a real kernel device? I want the device to
be almost identical to real tty's (I want the speed, parity, etc. ioctl's
to work so I can use "any" serial port aware software with this hack).
It seems I can set the speed for ttyp? with stty, but is it possible for
the other end of the pseudo-terminal device to receive these ioctl calls
and ask the remote box to change baud rates etc.?
If this is all possible, can I also create a bunch of pseudo-terminal
device nodes with custom names for this system (eg. while the daemon
processs is running)?
(Sigh.. I really wish I could stop the world for a year or two, so I could
take the time to learn kernel programming and a thousand other things...)
Thanks,
-jm
ITOH Yasufumi
jma...@pyy.jmp.fi writes:
> It seems I can set the speed for ttyp? with stty, but is it possible for
> the other end of the pseudo-terminal device to receive these ioctl calls
> and ask the remote box to change baud rates etc.?
I think pty "packet mode" is usable for this purpose.
See pty(4) and look at TIOCPKT ioctl.
I havn't use it, though. :)
--
ITOH, Yasufumi <it...@netbsd.org>
Jukka Marin
> > It seems I can set the speed for ttyp? with stty, but is it possible for
> > the other end of the pseudo-terminal device to receive these ioctl calls
> > and ask the remote box to change baud rates etc.?
>
> I think pty "packet mode" is usable for this purpose.
> See pty(4) and look at TIOCPKT ioctl.
Hmm yeah, sounds good. :-) Need to give it a try.
Now, if the daemon could create a set of its pseudo-terminals with well-
known names, I'd be happy as a .. a.. programmer who has found he doesn't
need to write a kernel driver for what he's doing ;-)
Thanks!
-jm
Jukka Marin
> > It seems I can set the speed for ttyp? with stty, but is it possible for
> > the other end of the pseudo-terminal device to receive these ioctl calls
> > and ask the remote box to change baud rates etc.?
>
> I think pty "packet mode" is usable for this purpose.
> See pty(4) and look at TIOCPKT ioctl.
I wrote a small test program and I can read data off the master end of the
pty, but I get no notification when the slave changes port speed or other
parameters. I guess I must be doing something wrong, but I don't know
what. The source is at http://www.jmp.fi/~jmarin/koe.c, if someone has
the time and will to take a look.. thanks ;)
-jm
Greg A. Woods
> Subject: pty and baud rate?
>
> I want to create a "driver" for a "terminal server" in NetBSD. This box
> has an Ethernet interface and 8 serial ports. Can I use pty's and a userland
> daemon or do I need to create a real kernel device? I want the device to
> be almost identical to real tty's (I want the speed, parity, etc. ioctl's
> to work so I can use "any" serial port aware software with this hack).
Which way do you want this "terminal server" to work? Do you want to
"dial" in to it, or do you want to telnet/whatever to it and "dial" out?
(or both?)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
Jukka Marin
> > I want to create a "driver" for a "terminal server" in NetBSD. This box
> > has an Ethernet interface and 8 serial ports. Can I use pty's and a userland
> > daemon or do I need to create a real kernel device? I want the device to
> > be almost identical to real tty's (I want the speed, parity, etc. ioctl's
> > to work so I can use "any" serial port aware software with this hack).
>
> Which way do you want this "terminal server" to work? Do you want to
> "dial" in to it, or do you want to telnet/whatever to it and "dial" out?
> (or both?)
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..)
-jm
Greg A. Woods
> 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....
ITOH Yasufumi
jma...@pyy.jmp.fi writes:
> I wrote a small test program and I can read data off the master end of the
> pty, but I get no notification when the slave changes port speed or other
> parameters. I guess I must be doing something wrong, but I don't know
By a look at sys/kern/tty_pty.c, the EXTPROC termios flag seems to be
required. Try
stty -f /dev/ttyqf extproc
Yeah, the user can drop the flag....
The master side should probably re-enaable the flag
when it detects that the flag was dropped.
--
ITOH, Yasufumi
Jukka Marin
> In article <2000072116...@pyy.jmp.fi>
> jma...@pyy.jmp.fi writes:
>
> > I wrote a small test program and I can read data off the master end of the
> > pty, but I get no notification when the slave changes port speed or other
> > parameters. I guess I must be doing something wrong, but I don't know
>
> By a look at sys/kern/tty_pty.c, the EXTPROC termios flag seems to be
> required. Try
>
> stty -f /dev/ttyqf extproc
Yes, this seems to help! Thanks :-)
> Yeah, the user can drop the flag....
> The master side should probably re-enaable the flag
> when it detects that the flag was dropped.
Probably..
Now the only thing that's bothering me is that I need to rm some real pty
device nodes and create some of my own with special names. It would be
better if I could create "dynamic" nodes when the daemon starts, but I
guess this is not possible (kernel seems to compare the minor number
againts a constant (I think :)). Well, good enough for testing how things
work.
Thanks to all who helped.
-jm
Jukka Marin
> 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