* * * * *

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

    -----[ data ]-----
    TIMEOUT=60
    INIT="" \d+++\dAT\r OK\r\n ATZ\r
    WAITFOR=RING
    CONNECT="" ATA\r CONNECT\s\A
    DELAY=1
    -----[ END OF LINE ]-----

 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.

 7. Next, add an entry to /etc/inittab for uugetty. What I have is:


    S1:2345:respawn:/sbin/uugetty ttyS1 F57600


 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.

 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:

    -----[ data ]-----
    -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
    -----[ END OF LINE ]-----

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

    -----[ shell ]-----
    /sbin/route add -net 208.26.72.16 netmask 255.255.255.240 dw $4
    /sbin/route del $5
    -----[ END OF LINE ]-----

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

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

Email author at [email protected]

You are viewing proxied material from gopher.conman.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.