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
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- LiveCode Ltd.'s LiveCode
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide