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 18.104.22.168 Aug 4 16:12:23 merc_linux pppd: remote IP address 22.214.171.124If 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:
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|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|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
10 min 50 sec ago
- Reply to comment | Linux Journal
4 hours 10 min ago
- Yeah, user namespaces are
5 hours 26 min ago
- Cari Uang
8 hours 58 min ago
- user namespaces
11 hours 51 min ago
12 hours 17 min ago
- One advantage with VMs
14 hours 46 min ago
- about info
15 hours 19 min ago
15 hours 20 min ago
15 hours 21 min ago
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?