On Tue, 29 May 2007, Maurice Janssen wrote:
> Hi,
>
> I'm trying to use a VT420 serial terminal on an i386 box running
> 4.1-stable. Not as a system console, just as an extra screen to login.
> The output of the boot loader and kernel output should go to the
> monitor, as usual.
>
> The terminal is hooked up to the first serial port with a null modem
> cable. I changed the tty00 line of /etc/ttys to:
> tty00 "/usr/libexec/getty std.9600" vt220 on secure
> and sent -HUP to init. There's a getty process on tty00, but there's
> no login: prompt on the terminal. Everything I type on the terminal is
> echoed on the screen, so the cable is OK (local echo is off).
HMMMM. Look into two things, no, make that three:
1) The settings on the terminal, whether XON/XOFF or RTS/CTS
synchronization is selected, also baud rate, parity, 8/7 bits. Try
8 bits, No parity, 1 stop bit ("8N1").
2) The settings on the tty, from # stty -a /dev/tty00 when
the getty is running.
3) There are null modem cables, and there are null modem
cables. Some are just plain junk, providing only cross over of the
two data pins and if you're lucky, a ground. Others implement
various ideas of what a null modem cable should be; the opinions
of what a null modem cable differed between Digital, who made your
terminal and IBM, who designed the PeeCee.
> The funny thing is, when I start 'tip tty00' on the machine (while
> logged in at the keyboard+monitor), the login: prompt appears on the
> terminal.
Yeah, this is weird. You should be able to get the login: prompt
by at most hitting the carriage return on the 420 twice. Try to
set up everything for XON/XOFF flow control.
> When I quit tip, I can login at the terminal. When I logout from the
> terminal, the login: prompt doesn't appear (but everything I type is
> echoed to the terminal screen as before). I can start tip again, and
> then the login: prompt shows up again.
>
> I suspected a problem with the permissions of the tty00 device. After
> logout, they are set to
> crw------- 1 root wheel 8, 0 May 29 21:44 tty00
This, by default, should be uucp.dialer, permissions crw-rw---,
when "at rest". When a getty is running, it should be as shown here.
> When logged in it is set to
> crw------- 1 maurice tty 8, 0 May 29 22:00 tty00
> Not sure if this is what it should be, but it doesn't look strange to
> me.
>
> BTW: not sure if it is related, but when I login as normal user, the
> following warning is shown on the terminal:
> ksh: No controlling tty (open /dev/tty: Device busy)
> ksh: warning: won't have full job control
> When I login as root, I don't get this warning.
Ick. I have my suspicions, but won't voice them since they are
superstitious. They involve a brief trip to single-user mode and
running cd /dev; sh MAKEDEV all.
> Any ideas what's going wrong?
Yeah, you're using a serial terminal on a PeeCee. (sarcasm).
You are in a maze of twisty little passages, all alike. The
lamp grows dimmer. (Zork, a metaphor for debugging RS-232).
Install a terminal emulator on the box, like kermit or something
like minicom, from ports if the sometimes goofy behavior of tip/cu
annoys you (like killing its parent xterm when you give it ~.).
Hook up the terminal. See what you can do. Try things (settings).
Terminals are a PITA, as bad as serial printers. See if the 420
has a VT-220 emulation mode, if so try it. It's hard to debug them
"over the phone" (by email) like this, one needs to poke and try.
A RS232 line analyzer is real handy. There used to be various
utilities for MS-DOS that would display line status of the com ports
on the screen, much like the blinkenlights on a modem. Don't know
it they exist for Unix. Could kermit have such a feature? One has
to delve into the kernel to see these things, a forbidden zone in
Unix, unless some happy ioctl to pccom exists.
Helpful man pages: tty, tip, remote, cu, getty, gettytab, pccom
With the getty killed, try catting a "large" text file to
/dev/tty00 (as root), look for garbage on the terminal, a sign
of flow control being wrong. Try this with the terminal set
for "smooth scrolling".
A debugging test: use the same cable (if you can) and connect
the com ports of two OpenBSD boxes. Start the getty on one, and
use tip/cu/minicom/kermit on the other. Everything should work
fine. If it doesn't, the cable sucks in some way. If it doesn't
work, force XON/XOFF on both boxes. How you do this for getty is
a good question, settings in gettytab is the answer.
Dave "I already have a headache, and it's not my problem!"
