Configuring pppd in Linux, Part II
As you probably saw in Part I of this article, in order to establish the serial connection, you have to send the string ATDT12345678 (with your provider's phone number, of course) to your modem and wait for the string CONNECT to come back from the modem itself (that would happen once the connection has established). Some messages other than CONNECT might be returned: BUSY, NO CARRIER, NO ANSWER, etc. In the previous article, you tried this practically, using minicom.
Even though you could do all of this by hand using minicom, you might want to use a program that does it all for you. The program should be able to talk to the modem, sending information and expecting a particular string as a response. Of course, such a program does exist, and it's called chat. For example, try to run the following command:
chat ABORT "BUSY" "OK" "TRY" "THIS" "TESTING" "COMMAND"
Be careful, because from now on the keyboard will be locked and you won't be able to quit the program, not even by pressing Ctrl-C. Type ok. The word TRY will pop out. Now type this; the word TESTING will appear on the screen. Finally, type command; the program chat will exit successfully. Try to run the command again: type ok, and again you will see the string TRY come out. At this point, type busy: the program will exit immediately. As you can guess, the chat program is designed to wait for a string and print something as a response. The first two words, ABORT BUSY, are special and instruct chat to exit if the word BUSY is received at any point during its execution. If something goes wrong, you can run the same chat command adding the switch -v:
chat -v ABORT "BUSY" "OK" "TRY" "THIS" "TESTING" "COMMAND"The -v option stands for verbose, meaning that chat will tell you exactly what is going on, what it is expecting and so on. Of course, all the debug information will be recorded in /var/log/ppp_article if you followed the instructions I gave you earlier about syslogd. Let's analyze a different chat command:
chat ABORT "BUSY" "" "AT" "OK" "ATDT93355100" "CONNECT"As you can probably guess, you will have to behave like a modem in order to get chat to exit successfully. It will send you an AT string, and you have to type ok. Then, it will send you the string ATDT93355100 and wait until you type connect. Then, it will exit. This probably sounds familiar to most readers; this is exactly what you need to connect to your ISP, if you could get chat to talk to the modem and not the keyboard. The command I use for my provider is:
chat ABORT BUSY ABORT "NO CARRIER" TIMEOUT 120 "" AT OK ATDT94310999 CONNECTIt's very simplistic, and as a matter of fact, it could be done a lot better. But in my case, it does the job and I am perfectly happy with it. You should have a look at the man page for chat (just type man chat) and look at the options it offers; later, you might want to change your connection script so that it uses all of the fancy options offered by chat. The next step is to write a shell script that encapsulates the chat command you wrote. The file will be placed in /etc/ppp and will be called chat-connect. To create it, just type the command:
vi /etc/ppp/chat-connect(of course, you can use any editor you like if you don't like vi). The script should look like this:
#!/bin/sh chat ABORT BUSY ABORT "NO CARRIER" TIMEOUT 120 "" AT OK ATDT94310999 CONNECTYou should substitute 94310999 with your ISP's dial-up number. Now, save and exit the editor. You need to make the script executable, with the chmod command:
chmod +x /etc/ppp/chat-connectSee if the script works by running
/etc/ppp/chat-connectIf it works, you moved one step toward your working internet connection. Effectively, you are very close to the goal. All you have to do is run pppd with the right parameters.
At this point you can start to work on the actual pppd configuration. The files involved are /etc/ppp/options, /etc/ppp/chap-secrets, /etc/ppp/pap-secrets and /etc/ppp/peers.
The options file is used to give pppd a list of default options. For now you should make sure that the options file, stored in /etc/ppp, is totally empty; just edit it with your favorite editor and delete everything in it. If you don't feel comfortable deleting the content, you can comment all the lines out putting a # symbol in front of each line. It is important to have the options file empty to make sure you have a fresh start. The first thing now is to test if the chat script we wrote works in a real situation. In order to do that, you can run pppd with the minimum number of parameters:
pppd /dev/modem 38400 modem lock connect /etc/ppp/chat-connect
The parameters can be given to pppd in any order. The /dev/modem option represents the serial port that the modem is connected to (as you know, it is a symbolic link that points to the real ttyS device). The parameter modem instructs the pppd dæmon that it will be dealing with a modem connection, and not a straight serial cable between you and your provider. The word lock tells pppd to lock the modem while using it (if you don't know what that means, don't panic; basically it's a way of guaranteeing that no other program will be accessing the modem while your connection is up). The last option, connect, comes with the parameter /etc/ppp/chat-connect and tells pppd what program it should run to dial the number and connect to the internet service provider; in your case, it's the chat script you wrote in the previous section of the article.
If nothing seems to work, you should add the option -v to the chat script, try again and look at the logs—at this point, it's normally quite easy to fix problems. If everything goes well, you should be able to see your modem connecting and hear it going through the usual whistling noises. Now you should be able to connect to the Internet with only one extra step. Edit the file /etc/pap-secrets and add your password to that file, adding a line that looks like this:
your_username_here * your_password_here
Remember that there should be a tab between each word. Now you are ready for the big test, an actual connection. Try the following command:
pppd /dev/modem 38400 modem lock connect /etc/ppp/chat-connect user your_username_here defaultrouteThe only extra parameters are user (followed by your user name as it comes in /etc/ppp/pap-secrets) and the option defaultroute. This last option makes sure that your connection will be used by default by the packets that are supposed to reach the Internet. With this option, pppd will set up the correct routing table once the connection is established. You should see, in the log, a message like this:
Aug 4 16:12:23 merc_linux pppd: local IP address 126.96.36.199 Aug 4 16:12:23 merc_linux pppd: remote IP address 188.8.131.52If it didn't happen, you might have to run pppd with the debug option and read the log file (that is /var/log/ppp_article) to see what happened:
pppd /dev/modem 38400 modem lock connect /etc/ppp/chat-connect user your_username_here defaultroute debugIf everything worked, congratulations; you are now connected to the Internet. Remember that when you want to disconnect, you simply can type:
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
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
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