In days of old (or so it seems), before cable modems and ADSL, people connected
to the Internet over modems. The most popular way to do that was to use a
protocol called "PPP", or the Point to Point Protocol. PPP encapsulates your
packets over a serial line (i.e. a telephone line) so that they can travel from
you to your ISP over the telephone company's voice network.
Setting up
Linux for PPP is surprisingly easy. The main component is "pppd", the PPP
daemon. Generally, any program that ends in 'd' is a daemon, a program that runs
silently in the background performing a task. Other examples are xinetd, sshd,
in.telnetd, ftpd, and httpd. pppd can also call external programs to help you
set up the connection, such as to dial the modem. Some ISPs require you to log
in through a text interface, some use ppp's natural authentication mechanisms.
"chat" is the component that takes you from modem dial to the PPP protocol.
Configuration for pppd generally lives in /etc/ppp. You'll see a few
files in there already, but don't worry about them. The first thing to do is
create our chat script, which will take care of dialing my ISP. Chat scripts, in
their simplest form, are a series of "When I get this, do that" commands. So, I
created /etc/ppp/chat-test as follows:
ABORT "NO CARRIER" ABORT "NO
DIALTONE" ABORT "ERROR" ABORT "NO ANSWER" ABORT "BUSY" "" "at"
OK "at&d0&c1" OK "atdt5551111" CONNECT ""
The first
five lines are things to look for that will cause the script to abort, rather
than complete successfully. Since "ABORT" is on the left, it just tells chat
that if this ever comes up, to abort. If the line is busy, I don't want PPP to
try to authenticate to nothing, do I? After that, it's your basic modem
commands. I wait for nothing, and send "at". From that, I should get "OK", at
which point I send my initialization string. "OK" follows, I dial the modem, and
I'm done when I see "CONNECT". This implies that I'm going to rely on PPP's
authentication method, which is PAP or CHAP.
PAP and CHAP are
authentication protocols (the AP part), and are either plain passwords, or
challenge-handshake (take a guess which is which). PAP passwords pass in
cleartext, CHAP in encrypted format. Normally this is something to be concerned
about, but since the password travels over the phone line, I'm not too concerned
about which I choose. Setting them up is the same.
/etc/ppp/pap-secrets
and /etc/ppp/chap-secrets hold the authentication tokens (ie
username/passwords). Since pppd can be both a client and a server, and you can
connect to multiple servers, all the secrets (passwords) are stored in the same
place. The format for dialin users is simply:
username * password
*
If you knew the name of the remote server, you could put it in place of
the first star, but in most cases, this is all you'll ever have.
So far,
we've got a chat script to connect us to the ISP, and our username/password is
taken care of. All that remains is the configuration of pppd itself.
There are several ways you can invoke pppd. We're going to set up a
peer, and direct pppd to call the peer. We could also set up a global
configuration, or even one specific to the modem. The peer way lets us keep our
ISP's configuration separate from anything else, such as other ISPs or your
PPPoE connection on ADSL.
/etc/ppp/peers is a directory containing your
peer configurations. The configuration files for pppd are a series of keywords
followed by an option. Order doesn't matter at all. I created a file called
"test", to refer to my "test" ISP:
ttyS2 38400 crtscts connect
'/usr/sbin/chat -v -f /etc/ppp/chat-test' noauth user sean
defaultroute
The first line tells pppd what my modem is, and what
options to use. Here, I have ttyS2 (AKA COM3), a locked port speed of 38400, and
hardware flow control (crtscts). The second line tells pppd to use chat to do
the connection, and I'm passing the name of the script. -v is "verbose", a good
idea to have set the first few times you connect. noauth isn't what you think it
might be, it says that you aren't requiring that the remote end authenticate
itself to you. However, the remote end will almost certainly want you to
authenticate itself to it, something that we already covered in pap-secrets.
"user sean" simply says that pppd is to present the credentials for sean
(from either pap-secrets or chap-secrets), and nothing else. defaultroute means
that pppd will install a default route to the other end. Since it's likely that
we'll be using this line to connect to the Internet, a default route is a good
thing. If you were connecting to a remote LAN, you would likely...
You must be logged in to view this entire article. Click Here to Finish Reading this Article
FREE subscription to Network World.
Your complimentary subscription will include 50 weekly issues jam packed with news analysis, expert industry opinion and management/career advice, all of which is packaged with your business needs in mind. We want to help you connect the technology dots and help you advance your company's business goals.
Email this Article
Print this Article
