"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis, linux-questions-only@ssc.com
Starshine Technical Services, http://www.starshine.org/

Connecting a Dumb Terminal to your Linux System

From Mark Cohen on 07 May 1998

Jim,

My name is Mark, I met you at the balug meeting this week. I just wanted to shoot off a note to you about getting getty to work on my linux box (RH5.0) Im trying to connect my dumb terminal to it (pilot)

Any help would be greatly appreciated!

-Mark

The simplest method that I know of is to add a line like this to your /etc/inittab file:

t1:23:respawn:/sbin/agetty -L 38400,19200,9600,2400,1200 ttyS1 vt100

... assuming you have 'agetty', that you want to use a null modem on COM2 (use ttyS0 for COM1 etc), and that your communications package on the PalmPilot will do vt100 emulation).

If you don't have a copy of 'agetty' you can use a line like:

t1:2345:respawn:/sbin/getty ttyS2 DT38400 vt100

... assuming you have a reasonable /etc/gettydefs (like the default one that used to come with Red Hat 4.x --- and is probably unchanged in newer releases). I won't go into the details about how the gettydefs file is constructed, let's suffice it to say that the syntax was "baroque".

It's undoubtedly possible to use uugetty and getty_ps with these as well --- though I haven't ever bothered with those packages. It should also be possible to use mgetty (which I use for modem dial-in lines and incoming fax support). However that doesn't seem to work even when I use the -r switch as specified in the manual.

Definitely don't try this with mingetty --- that is designed purely for use with virtual consoles.

In any event, these examples use "t1" as the inittab entry "id" and I have them enabled at different runlevels (since these examples are from different machines on my network). Read the inittab(5) man page for details about what the fields mean.

After you've edited this file simply issue the command:

'telinit q'

... to "tell init" to re-read it's configuration file and implement your changes. In a few seconds you should be able to login on that line (you might have to hit [Enter] a couple of times to get a login prompt).

If you don't get a login prompt, or you see a console message like: "respawning too fast.... disabled for five minutes" (check your /var/log/messages file for this and similar errors from init and/or from any 'getty' that you happen to be using), you should double-check the syntax of your entry, double-check which serial port you're plugged into (remember Linux' numbering of serial and printer ports sometimes doesn't correspond to DOS/BIOS extensions --- some crufty hardware may cause confusion), and check for IRQ conflicts and cabling errors.

If you still have problems with it after you've double and triple checked every detail than you have some troubleshooting choices:

• buy a cheap "breakout" box and watch how the LED's respond to your software activity.
• connect another system, even a DOS laptop and run C-Kermit or Telix or whatever you like in "host mode" and try to access that port from the other direction.
• connect a normal external modem to the box and see if you can connect and so simple AT commands to it.

In any of these cases you can play with a wide variety of 'setserial' and 'stty' commands to try and get the serial port to respond and/or behave properly. Before you spend too long with those, however, I have to say that the times when I've resorted to them as part of my troubleshooting have consistently been fixed by untangling an IRQ conflict or replacing a bad serial port (usually a whole multi-function controller, actually).

I personally have given up on the cheap $15 IDE/floppy/serial cards and I pay a bit extra for the QuickPath "FlexPort" cards (which usually come in at close to $100 US). Serial ports are hard enough to deal with without having flaky hardware underneath it. (Luckily most of the modern motherboard that have built-in serial ports have stopped putting in really cheap ones --- but it used to be that they were often junk and sometimes could not be disabled --- even if they had jumpers that purported to do so).

Anyway, good luck.

Personally I usually configure a "dumb terminal" port for all of my Linux boxes (eventually). This serves two important purposes: It is the most convenient way for me to get files to and from my laptop (for which I don't have a supported ethernet card). More importantly it gives me an extra troubleshooting option if my system "seems" hung. I can just plug in the old null modem and give it a go.

It can mean the difference between a clean shutdown and a game of "red-switch" roulette.

(Although it hasn't happened for any of my systems in so long I've almost given up on seeing it at all --- but it used to be possible for the Linux console driver be completely unresponsive, and even for the network subsystem to be dead while the serial lines were still accessible. However, if you don't configure the terminal line in advance you don't have the option when you want it).

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 29 June 1998

	versions	lilo	virtdom	kernel	winmodem	basicmail	betterbak
	shadow	dell	dumbterm	whylinux	redhat	netcard	macrovir
	newlook	tacacs	sendmail	dialdppp	ppp233	msmail	procmail