The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Wednesday, April 12, 2000

So you wanna add a modem to Linux?

Friends that know me know that I tend to get very frustrated when things I think should be simple, or at least straight forward, aren't. This is especially noticible with respect to computers.

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

  1. 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.
  2. 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.
  3. 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!

  4. Select which getty program you'll be using. mingetty is only used for virtual terminals, but that still leaves:
    • mgetty
    • uugetty
    • getty
    • agetty
    • mgetty
    Don't worry, they're all equally bad. We always ended up using uugetty.
  5. 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.
  6. Write the configuration file. Since we're using Hayes compatible modems, the following configuration file for uugetty seems to work:

    INIT="" \d+++\dAT\r OK\r\n ATZ\r

    The INIT and CONNECT lines are commonly called “chat scripts.” The format is a series of pairs, one string for what to expect as input, the next what to send for output. Notice that if something unexpected comes up you can't do anything about it. Or maybe you can. Best to check the source code.

  7. 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/gettydefsdon'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.

  8. 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 working:
    deflate 15,15
    bsdcomp 15,15
    netmask		#replace with your netmask	#replace with local IP, remote IP
    mru	552
    mtu	552
    asyncmap 0

    You also need to configure /etc/ppp/ip-up.local with the appropriate routing information. This is a shell script, not a configuration file. Through experimentation, I've found that the shell script has the following parameters:

    1. interface name
    2. tty device
    3. speed
    4. local IP address
    5. remote IP address
    6. extra param—not sure what it's for

    So in this file, I add some commands to get the routing done:

    /sbin/route add -net netmask dw $4
    /sbin/route del $5

    You don't need the route for the one IP address so it can be removed safely.

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

And you're done.

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 …/p>

Obligatory Picture

[“I am NOT a number, I am … a Q-CODE!”]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.