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 [1] 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.
3.
3. 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.
3.
3. 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.
3.
3. See what I mean? And we haven't even gotten the computer and modem talking yet!
3.
4. Select which getty program you'll be using. mingetty is only used for virtual terminals, but that still leaves:
4. * 4. * mgetty
4. * uugetty
4. * getty
4. * agetty
4. * mgetty

4. 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:
6.
6. * 6.
6. ```
6. TIMEOUT=60
6. INIT="" \d+++\dAT\r OK\r\n ATZ\r
6. WAITFOR=RING
6. CONNECT="" ATA\r CONNECT\s\A
6. DELAY=1
6.
6. ```
6.
6. 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.
6.
7. Next, add an entry to /etc/inittab for uugetty. What I have is:
7.
7. * 7.
7. ```
7.
7. S1:2345:respawn:/sbin/uugetty ttyS1 F57600
7.
7.
7. ```
7.
7. 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.
7.
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:
8. * 8.
8. ```
8. -pap
8. -chap
8. crtscts
8. deflate 15,15
8. bsdcomp 15,15
8. netmask 255.255.255.240 #replace with your netmask
8. 10.0.0.3:10.0.0.18 #replace with local IP, remote IP
8. modem
8. passive
8. -am
8. ipcp-accept-local
8. ipcp-accept-remote
8. mru 552
8. mtu 552
8. asyncmap 0
8.
8. ```
8.
8. 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:
8.
8. * 8. * 1. interface name
8. * 2. tty device
8. * 3. speed
8. * 4. local IP address
8. * 5. remote IP address
8. * 6. extra param—not sure what it's for

8. So in this file, I add some commands to get the routing done:
8.
8. * 8.
8. ```
8. /sbin/route add -net 208.26.72.16 netmask 255.255.255.240 dw $4
8. /sbin/route del $5
8.
8. ```
8.
8. You don't need the route for the one IP address so it can be removed safely.
8.
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>

[1] http://www.conman.org/people/myg/

Gemini Mention this post

Contact the author