"The Linux Gazette...making Linux just a little more fun!"

(?) The Answer Guy (!)


By James T. Dennis, tag@lists.linuxgazette.net
LinuxCare, https://www.linuxcare.com/

(?) Getting Access to the Internet

From albuquerque on Tue, 31 Aug 1999

Hope you can help me. I have a DELL I7K laptop running WIN98 and Linux RH6.0.

Linux seems to be running fine, have GNOME as my window stuff, I can access the PCMCIA card and use a SYQUEST SCSI drive.

Now I'd like to use Linux to access the Internet!!!!!!!!!!!!!

I have read most or many How TO s etc. and keep getting lost in the forest.

(!) That's a common problem. The answer will be a rather lengthy one. To answer this question I'll have to start with a view from "ten thousand feet" and then swoop down for a closer look at some details.
As with the answers to many questions about Linux quite a bit of my response will be qualified with: "It depends..."
Since Linux, and UNIX are written following a "toolbox" model it provides us with tools to apply to the whole class of problems. We have to know how to use those tools to fashion our own solution.
In the case of connecting to the Internet most of the "It depends" clauses are followed by the phrase "...on your ISP." Other things depend on your hardware, your distribution, and even on your personal preferences.

(?) Problem? What are the steps need to get on the Internet. (RH says use Linuxcfg's special command - which I can't find.) What is need to set up the Modem; What is needed to set up the DNS numbers(like Win98); What is needed to set up E-Mail; Where is the "Dialer"?

(!) I think Red Hat recommends the use of the linuxconf package. I don't know what Linuxcfg would be, or what sort of "special commands" it might offer.
(I suspect that you have simply mangled the name of the package and haven't referred to HOWTOs in the conventional way. These may seem like nitpicks. However attention to details of this sort, linuxconf vs. Linuxcfg and HOWTOs vs. "How TO s" is actually quite important in using most operating systems, particularly in using any UNIX like system).
So, your questions were:
That looks like five questions. It could also be considered as one broad question for which you've provided four specifications to clarify what you mean by "get on the Internet". I'll revisit each of these questions, with answers, below.
However, first I'll comment on some of the overall problems that lead to these sorts of questions. The first thought might be to say: "Linux is too hard to use." Getting on the Internet is one of the most common operations for PCs these days so it SHOULD be easy and straightforward.
Indeed it could be. If we were buying our computers with appropriate modems included and with Linux pre-installed and pre-configured for our modems AND if we were subscribing to ISPs who catered specifically to the particular Linux distribution that our hardware vendor was providing. If we didn't have so many choices --- then connecting to the Internet would be pretty easy.
Let's compare this to the typical experience of Window '98 user buying a new system and accepting whatever options are presented "up front" in that process. They buy a system with a cheesy little winmodem pre-installed. It includes icons to access MSN (the Microsoft Network) and possibly AOL. These are already on the desktop.
Under those circumstances (and the similar ones which predominate the experience of new Mac users) it is pretty easy to "get on the Internet." We'll ignore the trifling argument that being on MSN or AOL might not quite be the same as "being on the Internet." That's a matter of personal bias.
That process is easy. It sometimes isn't reliable. It certainly isn't flexible and may not be economical nor convenient (you have to put up with quite a bit of advertising if you subscribe to either of these "loss leader" ISPs). When things don't work right you are up against an unyielding brick wall. Lost in all that "ease of use" is any control over the underlying mechanics (much like the situation under the hood of most modern vehicles --- somewhere deeply wedged under all those proprietary electronics is your basic internal combustion, gasoline driven piston engine).
Things get very interesting if you want to have choices; to do things your own way. Linux is very much about "doing things your way." This is a facet of it that comes with quite a cost. It requires quite a time commitment to climb the Linux learning curve.
To complicate issues more every distribution starts out with a set of assumptions how things "should" be done. For example RedHat 6.0 includes 'linuxconf' --- and Red Hat Inc is encouraging people to use it.
Personally I don't like Linuxconf (nitpick, linuxconf is the command, Linuxconf is the subsystem which includes the command, some libraries, help files, an API and some other stuff). What I want from a system configuration management tool is much more focused than Linuxconf is written to provide.
The biggest difference between configuring UNIX-like systems and managing the configuration of NT, Win '9x, MacOS, and other proprietary systems, is that UNIX (and Linux) use text files to store almost all configuration data.
The Microsoft operating systems use a "Registry" (which represents a giant single point of failure as well as a key, performance limiting lock point for which many critical subsystems compete). Almost anything "interesting" that you want to do to configure an NT or Win '9x system involves tweaks to the registry. Anyone from that background who complains about how "non-intuitive" UNIX/Linux configuration file names are should take a good look at those \HKLM\... references to which they've become accustomed.
So, what I want out of a configuration management interface is one which primarily consolidates the process of creating and modifying these configuration text files and integrates that with a documentation and context sensitive help system.
A nice thing about having lots of small, individual text configuration file is that you can prepare one canonical or template that is suited for a given site or situation and easily distribute that to as many systems as necessary. It's scaleable with simple distribution and processing (scripting and text processing) tools.
The dark side of this model is that each of these conf files has a unique syntax and set of semantics. It's like having to know dozens of dialects of Hindi and Punjab to work within one administrative domain. That's the problem that I want solved.
Linuxconf tries to do too many other things and doesn't offer me a way to just spit out the conf files.
So, I don't use it.
This means that its quite possible that you could use Linuxconf to do what you want with a minimum of fuss and virtually no understanding of what all the "moving parts" mean or how they relate. However, I can't guide you along that path --- since I've taken the low road (or the "low-level" road as it were).

(?) Any help or assistance you can provide would be ever so greatly appreciated!

Thankyou Al

(!) So, let's revisit those questions:
What do you mean by "on the Internet?" You mention using a modem and using e-mail. So I'll guess that you want to be a simple, dial-in PPP client, to access web and e-mail (presumably through a POP mailbox) from a conventional ISP.
Note that I'm guessing here. There are many other ways to be "on the Internet."
For example you might want to have your own domain, configure one modem to maintain a persistent connection to the Internet, set up your own web and mail servers, configure another modem for dial-in by some associates etc. That would an equally legitimate interpretation of your question.
In general the process of connecting a Linux box consists of the following steps:
Most of these correspond to the other questions you asked. Fans of the OSI networking reference model will note that I've listed these roughly in order from the lowest level (physical) towards the upper (applications) layer. We're "stacking" each step on top of the ones on which it depends. (I bet some of you have wondered by the call it a "TCP/IP stack").
In your case you've said that you want to use a modem. So that will be your communications channel. We'll cover that with your next question.
Once you've dialed into your ISP and established a modem connnection, you'll have to run some protocol over that connection in order to provide any sort of networking through it. These days that will almost certainly be PPP. In the days of yore (about 4 or 5 years ago) you might have been coping with SLIP. That's virtually unheard of these days.
Under Linux PPP is provided by the PPP daemon, usually installed as /usr/sbin/pppd.
Your ISP probably defaults to issuing "dynamic IP" addresses. The PPP protocol has features for negotiating and establishing addressing, masking, and routing for each new connection. So long as you stick with reasonable defaults then you won't have to deal with those issues directly. We'll talk about that, and LAN addressing when we address your third question.
Almost all operations on the Internet are done using host and domain names. So one of the most vital "glue" services provided by the Internet is DNS.
This is usually classified as an "applications layer" service, because the Internet TCP/IP protocols don't conform to the seven layer OSI reference model. I tend to think of it as a "presentation layer" service (having to do with the translation between user/applications representation in the form of names to a lower level machine representation, IP addresses). I'm sure some OSI purist will correct me on this.
In any event there is a bit of a chicken-and-egg problem when we think about DNS. We have to provide an egg, in the form of one or more IP addresses, to gives us the whole specifies of other nameservers that form the DNS system.
So we list a few nameservers in our /etc/resolv.conf.
Conventionally these would either being a local caching name server or one of the name servers operated and maintained by our ISP. This makes quite alot of sense since it minimizes the number of network hops taken by our name resolution requests and their replies. In other words it results in faster name resolution at less overall cost in bandwidth across the Internet.
Usually you can just create one /etc/resolv.conf and leave it in place permanently. Even if you have multiple ISPs its possible to refer to any nameserver on the Internet, even if it isn't the "closest."
Once you have these networking basics in place you can access most Internet services. You can browse the web, fetch Linux package updates over FTP, telnet, use the finger command etc.
Note that your ISP might provide a proxy/cache for its customers. If that's the case you might be a bit happier (and make your ISP much happier) if you configure your web browsers to point to his Squid server, or whatever he's using. If that's the case, your ISP should provide you with the information and support to use the feature (it's really of more benefit to him and your fellow customers than anyone else).
E-mail is special case. There are many ways for you and your ISP to configure your e-mail services. In the simplest case you have an address of the form: YourName@YourISP.com and you just periodically use a POP or IMAP client to fetch your mail from your ISP's server.
Your POP/IMAP client might be part of a mail user agent (MUA: a program for reading and composing/sending e-mail) or it be a separate utility like 'fetchmail' which relays your mail from an mail store to a local "spool" (mailbox).
Note that POP is only a way of receiving e-mail. When it comes to sending e-mail there are two methods that are commonly employed by UNIX MUAs.
Most well-behaved programs call on a local program named /usr/lib/sendmail (which might be a copy of the classic 'sendmail' MTA, mail transport agent, or it might be any program that provides a sufficiently compatible interface to allow MUAs to feed mail to the local system transport agents).
Some programs ("know-it-alls") will bypass the local MTA and attempt to directly open their own connections to the mail transport agent on the recipients home host (or MX as the case may be). Netscape Communicator is an example of this class of program.
The reason I make this distinction is that your choice of MUA has implications regarding how your configure your system so that the mail you generate has an appropriate return address. It generates another "It depends..."
If you don't configure your system correctly then most people will not be able to respond to any mail you send them. They'll have to remember your address and type that in every time rather than being able to use the "reply" feature of their MUA. That would not endear you to your correspondents.
We'll get to that in a bit more detail later.
That's the overview of "getting on the Internet." Obviously most of the details are left to the constituent questions that you've provided.
First you need a real modem. This seems so obvious you might wonder why I'd even mention it.
winmodems (a.k.a. "losemodems").
To understand the difference between a real modem and a "winmodem" you have to know a little bit about how modems work.
The term modem originally stood for "modulator/demodulator" (which sounds like something Marvin the Martian might be brandishing as he says "Take me to your leader").
Telephone lines carry electrical signals which are normally analog modulations of sound. The fact that sound can be easily represented and transmitted by and replayed from electrical signals (in the forms of telephone, radio and phonograph, for example) is the major realization on which Thomas Edison built his fortune and his historical legacy.
For computers to make use of this medium they must be able to convert their digital signals into modulated electrical signals and vice versa. Thus we have devices that modulate and demodulate.
Fundamentally modems are programmable tone generators, usually with analog-to-digital (A/D) and digital-to-analog (D/A) circuitry and other stuff in them.
It's this other stuff that grew increasingly sophisticated throughout the late 70's, 80's and into the early 90's. Modern "smartmodems" and "Hayes Compatible" modems are essentially special purpose computers running an embedded system. The interface to that embedded system is any of the many variations to the AT set that every modem manufacturer has created.
In particular these modems needed to do signal transformations that were much more sophisticated that simple AM and FM (amplitude and frequency modulations respectively). So they needed special DSP (digital signal processing) chips as well as a processor and memory to handle the interpretation of AT commands. Naturally they also had fairly significant ROMs to store the AT command set interpreters.
The advantage of all this is that modems work in a relatively standard way, through a minimal interface (the serial port) and without introducing much processing overhead on the host systems.
Ironically the most recent real modems have CPUs that are probably more powerful than early PCs.
However, some manufacturers came up with the brilliant idea of ripping out all the DSPs, processors and firmware out of their modems. They produce a device which is essentially just the programmable tone generators, and force the host system to do all of the signal processing and provide the interface (AT command set emulation). This entails running a rather bulky and computationally expensive driver on the host system.
Those are winmodems.
Winmodems wouldn't be such a bad idea under certain circumstances. If the devices were priced much lower than "real" modems, and if the programming specifications were widely available, then the choice would be simply be a matter of comparing cost/benefit factors.
However, neither of these conditions is true of winmodems in the current PC market. They aren't significantly less expensive to the consumer (so the manufacturers and distributors keep all of the margin). Also, and here's the part that's of interest to Linux users, the specifications for devices are not available. Therefore the only drivers that exist for most of them are for MS Windows. In some cases it appears that some manufacturers have released proprietary UNIX drivers.
The economics that result in the widespread deployment of winmodems are instructive. As far as I can tell they first their way into the market through bundling. At a certain point it became a significant marketing handicap to sell a computer system without including a modem. However, the only characteristic of a modem that was important in marketing whole systems is the optimal throughput speeds. So computer retailers included the cheapest modems (in the right "speed" range) that they could find.
Since almost every system shipped with a (win)modem there was a corresponding drop in the sales of (real) modems as separately purchased peripherals. (Probably this wasn't really a "drop" so much as a slower growth in sales as compared to the broader expansion of the whole computing market). These (win)modems are mostly made by the same manufacturers as real modems. Naturally it then made sense for them to package these devices in the same way as their real modems for separate sales.
So, when you go to the store to buy a modem you'll find that winmodems are packaged identically to internal (real) modems. They are usually not clearly labelled (sometimes the warning doesn't even appear in the fine print on the outside packaging).
So, the easiest way to guarantee that you are getting a real modem is to buy an external one. So far as I know it's not possible to make an external "winmodem" that connects to a plainn old serial port. (One could certainly design a "RAM modem" that required a software driver to be "uploaded" to it, and such devices might exist --- but I'd put those in a different class even if they did require MS Windows or other proprietary drivers to operate).
The real danger of winmodems (and winprinters, which are similar in some respects) is that they build an artificial economic and hardware barrier to the adoption of new or alternative software. In other words, they give too much power to Microsoft (in this particular case). Any similar technology is best avoided by the wise consumer (regardless whether the co-incident beneficiary is Microsoft or any other software company).
There are some efforts to write drivers for some winmodems. Naturally the programming interfaces are different for each model and brand of these devices. In most cases the manufacturers are not providing any support for the efforts (and in some cases I'd bet that the modem manufacturers can't do so, since they may have licensed their drivers through a third party, etc.).
If any of those projects is a success than the modems that are supported by Linux will probably be called "linmodems."
At that point there will probably be four or five classes of modems in the PC world. "Real" modems (internal ISA, PCI, and external), winmodems (those that are still not supported by Linux), "linmodems" (those winmodems that are supported with a Linux driver), and possibly the USB modems will be in a class of their own.
Note that there is a potential problem with internal modems even if they are "real" (non-Winmodems). Some of these are "Plug and Pray" devices that must be initialized by some proprietary driver. In some cases you may be able to cope using the Linux pciutils package.
PCMCIA modems, such as you might be tempted to use in your laptop, come in both "real" and winmodem flavors. As with other internal modems there is usually nothing to clarify the matter on the packaging or in the marketing literature for these modems.
Calling the manufacturer's technical support line might help --- if they have one, if you can get through, and if the person you talk to has a clue what your asking about and the inclination and liberty to honestly answer your question.
However, the simple advice is:
Throw away the internal modem that came with your machine.
Buy an external modem!
If I recall correctly the Dell Inspiron 7000 that you have includes an internal "winmodem" --- ignore it. It's not supported by Linux. (Although Dell may be providing a supported modem in future versions since I've heard rumors that they'll eventually be offering desktop and laptop system with Linux pre-installed).
That finally leads us to the answer to the question at hand. How do we use a real modem under Linux?
Linux has a very simple interface to any normal modem. The application simply opens the device's node (entry in the filesystem which provides a means of access UNIX/Linux device drivers through normal file operations).
This would usually be /dev/ttyS0 or /dev/ttyS1, though it could be any of the /dev/ttyS* devices that represent access to the conventional PC serial ports (COM1 through COM4). It could also be any of the many devices associated with various multi-port serial cards (ttyR* for RocketPort, ttyC* for Cyclades, ttyD* for some Digiboard, and others for Stallion, etc.).
It's common for Linux users to create symlinks named /dev/modem and /dev/mouse which point to the real device interfaces for these common peripherals. Then all of our applications and configuration files can use the symbolic name. If we ever change to a different mouse or connect a modem to a different port we can simply update the symlink and leave all our software alone.
Once a process has an open read/write connection to the modem (and a lock on the device node to prevent other processings from jumping into the "conversation") then the use of the modem is rather simple. The communications application handles all of the details for you.
What's going on under the hood is a structured conversation (protocol) between the application and the modem. The application sends a special break signal after a pause to "break" the modem into command mode (similar to using the [Esc] key in 'vi' to break out of text entry mode into its command mode). Then the application can send a series of AT commands (that is any command starting with the ASCII sequence "AT"). These sequences set various options on the modem, and instruct it to dial and establish connections).
The modem reponds with various result codes like "OK" and "CONNECT" and "BUSY" etc. (Most of them can be configured to return numeric codes instead of text).
The basic AT command set is the same for all Hayes compatible modems. However, there are many extensions and settings that differ among brands and models of modem. The most significant differences are in the "init strings" --- these are AT commands which configure the modem in preparation for a particular mode of operation.
Tweaking init strings is more art than science. It can depend on the modem in use, the other modem to which it is connecting, and the software that will be communicating over the channel ... among other things. Every Linux serial communications utility is responsible for its own init strings and other dialogs with the modem.
This is quite unfortunate in some respects. It would be nice if 'uucico', 'kermit', 'pppd/chat', 'mgetty', 'efax', 'minicom', 'seyon', and other modem-using Linux utilities were all "reading off the same page" for at least the major modem settings (if they were all written to read and parse an /etc/modemcap file, or something like that). This would allow the admin to consolidate most of the information into one place, while allowing the applications to override those settings as necessary.
However, that's not the way it works, and it's not likely to become a new standard. So we'll stop daydreaming and get back to how it DOES work.
Here's what's necessary to get an application to talk to your modem:
Distribution maintainers usually set their programs to be mutually consistent (to use compatible lock files for example). They often don't configure their permissions and ownership to match my preferred policies, so I usually have to tweak some things to get them the way I want them to be.
In your case you're specifically interested in PPP. It sounds like you won't be using 'mgetty' (to recieve incoming data connections or faxes), and it seems unlikely that you'd be using any other modem utilities, or that you might just want to use 'sendfax' or 'efax' in addition to your PPP.
In addition it sounds like you are going to be running this system as a personal workstation, with no other accounts on it. This means that you won't have any problem where you try to access the modem, and some other user on you system is already using it. In other words, you don't have to concern yourself much with device locking and contention. The Red Hat default settings are probably fine for your case.
There have been many articles on setting up 'pppd' for Linux. It's surprisingly difficult simply because there are so many options. The Linux 'pppd' is designed to act as a networking client or server.
Technically PPP is a peering system, so the terms "client" and "server" are misnomers here. However, I use these terms to distinguish between the system that is initiating the connection (dialing in as a "client") and the one that is responding to it (answering the phone as a "server").
The Linux PPP daemon can act in both of these roles.
In your case you just want your pppd to act as a client.
The overall process is:
I personally recommend that the /etc/ppp/options file contains just one directive:
lock
That will force the PPP daemon to check for, respect and maintain a device lock file so that it can co-ordinate its use of the modem with any other programs that might be using it. I've talked about the gritty details of lock files before. You needn't worry about the details much since you probably will never really need the lockfiles. However, it's a good "placeholder" for your /etc/ppp/options file in most cases.
This allows us to put all of our other directives in a more specific file. We can then have different options files for different ISPs, and even for different modem banks at each ISP (when the fast local lines are busy you try the slower and more distant lines). It also allows us to have special options files for each modem (/etc/ppp/options.ttyXX) and for individual users (~/.ppprc). Those options are for allowing dial-in PPP If you wanted to connect to your home computer from work, or allow your friends to connect to you.
After creating that file (or checking that your distribution has created a suitable one for you) you can then create an ISP specific options file. That might look something like:

/dev/modem 115200

modem

crtscts

defaultroute

connect "chat -f /etc/ppp/chat.MYISP"

# connect "chat -v -f /etc/ppp/chat.MYISP"

# debug

# kdebug 7

# mtu 576 # 296

# mru 576 # 296
... notice that the first line refers to our device and speed. These must be the first options specified in this file, or they should be listed as parameters on the pppd command line in whatever script we write to make our calls.
The next two lines instruct the PPP daemon to treat the device as a modem (as opposed to a "local" or direct null modem connection) and to use the RTS/CTS (ready to send / clear to send) control wires on the cable between the modem and the computer (a common form of hardware handshaking).
The next directive instructs the PPP daemon to set a default route pointing to whichever interface it establishes while parsing this file. This is sensible when you are using 'pppd' as a client/caller to connect to an Internet ISP. You would not use it if you were making a connection to some private network, especially if you had a DSL or other Internet connection (through an ethernet card or some other PPP connection). Obviously an ISP that was using Linux/pppd on its dial-in modem servers would also NOT use this directive.
The next directive is the hardest for new Linux/'pppd' users to get working. It supplies a command that pppd use to establish new connections. As in this example this is usually an invocation of the 'chat' command. The chat file contains supply a dialog between the system and the modem followed by a dialog between the local and remote computers.
Chat scripts are lists of "send/expect" pairs. 'chat' implements a very small programming language for describing these dialogs, setting timeout intervals and abort conditions, and handling simple errors. Writing 'chat' scripts by hand is a hassle. There are several dialog/menu driven (text and GUI) front end programs (interfaces) which try to make this process (and the overall process of configuring PPP and connecting to the Internet) easier. You can find a whole directory of such tools at:
https://metalab.unc.edu/pub/Linux/system/network/serial/ppp
One that is conspicuously missing from this directory is WvDial at:
https://www.worldvisions.ca/wvdial
... This is probably the most popular of these interfaces. I've never used it personally (I edit my chat scripts by hand --- they aren't very long and I had to learn the syntax long before these tools existed).
However, I've heard many positive reports about it, so I can recommend it with some confidence. I notice from my Freshmeat search (to find its home page) that WvDial has been upgraded quite recently (earlier this month). So we have some indication that it's not suffering from "code rot" and neglect.
If you do have to create a chat script by hand here's what a typical one might look like:
TIMEOUT 30
ABORT BUSY
ABORT 'NO CARRIER'
"" ATZ
OK-AT&F-OK ATDT1234567890
CONNECT \d\r
ogin:-BREAK-ogin: MYUSERNAME
ssword:-\r-ssword: \qMYPASSWORD\q
"starting PPP..."
The first line sets the a timeout setting. The next two lines describe a couple of conditions under which chat should exit with an error exit value (if it receives either of these strings, it will ABORT the rest of the attempted dialog and call).
The following three lines are a simple modem dialog. The "expect" nothing (an empty string) and send a Hayes modem "reset" command (ATZ). If that doesn't result in an OK response then a "reset to factory defaults" is issued (AT&F). (If that doesn't result in the desired OK string then the script will time out and fail). Then we see an attempt to dial the phone and we wait for any sort of CONNECT string. We send a "delay" followed by a blank line. Those are indicated with the "escape sequences" as marked by the backslash prefix in \d and \r.
If your modem need some "init string" tweaks you'd insert them after the ATZ command.
The last three lines are a dialog between the remote system and ours. When a Hayes compatible modem connects it automatically shifts into "connect/communications mode" and ceases to interpret strings as commands. We'd send a "delay" followed by a "+++" to break back into the modem's command mode.
This dialog implements a simple login procedure. It expects a string like "login:" or "Login:" and sends a user/account name. The it expects a string like "Password:" or "password:" and "quietly" sends a password. (The "quietly" in this case refers to how 'chat' treats is "verbose" and "logging" output, and has NOTHING to do with its communications to the remote system). Finally our script expects an acknowlegement from the remote system indicating that it will now attempt to negotiate a PPP connection with us (using its implementation of PPP). Many people will not need this last line.
After this last expect string the script simply ends.
If 'chat' gets this far in the dialog it exits without returning any error (its system exit value is 0). Then the pppd program which spawned it resumes control of the file descriptor (/dev/modem) and attempts to negotiate a network connection over this new communications channel.
As we can see, spaces and line feeds separate the expect strings from the send strings. We have to quote any strings that contain spaces (using single or double quotes). The ABORT and TIMEOUT directives each take a single argument. That's why we have to use multiple ABORT directives to add a second abort string to the list. The dashes we've embedded in some of the expect strings implement a very simple (and somewhat crude) error response option. If the expected string (before the dash) is not detected within the timeout period, then the "error string" will be send to try to get the dialog back on track.
This is a very simplistic "language." It has not structures to support conditionals (IF/THEN/ELSE) or loops, etc. There are alternative utilities to implement more sophisticated chat scripting languages if you should need them. In particular you could use the 'expect' programming language (which is a TCL variant).
However ---- 'chat' is adequate for most cases (all that I've encountered so far).
One trick for getting the expect/send dialog that we need is to manually log into our ISP using 'minicom' or Kermit. We can then capture the dialog (on paper or using a "log to disk" feature or the 'script' (typescript) command.
One nice thing about using 'minicom' for this early stage of preparation and debugging is that we can manually login and "quit" out of minicom without resetting the modem. We can then invoke our PPP daemon with the chat script commented out. This should result in a working PPP connection (thus assuring us that our PPP options are correct and allowing us to focus purely on the chat script).
Getting back to our example PPP options file we see a series of comments. These can be used for doing debugging when we are having trouble with this connection. The first comment is a copy of the connect command line with the -v option added to 'chat' --- this provides us with verbose logging output (which is posted to our system logs so we can see our system engage in this dialog by reading our /var/log/messages file).
I usually login into one of my other virtual consoles when I'm debugging PPP connnections. You might just open an extra 'xterm'. From there just issue a command like:
tail -f /var/log/messages
... and leave it running. You'll see your log messages displayed as syslog receives them. (Actually on my own systems I add a line to my /etc/syslog.conf to post copies of all syslog output to one of my extra virtual consoles --- usually #24. But we won't get into that here).
The next couple of comments could be "uncommented" to direct 'pppd' to be more verbose as it runs (resulting in more output in our /var/log/messages).
The last couple of lines in this sample PPP options file are examples of how we might over-ride the maximum transmission and receive unit sizes, with a couple of common values to which we might force them. These mtu/mru settings might help us maintain faster, more robust connections under some line conditions and using some combinations of modems and other settings.
There are many other directives that we can put in your options files. Some might say there are TOO many.
These include options for enabling software flow control (if the crtscts directive won't work for your modem and cable, for example) and ways to note which control characters can't be cleanly transmitted over your connection (which will force pppd to "quote these" as multi-character sequences). There are several options to control the authentication and protocol negotiation between your PPP daemon and your ISP's system.
If you really want or need to know the gory details, read the 'pppd' man page.
Once our PPP daemon is communicating with our ISP's PPP implementation the two of them will usually negotiate a number of communications settings and most ISPs will then send us our IP address, netmask, and associated route.
The Linux 'pppd' will look for an executable /etc/ppp/ip-up and invoke that with a documented list of parameters (look in the man page). This can be used to set up additional services or doing any other custom event handling. Perhaps you want to resynchronize your system clock with an NTP server or three whenever you start up a new IP connection and run 'xntpd' for the duration, or perhaps you only want to run the 'ntpdate' command on the first connection of any given day. Perhaps you want to register your new, dynamically assigned IP address with some dynamic DNS system or announce that you're "online" to one or more of these "ICQ" services, etc.
There is also a /etc/ppp/ip-down hook and some analogous scripts for IPX handling.
Getting back to our bulleted list. When we've created a suitable options file and a working chat script we'd then generally create a script to call pppd with the appropriate options to use them.
This might be as simple as:

#!/bin/sh
/usr/sbin/pppd file /etc/ppp/options.MYISP
... which would simply instruct the PPP daemon to read our options file in addition to the global one (/etc/ppp/options).
In other cases we might have to prepare our serial port with commands like 'setserial' and 'stty'. 'stty' has an unusual syntax since it performs ioctl() calls on its stdin (standard input) file descriptor. Thus we have to use a command like:
stty crtscts cs8 -clocal 38400 < /dev/modem
... to actually affect the modem. Note that the redirection is FROM the device rather than to it. 'stty' is the only command that I know of that requires this odd syntax. The fact that I understand why it works this way doesn't make it any better for most users.
Hopefully your Red Hat installation is properly handling the serial ports on your system already. Otherwise you might have to play with the 'setserial' command which I simply don't have time to explain here.
As I've said, pppd will automatically invoke the ip-up and ip-down scripts as appropriate. So usually the invocation of pppd will be the last line in your "call.MYISP" script. You could do some scripting to retry several times, or try alternate numbers or alternative ISPs if your connection fails too often. In those cases you might want to use the -detach directive in your PPP options file.
Its possible to include most or all of your PPP options on 'pppd's command line (and it's possible to include your chat script on 'chat's command line; so with clever quoting you could have a long messy line that didn't rely on any of the custom configuration files that I've described here).
However, pppd is complicated enough without being downright obfuscatory.
The last bullet point I mentioned referred to "/etc/ppp/pap-secrets and/or /etc/ppp/chap-secrets" files. Some ISPs may be using the PAP or CHAP authentication protocols (which are built into Linux pppd). If so they should provide the name and password (secret) along with your other account information (like their phone numbers, and the IP addresses of their preferred nameservers). Generally the use of these authentication protocols should shorten and simplify your chat script. In our example the second part of the chat dialog (the host-to-host part) performed our authentication.
I realize that this was a long-winded (some might say excruciating) description of a very simple PPP configuration. I go into this much detail (and even into a few digresssions) in the hopes that it will help you and others who have tried to read the HOWTOs and the man pages and walked away in utter confusion.
Notice that this whole handling of the 'pppd' options files and the 'chat' scripts is the hardest part of getting Linux connected to your ISP. The fact that there so many options and several different files, and the fact that these all have to be consistent with one another in fairly complex ways it what confuses new users (and occasionally trips up even the most experienced of us).
When I'm teaching classes for Linuxcare (one of my roles with them) I refer to these as "moving parts." Any time we have a list of options that must correlate to one another to get a particular feature or subsystem (like PPP) working it requires a bit of explanation was to how all of these options fit together.
I usually draw a mechanical analogy. If I try to put a Toyota start motor into a typical Ford truck, it won't work. The pieces will almost certainly not fit together. The teeth in the starter's shaft will probably not mesh with those on the flywheel. The solenoid's throw might not push the start shaft out far enough to even engage them. The mounting holes probably won't line up, and the bolts probably wouldn't fit even if they did. (Of course this analogy provides a bit more detail than most people with no automotive inclinations appreciate; but the idea has been pretty clear to my students so far).
This concept of "moving parts" is a recurring theme in all technical education. There are many "moving parts" in MS Windows --- places where the value you put in one dialog box must "match" a different value in some other dialog, control panel or registry tree.
Often the settings on one machine must match settings on a different machine. In fact, that is the essence of networking.
So, having gone into great detail on this central question we'll finish by providing somewhat shorter answers to your other questions.
As I pointed out, most ISPs will provide your IP address through the PPP protocol. They should also provide forward and reverse DNS mappings between your IP address and some name (often dyn-123.myisp.com or dialin-123.somepop.myisp.com; where pop in this context refers to a "point of presence" --- a location where your ISP has modems and phone lines that connect to their network).
Netmasks and broadcast addresses are handled automatically by PPP. The basic interface route is also handled by the PPP daemon, as is the default route in most cases.
Your ISP will probably provide you with a list of preferred name servers. You simply put those in your /etc/resolv.conf which should look something like: 
domain starshine.org
search starshine.org
nameserver 123.45.67.89
nameserver 12.3.5.67
nameserver 12.3.5.78
If you were setting up your own network domain you'd have to register it with some naming authority (currently the InterNIC/NSI for the .com, .org, and .net domains, and various regional registries for the various national and .us state domains). When you registered your domain you'd also register a list of authoritative name servers (by IP address). These would have to be persistently online (through some form of "dedicated 24x7" connection to the Internet.
Usually small domains run by inexperienced used simply let their ISP handle all those details. They "outsource" their DNS management.
I've written other articles in the past that go into way too much detail about configuring your own DNS. That, and the fact that you almost certainly do NOT want to do this for yourself are reasons while I'll leave off further discussion of DNS here.
Basically everything is handled by your PPP configuration except for the contents of your /etc/resolv.conf.
If you have multiple ISPs you can use the ip-up script to force a symlink change whenever you connect. You create multiple /etc/resolv.conf.* files and use your script to create the appropriate symlink whenever you bring up the interface. This also works reasonably well when you are using DHCP, connecting your laptop to someone's ethernet network.
You can then point your /etc/resolv.conf to /etc/dhcpdc/resolv.conf (or wherever your DHCP client puts it).
It's also possible to just leave one set of nameservers listed in your /etc/resolv.conf and ignore your ISPs preferred list. This may result in slower response time and some wasted bandwidth (your name resolution requests will travel farther across the Internet before being answered). However, it usually works well enough for the case where you have a secondary ISP that you only call occasionally.
I've described a little bit of the complexity of e-mail handling already.
Basically you'll need at least a mail user agent (and MUA). Some MUAs (like Netscape Communicator and PINE) have integrated POP/IMAP clients and transport agents.
Others (like elm, mh, and mutt) will only provide the interface for reading, composing and managing your mail. They will require the use of separate utilities to receive your mail (i.e. 'fetchmail' for POP or IMAP mail stores) and to deliver it (typically 'sendmail' configured to "masquerade" as your ISP or vanity domain).
In your particular case it might be easiest to start with one of the "all-in-one" mail clients. I personally don't like their approach. However they can be simpler for a common case, even if they will cause problems for some networks where more centralization is required (behind firewalls and on private networks, for example).
If you need or want to configure a proper MTA then 'sendmail' is still the most widespread (a statement which will surely generate some flames from some 'qmail' fans our there). Here's is a simple sendmail "mc" (macro configuration) file: 
divert(0)dnl
OSTYPE(linux)
include(`/usr/share/sendmail.cf/m4/cf.m4')
FEATURE(`allmasquerade')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`masquerade_entire_domain')dnl
FEATURE(`always_add_domain')dnl
FEATURE(`nocanonify')dnl
FEATURE(`local_procmail')dnl
MAILER_DEFINITIONS
MAILER(`smtp')dnl
MAILER(`local')dnl
MAILER(`procmail')dnl
undefine(`BITNET_RELAY')dnl

MASQUERADE_AS(`***MYISP.COM***')dnl
define(`SMART_HOST', `smtp:***MAIL.MYISP.COM***')dnl
There are only two major "moving parts" to this file. You must change the last two lines to to match the domain/host name at which your ISP will accept mail for you (the part of your e-mail address after the @ sign) and you must provide a valid mail exchanger for your SMART_HOST.
This file would normally be created under /etc/mail/ or under /usr/share/sendmail-cf/ and would be used to generate a sendmail.cf file with a command like:
m4 < sendmail.mc > /etc/sendmail.cf
... issued from the same directory as the .mc file, of course.
Of course those other lines are also "moving parts" --- you might need to change the path to the include line, and you might need to include or even disable some features, etc. Like so many other coniguration files in Linux, all I can provide is a reasonable example that should work in many cases.
I've included other sample .mc files in other Answer Guy columns in the past. Usually I include one that's derived from whatever I'm running at home at any given time. This has changed over the years as I've changed my network, changed ISPs, etc.
For this to work smoothly you should create an account on your system that matches your account name on your ISP, and use that to work with your e-mail from that address. It's possible for you to control the name/address in your outgoing e-mail headers as well as the domain/host name portion. In other words you could configure 'sendmail' to modify the portion of your e-mail address that precedes the @ sign in the headers of your outgoing mail, as well as the part that follow it. However, that would require you to use the "genericstable" feature which is somewhat more advanced than I want to go in this message. (This is another case where the "all-in-one" mailers are easier to use. They'll generally let you set your e-mail address to anything you like without regard to any local system or network policies).
I think I've answered this one. 'chat' is your "Dialer" for the PPP daemon. Most other Linux/UNIX communications packages perform their own dialing by issuing ATDT (dial/tone) commands to the modem. If (by some strange chance) you had a phone that required the old pulse dialing (a rotary phone!) you'd use the ATDP command.
Al,
I realize that this has been a long article. I know that I've repeated myself in a few places (it's been written over several days, with a trip to L.A. and a conference in the middle).
Hopefully this will give you enough of a map of the forest that you can figure out which trees to climb, which ones to chop down and which branches to ignore.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 45 September 1999
HTML transformation by Heather Stern of Starshine Technical Services, https://www.starshine.org/

[ Answer Guy Index ] 1 2 3 4
5 6 7 8
9 10 11 12 13

[ Table Of Contents ] [ Front Page ] [ Previous Section ] [ Next Section ]