Configuring pppd in Linux, Part II
In Part I of this article (see the February 2002 issue of LJ), I explained how to configure the modem. At the end of the article you ended up with a symbolic link called /dev/modem that pointed to the right device file for your modem. You were sure that everything worked fine, as you connected to your internet service provider (even though you didn't establish a PPP connection). In this article I go further, explaining how to connect to the Internet. You are advised to read the previous article first. If you can't, just make sure that your modem is configured correctly, and that you do have a symbolic link called /dev/modem that points to the right device file in /dev.
In order to make any use of this article you should have all the login information about your provider, including the phone number you should dial to connect, your login and password, and a valid DNS server address (this is optional, as it can be assigned automatically by your provider).
This article assumes that your provider accepts PAP authentication. PAP is a way of sending your login and password information to the provider through the PPP protocol; it saves the users from the more complicated (and often manual) login procedures required by some internet service providers in the past. The vast majority of ISPs today will require you to use PAP. This article also assumes that you have a standard modem and not a Winmodem. Configuring a Winmodem is possible but can be tedious and is outside the scope of this article.
First of all, you must be logged in as root to configure your internet connection. A connection to the Internet via the modem is established using PPP (point-to-point protocol), which is used to encapsulate common TCP/IP packets so that they can be sent through a serial line (in fact, TCP/IP packets are meant to be transmitted over a network medium and wouldn't fit, as they are on a serial connection without being serialized first).
This article assumes that you have the following software installed: the kernel module that handles the PPP connection (every distribution I know of comes with a kernel that includes the PPP module, so you probably don't need to worry about it); the program pppd, which initializes the kernel modules after establishing the connection; the program chat, which is responsible for establishing the connection; and the program minicom, a very simple terminal program that lets you talk to the modem. To check if you have all of these programs, you can use the which command. This command tells you if the programs are available in one of the directories listed in the $PATH environment variable:
which pppd /usr/bin/pppd which chat /usr/bin/chat which minicom /usr/bin/minicom
If you don't have some of these programs, you should grab the right package and install it. You also might want to disable the call waiting for your telephone line. If it is active, an incoming call could cause the line to drop while you are connected.
Once we configure the modem, how do we connect to the Internet? We have to use (and configure) a program called pppd (point-to-point protocol dæmon). The following is what happens when you run pppd (assuming that chat is used as the dialer program and that pppd is correctly configured).
The dæmon starts. It sets the serial port parameters (speed, etc.). Then it runs an external program (chat) to establish the connection, which sends the connection command to the modem (ATDT followed by the provider's number). Then it waits for the string CONNECT from the serial port. At that point the connection has been established, and it's as if there were a serial cable running from your computer to the provider's computer. Once chat has finished its job, the program pppd takes over again. If the connection could not be established, pppd will exit and return an error. Otherwise, it will talk to the PPP dæmon on the other side of the line (the PPP handshake that you saw earlier as a bunch of indecipherable symbols) and will be assigned an IP address. A login and a password normally are required to complete this stage successfully (login information is sent during the PPP handshake). The program pppd makes sure that a kernel network interface is created and that the network traffic is directed to it.
The two programs that you need, pppd and chat, are not interactive. They are run and then send any messages to the system log dæmon, syslogd. The syslogd will then write the received messages on the hard drive. There are several classes of messages, and the different classes usually are stored in separate files. The exact place they are stored depends on your syslogd configuration.
Now, you should configure syslogd so that you are 100% sure that the debugging information from the dæmons pppd and chat actually are stored on disk—and that you know where they are. The configuration file for syslogd is /etc/syslog.conf. All you have to do is enter one extra line to it. To do that, just type the command:
Of course, you may use any editor you like (vi, Emacs, joe, pico, etc.). Now, insert the following line:
daemon.debug;*.info /var/log/ppp_articleRemember that there should be a tab between info and /var/log/ppp_article.
Now, you have to make sure that the dæmon syslogd knows about the change in its configuration file. To achieve this, run the command:
killall -HUP syslogd
The file /var/log/ppp_article should have been created and should contain one line that tells you that syslogd has been restarted. To check that this is true, you can type the following command:
cat /var/log/ppp_article Aug 4 19:28:46 merc_linux syslogd 1.3-3: restart.Instead of the cat command, which just reads a file, you can use the command tail with the option -f. This will keep on reading a file and will print on the screen any new information added to it. This means that as soon as syslogd writes anything on the file ppp_article, tail will show it on the screen:
tail -f /var/log/ppp_article Aug 4 19:28:46 merc_linux syslogd 1.3-3: restart.From now on, any logging information recorded by pppd or chat will appear on the screen automatically. You really should keep this console open always, and check for messages whenever you need to.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
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?