File: 12.html

package info (click to toggle)
lg-issue45 2-4
links: PTS
area: main
in suites: woody
size: 1,464 kB
ctags: 159
sloc: makefile: 36; sh: 4
file content (1581 lines) | stat: -rw-r--r-- 61,287 bytes
parent folder | download | duplicates (2)
<!--startcut ======================================================= -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<META NAME="generator" CONTENT="lgazmail v1.2M.l">
<TITLE>The Answer Guy 45: Getting Access to the Internet</TITLE>
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
	LINK="#3366FF" VLINK="#A000A0">
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<H4>"The Linux Gazette...<I>making Linux just a little more fun!</I>"</H4>
<P> <hr> <P>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<center>
<H1><A NAME="answer">
	<img src="../../gx/dennis/qbubble.gif" alt="(?)" 
		border="0" align="middle">
	<font color="#B03060">The Answer Guy</font>
	<img src="../../gx/dennis/bbubble.gif" alt="(!)" 
		border="0" align="middle">
</A></H1> 
<BR>
<H4>By James T. Dennis,
	<a href="mailto:answerguy@ssc.com">answerguy@ssc.com</a><BR>
	LinuxCare,
	<A HREF="http://www.linuxcare.com/">http://www.linuxcare.com/</A> 
</H4>
</center>

<p><hr><p>
<!--  endcut ======================================================= -->
<!-- begin 13 -->
<H3 align="left"><img src="../../gx/dennis/qbubble.gif" 
	height="50" width="60" alt="(?) " border="0"
	>Getting Access to the Internet</H3>


<p><strong>From albuquerque on Tue, 31 Aug 1999  
</strong></p>
<!-- ::
Getting Access to the Internet
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:: -->
<P><STRONG>
Hope you can help me.  I have a DELL I7K laptop running WIN98 and
Linux RH6.0.
</STRONG></P>
<P><STRONG>
Linux seems to be running fine, have <A HREF="http://www.gnome.org/">GNOME</A>
as my window stuff, I can access the PCMCIA card and use a SYQUEST SCSI drive.
</STRONG></P>
<P><STRONG>
Now I'd like to use Linux to access the Internet!!!!!!!!!!!!!
</STRONG></P>
<P><STRONG>
I have read most or many How TO s etc. and keep getting lost in
the forest.
</STRONG></P>
</STRONG>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
As with the answers to many questions about Linux quite a bit of
my response will be qualified with: "It depends..."
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
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"?
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
I think <A HREF="http://www.redhat.com/">Red Hat</A> recommends the use 
of the linuxconf package.  I don't know what Linuxcfg would be, or what
sort of "special commands" it might offer.
</BLOCKQUOTE>
<BLOCKQUOTE>
(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).
</BLOCKQUOTE>
<BLOCKQUOTE>
So, your questions were:
</BLOCKQUOTE>
<BLOCKQUOTE><ul><li>
What are the steps needed to "get on the Internet" with
Linux?
<li>What is needed to set up a modem under Linux?
<li>What is needed to set up "DNS numbers" (by which I presume
you mean: set your IP address, network/subnet mask,
broadcast address, and specify the addresses of your
"nearest" name servers)?
<li>What is needed to needed to set up e-mail?
<li>Where is the "Dialer?"
</ul></BLOCKQUOTE>

<BLOCKQUOTE>
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.
</UL></BLOCKQUOTE>
<BLOCKQUOTE>
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 <EM>SHOULD</EM> be easy and straightforward.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
To complicate issues more every distribution starts out with
a set of assumptions how things "should" be done.  For
example RedHat 6.0 includes '<tt>linuxconf</tt>' --- and Red Hat Inc is
encouraging people to use it.
</BLOCKQUOTE>
<BLOCKQUOTE>
Personally I don't like Linuxconf (nitpick, <tt>linuxconf</tt> 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Linuxconf tries to do too many other things and doesn't
offer me a way to just spit out the conf files.
</BLOCKQUOTE>
<BLOCKQUOTE>
So, I don't use it.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
Any help or assistance you can provide would be ever so greatly
appreciated!
</STRONG></P>
<P><STRONG>
Thankyou Al
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
So, let's revisit those questions:
</BLOCKQUOTE>
<BLOCKQUOTE><ul><li>
What are the steps needed to "get on the Internet" with
Linux?
</ul></BLOCKQUOTE>

<BLOCKQUOTE>
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.
</UL></BLOCKQUOTE>
<BLOCKQUOTE>
Note that I'm guessing here.  There are many other ways
to be "on the Internet."
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
In general the process of connecting a Linux box
consists of the following steps:
</BLOCKQUOTE>
<BLOCKQUOTE><ul><li>
Establish a physical link (communications
channel)
<li>
Configure a TCP/IP interface (handle IP
addressing, subnet masking, etc)
<li>
Configure routing (usually: set a default
route)
<li>
Configure name services resolution
(<TT>/etc/resolv.conf</TT>)
<li>
Configure and access specific applications
services
</ul></BLOCKQUOTE>

<BLOCKQUOTE>
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 <em>stack</em>").
</UL></BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Under Linux PPP is provided by the PPP daemon, usually
installed as <TT>/usr/sbin/pppd.</TT>
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
So we list a few nameservers in our <TT>/etc/resolv.conf</TT>.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Usually you can just create one <TT>/etc/resolv.conf</TT> 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."
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
<A stub="mailto:YourName@YourISP.com"
	>YourName@YourISP.com</A> and you just periodically use a POP
or IMAP client to fetch your mail from your ISP's
server.
</BLOCKQUOTE>
<BLOCKQUOTE>
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 '<tt>fetchmail</tt>'
which relays your mail from an mail store to a local
"spool" (mailbox).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Most well-behaved programs call on a local program named
<TT>/usr/lib/sendmail</TT> (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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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..."
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
We'll get to that in a bit more detail later.
</BLOCKQUOTE>
<BLOCKQUOTE>
That's the overview of "getting on the Internet."
Obviously most of the details are left to the constituent
questions that you've provided.
</BLOCKQUOTE>
<BLOCKQUOTE><ul><li>
What is needed to set up a modem under Linux?
</ul></BLOCKQUOTE>

<BLOCKQUOTE>
First you need a real modem.  This seems so obvious you
might wonder why I'd even mention it.
</BLOCKQUOTE>
<BLOCKQUOTE>
winmodems (a.k.a. "losemodems").
</BLOCKQUOTE>
<BLOCKQUOTE>
To understand the difference between a real modem and a
"winmodem" you have to know a little bit about how
modems work.
</BLOCKQUOTE>
<BLOCKQUOTE>
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").
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Ironically the most recent real modems have CPUs that
are probably more powerful than early PCs.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Those are winmodems.
</BLOCKQUOTE>
<BLOCKQUOTE>
Winmodems wouldn't be such a bad idea under certain
circumstances.  If the devices were priced <EM>much</EM> 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.).
</BLOCKQUOTE>
<BLOCKQUOTE>
If any of those projects is a success than the modems
that are supported by Linux will probably be called
"linmodems."
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
However, the simple advice is:
</BLOCKQUOTE>
<BLOCKQUOTE><BlockQuote>
Throw away the internal modem that came with
your machine.
</BlockQuote></BLOCKQUOTE>
<BLOCKQUOTE><blockquote>
Buy an external modem!
</blockquote></BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
That finally leads us to the answer to the question at
hand.  How do we use a <EM>real</EM> modem under Linux?
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
This would usually be <TT>/dev/ttyS0</TT> or <TT>/dev/ttyS1</TT>, though
it could be any of the <TT>/dev/ttyS*</TT> 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.).
</BLOCKQUOTE>
<BLOCKQUOTE>
It's common for Linux users to create symlinks named
<TT>/dev/modem</TT> and <TT>/dev/mouse</TT> 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
This is quite unfortunate in some respects.  It would be
nice if '<tt>uucico</tt>', '<tt>kermit</tt>', '<tt>pppd</tt>/<tt>chat</tt>',
'<tt>mgetty</tt>', '<tt>efax</tt>',
'<tt>minicom</tt>', '<tt>seyon</tt>', 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 <TT>/etc/modemcap</TT> 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Here's what's necessary to get an application to talk to
your modem:
</BLOCKQUOTE>
<BLOCKQUOTE><ul><li>
Provide it with the correct device name.
<li>
Ensure that the ownership and permissions
of the device node and <TT>/dev/</TT> directory are
suitable for your applications settings (this
frequently involves marking the application/
utility as SGID to a "modem" group).
<li>
Configure it to use the same location, naming
convention and format for its lock files as
all other applications on your system which
have access to the modem.
<li>
Provide your application/utility with any
init strings or other specific settings it
needs.
<li>
Ensure that the line is "conditioned"
correctly.  Most modem using applications
will do this for themselves, but sometimes
you need to write a wrapper script that will
use the 'setserial' and/or 'stty' commands to
prepare the serial line (the settings of the
device driver) for use, or reset it
afterwards.
</UL></BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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").
</BLOCKQUOTE>
<BLOCKQUOTE>
The Linux PPP daemon can act in both of these roles.
</BLOCKQUOTE>
<BLOCKQUOTE>
In your case you just want your pppd to act as a client.
</BLOCKQUOTE>
<BLOCKQUOTE>
The overall process is:
</BLOCKQUOTE>
<BLOCKQUOTE><ul><li>Edit the <TT>/etc/ppp/options</TT> file,
<li>Create an <TT>/etc/ppp/options.MYISP</TT> file
<li>Create a "chat script" (<TT>/etc/ppp/chat.MYISP</TT>)
<li>Create a script to call the pppd with the
    directive to use <TT>/etc/ppp/options.MYISP.</TT>
<li>(Possibly) create entries in the
    <TT>/etc/ppp/pap-secrets</TT> and/or <TT>/etc/ppp/chap-secrets</TT> files
</UL></BLOCKQUOTE>
<BLOCKQUOTE>
I personally recommend that the <TT>/etc/ppp/options</TT> file
contains just one directive:
</BLOCKQUOTE>
<BLOCKQUOTE><BlockQuote>
lock
</BlockQuote></BLOCKQUOTE>
<BLOCKQUOTE>
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 <TT>/etc/ppp/options</TT> file in most cases.
</BLOCKQUOTE>
<BLOCKQUOTE>
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
(<TT>/etc/ppp/options.ttyXX</TT>) and for individual users
(<tt>~/.ppprc</tt>).  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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<BLOCKQUOTE><BLOCKQUOTE><CODE>
<BR><TT>/dev/modem</TT> 115200
<Br><BR>modem
<Br><BR>crtscts
<Br><BR>defaultroute
<Br><BR>connect "chat -f <TT>/etc/ppp/chat.MYISP</TT>"
<Br><BR># connect "chat -v -f <TT>/etc/ppp/chat.MYISP</TT>"
<Br><BR># debug
<Br><BR># kdebug 7
<Br><BR># mtu 576	# 296
<Br><BR># mru 576 	# 296
</CODE></BLOCKQUOTE></BLOCKQUOTE>
<BLOCKQUOTE>
... 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <TT>/</TT> clear to send) control wires on the cable between
the modem and the computer (a common form of hardware
handshaking).
</BLOCKQUOTE>
<BLOCKQUOTE>
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 '<tt>pppd</tt>' 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
The next directive is the hardest for new Linux/'<tt>pppd</tt>'
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 '<tt>chat</tt>' command.
The chat file contains supply a dialog between the
system and the modem followed by a dialog between the
local and remote computers.
</BLOCKQUOTE>
<BLOCKQUOTE>
Chat scripts are lists of "send/expect" pairs.  '<tt>chat</tt>'
implements a very small programming language for
describing these dialogs, setting timeout intervals and
abort conditions, and handling simple errors.  Writing
'<tt>chat</tt>' 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:
</BLOCKQUOTE>
<BLOCKQUOTE><BlockQuote>
<A HREF="http://metalab.unc.edu/pub/Linux/system/network/serial/ppp"
	>http://metalab.unc.edu/pub/Linux/system/network/serial/ppp</A>
</BlockQuote></BLOCKQUOTE>
<BLOCKQUOTE>
One that is conspicuously missing from this directory is
WvDial at:
</BLOCKQUOTE>
<BLOCKQUOTE><BlockQuote>
<A HREF="http://www.worldvisions.ca/wvdial"
	>http://www.worldvisions.ca/wvdial</A>
</BlockQuote></BLOCKQUOTE>
<BLOCKQUOTE>
... 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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
If you do have to create a chat script by hand here's
what a typical one might look like:
</BLOCKQUOTE>
<BLOCKQUOTE><BlockQuote><Code>
TIMEOUT 30
<Br>ABORT BUSY
<Br>ABORT 'NO CARRIER'
<Br>"" ATZ
<Br>OK-AT&amp;F-OK ATDT1234567890
<Br>CONNECT \d\r
<Br>ogin:-BREAK-ogin: MYUSERNAME
<Br>ssword:-\r-ssword: \qMYPASSWORD\q
<Br>"starting PPP..."
</Code></BlockQuote></BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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&amp;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.
</BLOCKQUOTE>
<BLOCKQUOTE>
If your modem need some "init string" tweaks you'd
insert them after the ATZ command.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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
'<tt>chat</tt>' 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
After this last expect string the script simply ends.
</BLOCKQUOTE>
<BLOCKQUOTE>
If '<tt>chat</tt>' 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 (<TT>/dev/modem</TT>) and attempts to negotiate a
network connection over this new communications channel.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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
'<tt>expect</tt>' programming language (which is a TCL variant).
</BLOCKQUOTE>
<BLOCKQUOTE>
However ---- '<tt>chat</tt>' is adequate for most cases (all
that I've encountered so far).
</BLOCKQUOTE>
<BLOCKQUOTE>
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 '<tt>script</tt>'
(typescript) command.
</BLOCKQUOTE>
<BLOCKQUOTE>
One nice thing about using '<tt>minicom</tt>' 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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <tt>-v</tt> option added to '<tt>chat</tt>' --- 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 <TT>/var/log/messages</TT> file).
</BLOCKQUOTE>
<BLOCKQUOTE>
I usually login into one of my other virtual consoles
when I'm debugging PPP connnections.  You might just
open an extra '<tt>xterm</tt>'.  From there just issue a command
like:
</BLOCKQUOTE>
<BLOCKQUOTE><BLOCKQUOTE><CODE>
tail -f /var/log/messages
</CODE></BLOCKQUOTE></BLOCKQUOTE>
<BLOCKQUOTE>
... 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 <TT>/etc/syslog.conf</TT> to post
copies of all syslog output to one of my extra virtual
consoles --- usually #24.  But we won't get into that
here).
</BLOCKQUOTE>
<BLOCKQUOTE>
The next couple of comments could be "uncommented" to
direct '<tt>pppd</tt>' to be more verbose as it runs (resulting in
more output in our <TT>/var/log/messages</TT>).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
There are many other directives that we can put in your
options files.  Some might say there are TOO many.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
If you really want or need to know the gory details,
read the '<tt>pppd</tt>' man page.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
The Linux '<tt>pppd</tt>' will look for an executable
<TT>/etc/ppp/ip-up</TT> 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 '<tt>xntpd</tt>' for the
duration, or perhaps you only want to run the '<tt>ntpdate</tt>'
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
There is also a <TT>/etc/ppp/ip-down</TT> hook and some analogous
scripts for IPX handling.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
This might be as simple as:
</BLOCKQUOTE>
<BLOCKQUOTE><BLOCKQUOTE><CODE>
<BR>#!/bin/sh
<BR>/usr/sbin/pppd file /etc/ppp/options.MYISP
</CODE></BLOCKQUOTE></BLOCKQUOTE>
<BLOCKQUOTE>
... which would simply instruct the PPP daemon to read
our options file in addition to the global one
(<TT>/etc/ppp/options</TT>).
</BLOCKQUOTE>
<BLOCKQUOTE>
In other cases we might have to prepare our serial port
with commands like '<tt>setserial</tt>' and '<tt>stty</tt>'.  
'<tt>stty</tt>' has
an unusual syntax since it performs <tt>ioctl()</tt> calls on its
stdin (standard input) file descriptor.  Thus we have to
use a command like:
</BLOCKQUOTE>
<BLOCKQUOTE><BLOCKQUOTE><CODE>
stty crtscts cs8 -clocal 38400 &lt; /dev/modem
</CODE></BLOCKQUOTE></BLOCKQUOTE>
<BLOCKQUOTE>
... to actually affect the modem. Note that the
redirection is FROM the device rather than to it.
'<tt>stty</tt>' is the only command that I know of that requires
this odd syntax.  The fact that I understand <EM>why</EM> it
works this way doesn't make it any better for most
users.
</BLOCKQUOTE>
<BLOCKQUOTE>
Hopefully your Red Hat installation is properly
handling the serial ports on your system already.
Otherwise you might have to play with the '<tt>setserial</tt>'
command which I simply don't have time to explain here.
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <tt>-detach</tt> directive
in your PPP options file.
</BLOCKQUOTE>
<BLOCKQUOTE>
Its possible to include most or all of your PPP options
on '<tt>pppd</tt>'s command line (and it's possible to include
your chat script on '<tt>chat</tt>'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).
</BLOCKQUOTE>
<BLOCKQUOTE>
However, pppd is complicated enough without being
downright obfuscatory.
</BLOCKQUOTE>
<BLOCKQUOTE>
The last bullet point I mentioned referred to
"<TT>/etc/ppp/pap-secrets</TT> and/or <TT>/etc/ppp/chap-secrets</TT>"
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Notice that this whole handling of the '<tt>pppd</tt>' options
files and the '<tt>chat</tt>' 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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Often the settings on one machine must match settings on
a different machine.  In fact, that is the essence of
networking.
</BLOCKQUOTE>
<BLOCKQUOTE>
So, having gone into great detail on this central
question we'll finish by providing somewhat shorter
answers to your other questions.
</BLOCKQUOTE>
<BLOCKQUOTE><ul><li>
What is needed to set up "DNS numbers" (by which I presume
you mean: set your IP address, network/subnet mask,
broadcast address, and specify the addresses of your
"nearest" name servers)?
</UL></BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Your ISP will probably provide you with a list of
preferred name servers.  You simply put those in your
<TT>/etc/resolv.conf</TT> which should look something like:
</BLOCKQUOTE>

<blockquote><pre>domain starshine.org
search starshine.org
nameserver 123.45.67.89
nameserver 12.3.5.67
nameserver 12.3.5.78
</pre></blockquote>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Usually small domains run by inexperienced used simply
let their ISP handle all those details.  They
"outsource" their DNS management.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Basically everything is handled by your PPP
configuration except for the contents of your
<tt>/etc/resolv.conf</tt>.
</BLOCKQUOTE>
<BLOCKQUOTE>
If you have multiple ISPs you can use the ip-up script
to force a symlink change whenever you connect.  You
create multiple <TT>/etc/resolv.conf.*</TT> 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
You can then point your <TT>/etc/resolv.conf</TT> to
<TT>/etc/dhcpdc/resolv.conf</TT> (or wherever your DHCP client
puts it).
</BLOCKQUOTE>
<BLOCKQUOTE>
It's also possible to just leave one set of nameservers
listed in your <TT>/etc/resolv.conf</TT> 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.
</BLOCKQUOTE>
<BLOCKQUOTE><ul><li>
What is needed to needed to set up e-mail?
</UL></BLOCKQUOTE>

<BLOCKQUOTE>
I've described a little bit of the complexity of e-mail
handling already.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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. '<tt>fetchmail</tt>' for POP or IMAP mail
stores) and to deliver it (typically '<tt>sendmail</tt>'
configured to "masquerade" as your ISP or vanity
domain).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
If you need or want to configure a proper MTA then
'<tt>sendmail</tt>' is still the most widespread (a statement
which will surely generate some flames from some '<tt>qmail</tt>'
fans our there).  Here's is a simple sendmail "mc"
(macro configuration) file:
</BLOCKQUOTE>

<blockquote><pre>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
</pre></blockquote>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
This file would normally be created under <TT>/etc/mail/</TT> or
under <TT>/usr/share/sendmail-cf/</TT> and would be used to
generate a sendmail.cf file with a command like:
</BLOCKQUOTE>
<BLOCKQUOTE><BlockQuote><Code>
m4 &lt; sendmail.mc &gt; /etc/sendmail.cf
</Code></BlockQuote></BLOCKQUOTE>
<BLOCKQUOTE>
... issued from the same directory as the .mc file, of
course.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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 '<tt>sendmail</tt>' 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).
</BLOCKQUOTE>
<BLOCKQUOTE><ul><li>
Where is the "Dialer?"
</ul></BLOCKQUOTE>
<BLOCKQUOTE>
I think I've answered this one.  '<tt>chat</tt>' 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Al,
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<!-- sig -->

<!-- end 13 -->
<!--startcut ======================================================= -->
<P> <hr> <P>
<H5 align="center"><a href="http://www.linuxgazette.com/ssc.copying.html"
	>Copyright &copy;</a> 1999, James T. Dennis 
<BR>Published in <I>The Linux Gazette</I> Issue 45 September 1999</H5>
<H6 ALIGN="center">HTML transformation  by
	<A HREF="mailto:star@starshine.org">Heather Stern</a> of
	Starshine Technical Services,
	<A HREF="http://www.starshine.org/">http://www.starshine.org/</A> 
</H6>
<P> <hr> <P>
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
<TABLE WIDTH="98%"><TR VALIGN="center" ALIGN="center">
<TD ROWSPAN="2" COLSPAN="2" WIDTH="42%"><A 
	HREF="../lg_answer45.html"
	><IMG SRC="../../gx/dennis/answernew.gif"
              ALT="[ Answer Guy Index ]"></A></td>
  <TD WIDTH="14%"><A HREF="1.html">1</A></TD>
  <TD WIDTH="14%"><A HREF="2.html">2</A></TD>
  <TD WIDTH="14%"><A HREF="3.html">3</A></TD>
  <TD WIDTH="14%"><A HREF="4.html">4</A></TD>
</TR><TR VALIGN="center" ALIGN="center">
  <TD WIDTH="14%"><A HREF="5.html">5</A></TD>
  <TD WIDTH="14%"><A HREF="6.html">6</A></TD>
  <TD WIDTH="14%"><A HREF="7.html">7</A></TD>
  <TD WIDTH="14%"><A HREF="8.html">8</A></TD>
</TR><TR VALIGN="center" ALIGN="center">
  <TD><A HREF="9.html" >9</A></TD>
  <TD><A HREF="10.html">10</A></TD>
  <TD><A HREF="11.html">11</A></TD>
  <TD><A HREF="12.html">12</A></TD>
  <TD><A HREF="13.html">13</A></TD>
</TR></TABLE>
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
<P> <hr> <P>
<!-- begin lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<A HREF="../../lg_toc45.html"
	><IMG SRC="../../gx/indexnew.gif" ALT="[ Table Of Contents ]"></A>
<A HREF="/index.html"
	><IMG SRC="../../gx/homenew.gif" ALT="[ Front Page ]"></A>
<A HREF="../lg_bytes45.html"
	><IMG SRC="../../gx/back2.gif" ALT="[ Previous Section ]"></A>
<A HREF="../lg_tips45.html"
	><IMG SRC="../../gx/fwd.gif" ALT="[ Next Section ]"></A>
<!-- end lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
</BODY></HTML>
<!--endcut ========================================================= -->