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.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- 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