A 10-Minute Guide for Using PPP to Connect Linux to the Internet
Connecting your Linux machine to the Internet with PPP is easy in most situations. In this article I show you how to configure PPP for the most common type of connection. We assume your Linux machine is a stand-alone machine that dials into an Internet Service Provider and performs an automatic login, and the Internet Service Provider allocates the IP address that your machine will use. You can find details of how to configure PPP for other situations in the PPP-HOWTO by Robert Hart. You will need the right software and a couple of pieces of information before you start. Let's get started.
First, check that you have the right software. The program that manages PPP for Linux is called pppd. The pppd program is linked very tightly with the kernel, so you must run a version of pppd that matches your kernel.
Kernel Version pppd version 1.2.* 2.1.2d 1.3.0 -> 1.3.84 2.1.2d 1.3.84 -> 1.3.99 2.2.0f 2.0.* 2.2.0f 2.1.* 2.2.0f
Check the version of pppd and kernel that you have installed with the following commands:
$ /usr/sbin/pppd version $ uname -aThe first command is a trick. The pppd command doesn't actually have a version option. However, the version number will appear in the error message pppd returns, since you have supplied it with a bad argument.
If the first command fails, you probably don't have PPP installed. You can obtain the latest version of the source from:
If you have installed from a distribution such as Debian, Red Hat or Slackware, the pppd program is available precompiled within those distributions. You just have to get the package and install it.
Next you must check that your kernel has PPP support. Do this by giving the command:
$ dmesg | grep -i ppp
You should see the following messages:
PPP: version 2.2.0 (dynamic channel allocation) PPP Dynamic channel allocation code copyright 1995 Caldera, Inc. PPP line discipline registered.If not, PPP may have been installed as a module. Become root and try:
# insmod pppIf that fails, you will have to rebuild your kernel with PPP support. Follow the instructions in /usr/src/linux/README, and when configuring your kernel ensure that you answer “Yes” to:
General setup ---> [*] Networking support Network device support ---> [*] Network device support <*> PPP (point-to-point) supportThese prompts may be different in non-2.0 kernels.
Next you must note what keystrokes you will send and what prompts you will receive to log in to your ISP. The best way to collect these is to try manually logging into your ISP using a terminal program such as minicom. Be sure to make note of the capitalization of prompts such as the “login:” prompt as this will be important later.
A typical scenario follows:
Expect Send Comment ------ ---- ------- nothing AT&F/r (mode reset) OK AT&D2&C1/r (mode initialization) OK AT&D555-9999/r (modem dialing command)
The modem dials, sends CONNECT message and then you enter userid and password as follows:
login: username/r password: password/r
Lastly, you must know the IP address of a nameserver so that you can configure your name resolver and use host names instead of IP addresses. Get this information from your ISP.
The pppd program can accept configuration parameters from two places. The first is from the command line, and the second is from “options” files. The arguments supplied are close to identical in either case, but the command line method can be messy. So I will describe how to configure PPP using the options files instead.
The normal location of the options file is:
The options file is a simple text file containing parameters pppd will use when it is executed—one parameter per line. The options file must be readable by whoever will execute the pppd program. In most installations this will be root, either directly or by executing pppd from a program like sudo.
If you don't have an /etc/ppp directory, as root create one using the following commands:
# mkdir /etc/ppp # chown root:root /etc/ppp # chmod 755 /etc/ppp
Create an /etc/ppp/options file that looks like the following example:
debug /dev/ttyS0 38400 modem crtscts lock connect /etc/ppp/net-connect asyncmap 0 defaultroute :This example assumes:
You want PPP to give you diagnostic information as it runs.
Your modem is connected to serial device /dev/ttyS0.
You want the serial port speed to be set at 38400 bps.
You want to listen to the Data Carrier Detect signal.
You will use hardware (RTS/CTS) handshaking.
Your dialer program is /etc/ppp/net-connect.
You have a full 8 bit clean connection.
By default datagrams should be sent via the PPP link.
You want the PPP server that you call to assign the IP address you will use.
These are all fairly typical defaults for an ISP connection. You will have to adjust the serial device to suit where you have your modem connected and, if you are using data compression, you might want to set your serial port speed to something higher. PPP provides a means of escaping select characters, so that they do not interfere with your connection. For example, if you were running PPP over a link that would disconnect if it received a control-D character, you could ask PPP to escape that character, and it would automatically replace it with another and reverse the process at the other end. While the default is safe, it escapes a number of characters that normally don't need escaping and this will decrease the performance of your link. Since most ISPs provide 8 bit clean links you don't need to escape any characters, so we tell pppd not to, using the asyncmap option.
The pppd package includes a program called chat. The chat program is a simple program that can be used to automate the dialing procedure. The chat program also accepts arguments from the command line or from a file. Again I'll describe how to configure it from a file as this is the better method.
To make use of the chat program from within pppd, we must ensure that the connect option points to a script that calls chat. Create a script called /etc/ppp/net-connect that looks like:
#!/bin/sh /usr/sbin/chat -v -t 60 -f /etc/ppp/net-chat
This shell script will invoke the chat command with the -v, -t and -f arguments. The -v argument is useful when you are configuring pppd, as it sends verbose diagnostic messages to the system log to show you what is happening as the chat program runs. The -t 60 argument simply tells the chat program to wait 60 seconds for the expected text to arrive before timing out with an error. The -f argument tells chat the name of the file it should use to get the expect/send sequences it will use to login.
Make sure the script is readable and executable by whoever will invoke pppd. Assuming again that “whoever” is root, use the following commands:
# chmod 500 /etc/ppp/net-connect # chown root:root /etc/ppp/net-connect
Create a chat script called /etc/ppp/net-chat that will automate the login sequence as described earlier. I will base this script on the details presented in the table.
ABORT "BUSY" ABORT "NO CARRIER" "" AT&F\r OK AT&D2&C1\r OK ATD555-9999\r ogin: sword:The first two lines are special. The ABORT keyword is a special token that allows you to specify strings of characters that will cause the chat program to exit. In the example presented, if the chat program receives either the string "BUSY" or the string "NO CARRIER" then it will abort immediately. The rest of the file is a simple list of expect/send pairs, based on the information we gathered when we manually logged in. The above example reads in full:
ABORT the script if we receive "BUSY" or "NO CARRIER". Expect nothing, then send AT&F< carriage-return> to reset the modem to factory configuration, expect to receive OK then send AT&D2&C1<carriage-return>, then expect OK and send ATD555-9999<carriage-return>, then expect login: and send username<carriage-return>, then expect sword: and send password<carriage-return>, and then exit normally.
Finally, we must ensure this script is readable by whoever will invoke pppd. Again assuming that whoever is be root, you can use the following commands:
# chown root:root /etc/ppp/net-chat # chmod 600 /etc/ppp/net-chat
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Roll your own dynamic dns
3 hours 22 min ago
- Please correct the URL for Salt Stack's web site
6 hours 34 min ago
- Android is Linux -- why no better inter-operation
8 hours 49 min ago
- Connecting Android device to desktop Linux via USB
9 hours 18 min ago
- Find new cell phone and tablet pc
10 hours 16 min ago
11 hours 45 min ago
- Automatically updating Guest Additions
12 hours 53 min ago
- I like your topic on android
13 hours 40 min ago
- This is the easiest tutorial
20 hours 15 min ago
- Ahh, the Koolaid.
1 day 1 hour ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?