Configuring pppd in Linux, Part I
Connecting to the Internet may be easier than you think; Tony begins this two-part series with how to configure your modem.
by Tony Mobily
Today, many people install Linux on their desktop computers. Unfortunately, quite a few people seem to get stuck as soon as they try to do the one thing that apparently no one is ready to give up: connecting to the Internet. Why do they get stuck? There are several reasons, but the main one is that there is no official equivalent of Windows' “remote access” or Mac's ConfigPPP. As a result, many users end up having some similar programs available on their system (GNOME dial-up, Linuxconf, KDE dialer, etc.) without knowing anything about them.
It is also quite possible that no automatic configuration program is available (for example, if the user chose not to install either GNOME nor KDE when he or she installed the system). So why not take on the challenge of learning how to establish an internet connection by hand? This article explains how to set up a modem on your Linux system—a crucial step that many users seem to have trouble with. In the next article I will talk about how to configure pppd itself, assuming that the modem is configured correctly.
To get the most out of this article you should first be fairly familiar with the basics of using the shell (how to change directory, list the files in a directory, etc.), editing a file using any editor, running a program and using virtual consoles or several terminals in the X Window System.
This article will assume that you have a real modem, not a Winmodem. Configuring a Winmodem is possible but can be tedious and is outside the scope of this article.
The first thing you have to do is know where your modem is. What we are looking for is the serial port to which the modem is connected. This is true even if you are using an internal modem, as the modem card itself will contain a serial port. Your computer is likely to have two serial ports. Quite possibly, one is being used by your mouse (unless you have a PS/2 or USB mouse). In UNIX, every device is represented as a file in the directory /dev. This directory contains an entry for every device you possibly could have installed on your computer. The serial ports are called ttyS, followed by a number between 0 and 3. Let's have a look:
cd dev ls -l ttyS* crw------- 1 merc tty 4, 64 Aug 3 10:24 ttyS0 crwxr-xr-x 1 root tty 4, 65 Aug 3 10:25 ttyS1 crw------- 1 root tty 4, 66 May 6 1998 ttyS2 crw------- 1 root tty 4, 67 May 6 1998 ttyS3
Which is the one the modem is connected to? The answer is, it depends on where you plugged in your modem (or, if you have an internal modem, it depends on how it is configured). If you are used to calling serial ports COM1, COM2 and so on, you should know that the equivalents here are COM1 = ttyS0, COM2 = ttyS1, COM3 = ttyS2 and COM4 = ttyS3. And, if you don't know which serial port your modem is plugged into (or configured for) don't worry, because we will find that out in a little while.
Usually, there is a symbolic link (that is more or less the equivalent of a Windows shortcut) called “modem” that points to one of the serial ports. For example, on my system I have:
ls -l modem lrwxrwxrwx 1 root root 5 Feb 7 2000 modem -> ttyS1
In my case the modem is connected to the second serial port, ttyS1 (the symbolic link you can see above basically means that any program that uses the file /dev/modem is actually dealing with /dev/ttyS1).
Please remember that your system might be different, and you might not have a symbolic link that points to ttyS1 or ttyS0. In fact, the goal of this section is to have a symbolic link in /dev called modem that points to the right serial port (that is, the one your modem is connected to).
First we are going to determine to which serial port your modem is connected. Type the command minicom. To see if minicom is already talking to your modem, just type at and press Enter. If you see an “OK” response, minicom is using the right file in /dev to access the modem. Otherwise, for some reason minicom was unable to talk to the modem.
If there was no OK response from the modem, the first thing to do is to find out where the modem is (that is, to which serial port the modem is connected). This is done easily from minicom: press Ctrl-A and then O. Please note that sometimes minicom is configured so that it uses the Alt key. If that is the case, you should remember that every time I write Ctrl-key, you should press Alt-key (e.g., instead of Ctrl-A and then O, you should press Alt and then O).
The minicom configuration screen will pop up. Select “Serial port setup” and press Enter. Now, press A and choose a different serial port. For example if the current port is /dev/ttyS0, change it into /dev/ttyS1 (Figure 1). You will now have to exit minicom and run it again. Press Enter and select “Save default as dfl”. Then select “Exit” (you will exit the configuration screen) and quit minicom (Ctrl-A and then Q).
Now, run it again. minicom will talk to the serial port you chose. Type at and press Enter. If you receive an OK as a response, you have found the modem (see Figure 2). Otherwise, you will have to repeat the steps outlined in this section until you find the serial port (that is, when you receive an OK response from the modem when you type at after running minicom). Please remember that normal debugging procedures should be followed when you try to figure out where your modem is. In particular, make sure your modem is switched on, is connected to the computer, is using the right power supply and that its connection with the computer is firm.
They seem to be trivial checks, but it is because of their triviality that they are often ignored. As a result, you can spend hours trying to configure a modem that actually is not connected or switched on.
If there is an OK response from the modem, everything is working, and it's only a matter of sorting a few things out. From minicom, press Ctrl-A and then O. The minicom configuration screen will pop up. Select “Serial port setup” and press Enter.
On the first line, you will be able to see what file minicom is using to communicate to the modem. If it is /dev/modem, everything is configured properly on your system, and you can skip to the next section of this article (“Talking to the Modem”).
If you received the OK response, but minicom is configured to use a different port (such as /dev/ttyS0), then you have to create a symbolic link called modem in /dev in order to make sure you have a working /dev/modem entry in your system (remember, this was the primary goal of this section). Write down which port minicom actually is using (let's suppose it is /dev/ttyS0). Quit the configuration screen (pressing Enter and selecting “Exit”), and quit minicom (by pressing Ctrl-A and then Q). Now you are back to your shell. Go into the /dev directory and create the symbolic link for “modem” like this:
cd /dev ln -sf ttyS0 modem ls -l modem lrwxrwxrwx 1 root root 5 Aug 3 12:32 modem -> ttyS0
Of course, you will have to substitute ttyS0 with the port you found in the minicom configuration screen.
Now, run minicom again. Make sure everything still works by typing at and pressing Enter. You should receive the reassuring OK response (see Figure 2). Go to the minicom configuration screen again (Ctrl-A and O) and select “Serial port setup”. Now change the default device by pressing A and substituting /dev/ttyS0 with /dev/modem (see Figure 1). Press Enter, then “Save setup as dfl” and select “Exit” to exit the configuration screen. In order to have minicom work with the new configuration you have to exit minicom (Ctrl-A and Q) and run it again.
Now minicom is using the device /dev/modem. Type at. You should receive an OK response (see Figure 2). If that is the case, congratulations!
Configuring the modem is the most critical step when you try to connect to the Internet. Many users do not know to which serial port their modem is connected. As shown in the previous section, it is clear that the modem was already configured; you only had to find out where it was and create a symbolic link in /dev that pointed to the right device file.
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
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
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