And it's one of the reasons I haven't bother to set up printer support under Linux (or Unix in general). Unix weenies chant “Simple. Simple. Simple,” but what they do is “Complex. Complex. Incomprehensible.” I'll take the case of modems under Linux, since I have more than my share of experience with what normally should be rather simple and painless.
Situation: Hook two Linux systems together via modem. Mark and I have done this several times over the years and every time it takes several hours to get it working. The first time it took like 16 hours, but that's because we wasted 12 hours on a core-dumping uugetty (that we didn't know was dumping core).
- Plug modem into computer. Even if it's an internal modem and you have
to open the system and shove a card in, this is the simple step. But
because of the PC hardware you have to make sure you don't have IRQ
conflicts, but let's assume you don't. Plug the modem in.
- Figure out which port the modem is plugged into. Again, this should be
simple and in fact, these two steps are the same reguardless if you are
using MS-DOS, Windows, or Linux.
- Now figure out if you need to use /dev/cua* or
/dev/ttyS*, but it depends upon the Linux kernel you are using.
One if for dialing in, one for dialing out, but in a pinch I think you can
use either as long as you don't try to have one program answering the phone
and another one trying to make an outgoing call.
For you see, while both /dev/cua* and /dev/ttyS* use the same driver, they have slightly different semantics when opening them up for use and I can never rember what those semantics are (but hey, this is Linux, I can check the source code) or which device is for dialing in or dialing out.
But the newer Linux kernels (starting with 2.0? 2.2?) have removed that annoying aspect, thus annoying a bunch of package maintainers who content that Linux was doing the Right Thing and this new way of doing things is the Wrong Way.
See what I mean? And we haven't even gotten the computer and modem talking yet!
- Select which getty program you'll be using. mingetty
is only used for virtual terminals, but that still leaves:
- Figure out what configuration file it wants. Usually you think the
man page would tell you, but I've found that it's best to grep
through the executable for potential configuration file names.
- Write the configuration file. Since we're using Hayes compatible
modems, the following configuration file for uugetty seems to work:
TIMEOUT=60 INIT="" \d+++\dAT\r OK\r\n ATZ\r WAITFOR=RING CONNECT="" ATA\r CONNECT\s\A DELAY=1
- Next, add an entry to /etc/inittab for uugetty. What
I have is:
S1:2345:respawn:/sbin/uugetty ttyS1 F57600
The first paramter to uugetty is what device entry to use, minus the /dev part. The second is an entry out of /etc/gettydefs—don't edit this file! For a modem you pretty much want a fixed-baud modem entry, one that is faster than your modem supports since most modems these days can do on the fly compression.
- Next, you need to configure the PPP daemon. Under Linux the
file you want to edit is /etc/ppp/options. There are a slew of
options to configure and through plug-n-pray, Mark and I got the following
-pap -chap crtscts deflate 15,15 bsdcomp 15,15 netmask 255.255.255.240 #replace with your netmask 10.0.0.3:10.0.0.18 #replace with local IP, remote IP modem passive -am ipcp-accept-local ipcp-accept-remote mru 552 mtu 552 asyncmap 0
- interface name
- tty device
- local IP address
- remote IP address
- extra param—not sure what it's for
/sbin/route add -net 18.104.22.168 netmask 255.255.255.240 dw $4 /sbin/route del $5
- Add a user to the passwd file who has a shell of /usr/sbin/pppd so the other side can log in and establish a PPP connection.
Oh, I forgot to mention, that's only for one half the connection—the one that is accepting incoming calls. Doing the other side is similar but I think I got my point across—this is insane.
Now, for a printer …