mirror of https://github.com/tLDP/LDP
7694 lines
241 KiB
Plaintext
7694 lines
241 KiB
Plaintext
<!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
|
||
|
||
|
||
<Article id="index">
|
||
|
||
<ArtHeader>
|
||
|
||
<Title>DSL HOWTO for Linux</Title>
|
||
|
||
<PubDate>v1.71, 2002-07-21</PubDate>
|
||
|
||
<AuthorGroup>
|
||
<AUTHOR>
|
||
<FirstName>Hal</FirstName>
|
||
<SurName>Burgiss</SurName>
|
||
<Affiliation>
|
||
<Address>
|
||
<Email>hal@foobox.net</Email>
|
||
</Address>
|
||
</Affiliation>
|
||
</AUTHOR>
|
||
|
||
<AUTHOR>
|
||
<FirstName>Original Author: David</FirstName>
|
||
<SurName>Fannin</SurName>
|
||
<Affiliation>
|
||
</Affiliation>
|
||
</AUTHOR>
|
||
|
||
<Editor>
|
||
<firstname>Greg</firstname>
|
||
<surname>LeBlanc</surname>
|
||
<Affiliation>
|
||
<Address>
|
||
<Email>GLeblanc@cu-portland.edu</Email>
|
||
</Address>
|
||
</Affiliation>
|
||
</Editor>
|
||
|
||
</AuthorGroup>
|
||
|
||
<!--
|
||
|
||
Not supported...
|
||
|
||
<othercredit>
|
||
<firstname>Greg</firstname>
|
||
<surname>LeBlanc</surname>
|
||
<contrib>Help with layout, organization and various content suggestions.
|
||
</contrib>
|
||
</othercredit>
|
||
|
||
...and if co-author is not used or is inappropriate, you could use
|
||
the <othercredit> tag. Example:
|
||
<othercredit>
|
||
<firstname>Greg</firstname>
|
||
<othername>J</othername>
|
||
<surname>Ferguson</surname>
|
||
<contrib>Conversion to DocBook SGML; updated section on
|
||
foo</contrib>
|
||
</othercredit>
|
||
This goes in the <artheader> (DocBook 3.x) or <articleinfo> (DocBook 4.x)
|
||
section.
|
||
|
||
|
||
|
||
-->
|
||
|
||
<RevHistory>
|
||
|
||
<Revision>
|
||
<RevNumber>v1.71</RevNumber>
|
||
<Date>2002-07-21</Date>
|
||
<Authorinitials>hb</Authorinitials>
|
||
<RevRemark>
|
||
Add another supported modem only.
|
||
</RevRemark>
|
||
</Revision>
|
||
<Revision>
|
||
<RevNumber>v1.7</RevNumber>
|
||
<Date>2002-07-14</Date>
|
||
<Authorinitials>hb</Authorinitials>
|
||
<RevRemark>
|
||
More small updates.
|
||
</RevRemark>
|
||
</Revision>
|
||
|
||
<Revision>
|
||
<RevNumber>v1.6</RevNumber>
|
||
<Date>2002-05-23</Date>
|
||
<Authorinitials>hb</Authorinitials>
|
||
<RevRemark>
|
||
Various small updates.
|
||
</RevRemark>
|
||
</Revision>
|
||
|
||
|
||
<Revision>
|
||
<RevNumber>v0.92</RevNumber>
|
||
<Date>1999-04-10</Date>
|
||
<Authorinitials>df</Authorinitials>
|
||
<RevRemark>
|
||
First release (ADSL mini HOWTO).
|
||
</RevRemark>
|
||
</Revision>
|
||
</RevHistory>
|
||
|
||
|
||
<KeywordSet>
|
||
<Keyword>DSL</Keyword>
|
||
<Keyword>xDSL</Keyword>
|
||
<Keyword>ADSL</Keyword>
|
||
<Keyword>RADSL</Keyword>
|
||
<Keyword>IDSL</Keyword>
|
||
<Keyword>G.Lite</Keyword>
|
||
<Keyword>SDSL</Keyword>
|
||
<Keyword>SHDSL</Keyword>
|
||
<Keyword>PPPoE</Keyword>
|
||
<Keyword>PPPoA</Keyword>
|
||
<Keyword>PPPoATM</Keyword>
|
||
<Keyword>DSLAM</Keyword>
|
||
<Keyword>VDSL</Keyword>
|
||
<Keyword>Broadband</Keyword>
|
||
<Keyword>Internet</Keyword>
|
||
<Keyword>Network</Keyword>
|
||
<Keyword>Alcatel</Keyword>
|
||
</KeywordSet>
|
||
|
||
<Abstract>
|
||
|
||
<Para>
|
||
<Comment>
|
||
|
||
aspell -H -c DSL-HOWTO.sgml
|
||
submit@tldp.org
|
||
|
||
export CVSROOT=:pserver:hal@cvs.tldp.org:/cvsroot
|
||
cvs -d $CVSROOT login
|
||
pword: XXXXXXXXXXXXXX
|
||
|
||
$cvs get LDP/howto/docbook/DSL-HOWTO.sgml
|
||
|
||
upload...
|
||
$ cvs commit DSL-HOWTO.sgml !!!!!!!!!!!!!!!!
|
||
(from the LDP/howto/docbook/ dir)
|
||
|
||
check here: http://cvs.pld.org.pl/LDP/howto/docbook/DSL-HOWTO.sgml
|
||
|
||
alex alex@bennee.com, user land A STUSB.
|
||
|
||
====================================================================
|
||
Submitted 1.71 07/21/02
|
||
Changes:
|
||
IteX PCI ADSL modem (Apollo 3 chipset) Dlink
|
||
|
||
|
||
Todo:
|
||
Add the ADSL Bandwidth HOWTO
|
||
|
||
Begin 1.7 07/10/02 SUBMITTED 07/14/02
|
||
Changes:
|
||
Added comments on ISDN microfilters being different.
|
||
cable modem now more secure.
|
||
http://eciadsl.sourceforge.net USB modems.
|
||
Add something on usepeerdns per Timo Karjalainen timo.karjalainen@myorigo.com
|
||
remove linuxfriendly ISPs???
|
||
|
||
Todo:
|
||
|
||
|
||
Begin 1.6 01/07/02 submitted 05/23/02
|
||
Changes:
|
||
new faq re: distance CO vs DSLAM
|
||
minor touch ups to DSL family.
|
||
Trouble: setup both chap and pap
|
||
Removed sympatico from ISPs.
|
||
Xpeed not in 2.4.
|
||
Made table of out of distance chart
|
||
Alarm re-write.
|
||
|
||
|
||
Released 1.5 to LDP 01/07/02
|
||
Begin 1.5 12/10/01
|
||
|
||
Changes:
|
||
new ISP (Tiscali)
|
||
new ATM page URL
|
||
new ISP (istop)
|
||
http://sourceforge.net/projects/speedtouch (new link)
|
||
Adv Routing tweaks! 12/28/01 HOT!
|
||
New FAQ (be my own ISP?)
|
||
PPP LCP tuning
|
||
LCP in glossary
|
||
new ISP (q-dsl)
|
||
fixed _screen_ tags 12/31/01
|
||
removed linux.com.sg/news/atm/
|
||
rewrite new tuning section on iproute 01/02/02
|
||
reworked SpeedTouch section again. (major)
|
||
|
||
|
||
ToDo:
|
||
See: http://ds9a.nl/lartc/HOWTO/cvs/2.4routing/output/2.4routing-15.html#ss15.8
|
||
cbq stuff
|
||
|
||
Begin 1.4 started 06/30/01
|
||
|
||
Changes:
|
||
new ISP (VIC)
|
||
new ISP FAQ: T-DSL
|
||
shorewall firewall added. 11/01/01
|
||
BT-Internet doc added
|
||
Minor note on interleaving per Juha
|
||
Removed references to Rhythms telco
|
||
shdsl update
|
||
Security URLs (mine)
|
||
Took out large chunk of security related stuff. It's in the
|
||
Security HOWTOs now, and better explained.
|
||
Re-worked the Alcatel USB section, removing Chris's HOWTO.
|
||
|
||
Todo:
|
||
|
||
Look at txt version. Some screen output is not spaced right.
|
||
Flesh out linux router. Add basic networking.
|
||
NAT'd ISPs????
|
||
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2923.html PMTUD, don't block
|
||
destination unreachable ICMP.
|
||
|
||
|
||
Submitted 1.3 06/30/01
|
||
Begin 1.3 Wed 03/28/01 06:57:01 PM
|
||
|
||
Changes:
|
||
Fixed a few broken links.
|
||
Feeble attempt to add some internalization to a few sections.
|
||
RWIN and interleaving in glossary.
|
||
Minor changes to comments on RBOC/independent shake out, and
|
||
remote terminals.
|
||
Updates to the SpeedTouch HOWTO in appendix
|
||
Added back the NTS FAQ.
|
||
Added a new dyn dns org.
|
||
Added bit about kernel mode PPPoE/rp-pppoe per David Skoll
|
||
|
||
|
||
<!--
|
||
|
||
|
||
<date>
|
||
<year>2000</year>
|
||
<month>12</month>
|
||
<date>11</date>
|
||
</date>
|
||
|
||
|
||
<glossary><title>Example Glossary</title>
|
||
<para>
|
||
This is not a real glossary, it's just an example.
|
||
</para>
|
||
|
||
<glossdiv><title>E</title>
|
||
<glossentry id="xml"><glossterm>Extensible Markup Language</glossterm>
|
||
<acronym>XML</acronym>
|
||
<glossdef>
|
||
<para>Some reasonable definition here.</para>
|
||
<glossseealso otherterm="sgml">
|
||
</glossdef>
|
||
</glossentry>
|
||
</glossdiv>
|
||
|
||
</glossary>
|
||
|
||
-->
|
||
|
||
</Comment>
|
||
</Para>
|
||
|
||
|
||
|
||
<Para>
|
||
This document examines the DSL family of high speed Internet services now
|
||
being deployed in various markets worldwide. Information is included on the
|
||
technology behind DSL as well as subscribing, installing, configuring, and
|
||
troubleshooting, with an emphasis on how this impacts Linux users.
|
||
</Para>
|
||
|
||
</Abstract>
|
||
|
||
</ArtHeader>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
||
|
||
<Sect1 id="intro">
|
||
<Title>Introduction</Title>
|
||
|
||
<Para>
|
||
DSL, or Digital Subscriber Loop, is a high-speed Internet access technology
|
||
that uses a standard copper telephone line (a.k.a. <Quote>loop</Quote> in
|
||
telco parlance). DSL provides a direct, dedicated connection to an ISP via
|
||
the existing telco network. DSL is designed to run on up to 80% of the
|
||
telephone lines available in the United States. By using line-adaptive
|
||
modulation, DSL is capable of providing data speeds of 8 Mbps or more.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
DSL services are now being aggressively marketed for home and small business
|
||
use. DSL is typically priced below ISDN, and well below T1 service, yet can
|
||
provide potentially even greater speeds than T1 without the
|
||
cost, complexity, and availability issues of T1. Since DSL is a dedicated,
|
||
often <Quote>always on</Quote> service, it avoids the delays and use charges
|
||
that are common with ISDN. Making this quite a nice technology for the
|
||
bandwidth starved masses.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
While all this sounds exciting, DSL does have some drawbacks. The quality of
|
||
the DSL signal, and thus the connection, depends on distance (the length of
|
||
the copper <Quote>loop</Quote>) and various other factors. Also, there is no
|
||
such thing as standard <Quote>DSL</Quote>. There are various flavors of DSL,
|
||
and many, many ways DSL providers are implementing their networks. In typical
|
||
fashion, Linux users are often left to fend for themselves, since the DSL
|
||
providers are often taking the easy way out, and catering only to
|
||
<Quote>mainstream</Quote> Operating Systems.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The topics included in this HOWTO include qualification and pre-installation,
|
||
installation, configuration, troubleshooting and securing a DSL connection. As
|
||
well as other related topics. There are also appendices including a
|
||
comprehensive <Link LinkEnd="overview">DSL Overview</Link>, <link
|
||
linkend="faq">Frequently Asked Questions</link>, a listing of <link
|
||
linkend="links">related links</link>, and a <link
|
||
linkend="glossary">glossary</link>. </Para>
|
||
|
||
<Para>
|
||
Due to the fast pace of change in the telco and DSL industries, please make
|
||
sure you have the latest version of this document. The current official
|
||
version can always be found at
|
||
<Ulink
|
||
url="http://www.tldp.org/HOWTO/DSL-HOWTO/">http://www.tldp.org/HOWTO/DSL-HOWTO/</Ulink>. Pre-release versions can be found at <Ulink
|
||
URL="http://feenix.burgiss.net/ldp/adsl/">http://feenix.burgiss.net/ldp/adsl/</Ulink>.
|
||
|
||
</Para>
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Document Structure and Reading Guidelines</Title>
|
||
|
||
<Para>
|
||
This document attempts to give a comprehensive discussion of DSL. All aspects
|
||
are hopefully addressed to one degree or another with what can be a complex
|
||
topic since it deals with networking, hardware, new fangled technologies, and
|
||
various approaches taken by various vendors. The core components of this
|
||
document are:
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The <Link LinkEnd="installation">Installation</Link> section covers
|
||
installation of DSL hardware and related components, including wiring
|
||
considerations, splitter or microfilter installation, modem and Network
|
||
card installation.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The <Link LinkEnd="configure">Configuring Linux</Link> section covers
|
||
mostly client and software aspects of getting the connection up and
|
||
running. The Network card configuration is actually covered mostly in the
|
||
above Installation section.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The <Link LinkEnd="secure">Securing Your Connection</Link> section covers
|
||
Security implications that are even more important with a full-time
|
||
connection. Linux users seem especially targeted by crackers, because
|
||
quite frankly, some don't understand how important security is, or don't
|
||
understand the finer points of this. And who wants to <quote>own</quote>
|
||
a Windows box?
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The <Link LinkEnd="tuning">Tuning and Troubleshooting</Link> section
|
||
covers post-installation topics like how well is our connection performing,
|
||
and how to track down any show-stoppers or intermittent problems.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
There is also a lengthy Appendix that covers various topics relating to
|
||
Linux and DSL. None of these are directly related to simply getting that
|
||
connection up and running, but may be of interest nonetheless.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
|
||
|
||
<Para>
|
||
To simplify the navigation of this document, below is a suggested reading
|
||
guideline. Everyone should read the Introduction. Please pay special
|
||
attention to the <Link LinkEnd="usage">Conventions and Terminology</Link>
|
||
section, as some of this terminology may be used somewhat differently in
|
||
other contexts. Also, there is a <Link LinkEnd="glossary">Glossary</Link> if
|
||
you get lost in the world of TA (telco acronyms) ;-).
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If you don't know anything about DSL, you should probably read the entire
|
||
document. You may want to start with the <Link LinkEnd="overview">DSL
|
||
Overview</Link> section in the Appendix, and then the <Link
|
||
LinkEnd="faq">FAQ</Link>. The DSL Overview explains how the various pieces
|
||
of the puzzle fit together. DSL network implementations are more complex
|
||
than traditional dialup networks.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If you have already done some homework, but have not ordered service from
|
||
anyone yet, read the <Link LinkEnd="cproviders">Choosing
|
||
Providers</Link> section. Also, you might get a head start by reading the
|
||
<Link LinkEnd="configure">Configuring Linux</Link> section so you know
|
||
what lies ahead.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If you have ordered service already, and are awaiting delivery, you can
|
||
skip the sections on choosing a Provider. If you will be doing a
|
||
self-install, you should read the pertinent parts of the <Link
|
||
LinkEnd="installation">Installation</Link> section, the <Link
|
||
LinkEnd="configure">Configuring Linux</Link> section, and the <Link
|
||
LinkEnd="secure">Securing Your Connection</Link> section.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If the installation is complete, and you can't get a working connection,
|
||
skip right to the <Link LinkEnd="tuning">Troubleshooting</Link> Section.
|
||
If you are not clear on what protocols are required, or what software you
|
||
need to have installed, also read the <Link
|
||
LinkEnd="configure">Configuring Linux</Link> section. If not sure what
|
||
terms like <Quote>sync</Quote> mean in this context, then be sure to read
|
||
the <Link LinkEnd="overview">DSL Overview</Link> section first so you know
|
||
how it all fits together.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If trying to decide between cable and DSL, read the
|
||
<Link LinkEnd="cable">Cable vs DSL</Link> section, and possibly the
|
||
<Link LinkEnd="overview">DSL Overview</Link> section.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If you have never had a full-time Internet connection, or are not
|
||
absolutely sure you fully understand how to secure you connection,
|
||
be sure to read The <Link LinkEnd="secure">Securing Your Connection</Link>
|
||
section. If you don't understand some aspect of this, re-read it, or start
|
||
looking for other references.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
There is a comprehensive <Link LinkEnd="links">Links section</Link> that
|
||
has references to some topics not touched on in the main body of the
|
||
Document itself.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>What's New</Title>
|
||
<para>
|
||
1.71: Add info on the IteX PCI ADSL modem only.
|
||
|
||
</para>
|
||
<para>
|
||
1.7: Added comments on ISDN line filters being different than POTS,
|
||
and other additions related to ADSL over ISDN in various places. Add another
|
||
supported modem: Eci Hi Focus ADSL Modem (and various related chipsets).
|
||
Removed the 'Linux Friendly ISP' section. The landscape has changed much
|
||
since this section was started. Back then there were few options for DSL in
|
||
many places, and all too often a non-compatible modem was the only thing
|
||
available. Also, the advent of microfilters and self-installation has helped
|
||
with the <quote>do-it-yourselfer</quote> approach, giving everybody more
|
||
freedom. Then, maintaining this number of links was a PITA too. I still
|
||
encourage new subscribers to shop their local markets if there are options.
|
||
Many large ISPs and telcos have very poor ideas of what an Internet
|
||
connection is and restrict severely what you can do with Linux. Or at least
|
||
try to ;-) Updated LDP links to tldp.org (from linuxdoc.org).
|
||
</para>
|
||
<para>
|
||
1.6: Several new Linux Friendly ISPs. Clarification on
|
||
problems with alarm systems. Minor touch ups to other sections, and fix some
|
||
broken links (never ending job :).
|
||
|
||
</para>
|
||
<para>
|
||
1.5: New Tuning sub-section using <application>iproute</application>. Hot
|
||
stuff! Other additions to the Tuning section. A few new ISPs. Alcatel
|
||
SpeedTouch USB section updates. Thanks to Alex Bennee for clarifying things.
|
||
Other minor updates to FAQ, Glossary and Tuning.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
1.4: A few new and updated URLs, and catch ups. The Alcatel USB modem section
|
||
is revamped. A few new ISPs.
|
||
|
||
</para>
|
||
|
||
<Para>
|
||
Version 1.3: Updates to the SpeedTouch USB HOWTO in the appendix.
|
||
Minor update to PPPoE section, and two new Linux Friendly ISPs. A feeble
|
||
attempt to make the document a little less U.S.-centric. Various minor
|
||
updates.
|
||
</Para>
|
||
|
||
<Para>
|
||
Version 1.2 adds PPTP configuration section for Alcatel ethernet modems.
|
||
Also, added are two additional sections in the <Quote>Tuning</Quote> section
|
||
for the TCP Receive window, and ADSL/DMT interleaving. And the big news is
|
||
the release of open source drivers for the Alcatel USB modem as of March
|
||
2001. There is an Alcatel SpeedTouch USB mini HOWTO in the <Link
|
||
LinkEnd="SpeedtouchUSB">appendix</Link> by Chris Jones. A number of
|
||
miscellaneous updates as well.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Version 1.1 included quite a few minor corrections, updates,
|
||
and additions. Not much that is substantially new. There are finally two
|
||
Linux compatible DSL PCI modems from Xpeed. The drivers are now in the kernel
|
||
2.2.18 source (not ported to 2.4 as of this writing 05/23/02).
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Version .99 addresses some of the many changes that have occurred since the
|
||
original ADSL mini HOWTO was published. Originally, ADSL was the primary DSL
|
||
technology being deployed, but more and more some of the other DSL flavors
|
||
are entering the picture -- IDSL, SDSL, G.Lite, and RADSL. Thus the renaming
|
||
from <Quote>ADSL mini HOWTO</Quote> to the <Quote>DSL HOWTO</Quote>. There
|
||
have been many other changes in DSL technology as well. PPPoE/A encapsulation
|
||
has become more and more common as many ISPs are jumping on this bandwagon.
|
||
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Copyright</Title>
|
||
|
||
<Para>
|
||
DSL HOWTO for Linux (formerly the ADSL mini HOWTO)
|
||
</Para>
|
||
|
||
<Para>
|
||
Copyright © 1998,1999 David Fannin.
|
||
</Para>
|
||
|
||
<Para>
|
||
This document is free; you can redistribute it and/or modify it under the
|
||
terms of the GNU General Public License as published by the Free Software
|
||
Foundation; either version 2 of the License, or (at your option) any later
|
||
version.
|
||
</Para>
|
||
|
||
<Para>
|
||
This document is distributed in the hope that it will be useful, but WITHOUT
|
||
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
|
||
FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
|
||
details.
|
||
</Para>
|
||
|
||
<Para>
|
||
You can get a copy of the GNU GPL at <ULink
|
||
URL="http://www.gnu.org/copyleft/gpl.html">GNU GPL</ULink>.
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Credits</Title>
|
||
|
||
<Para>
|
||
Thanks to all those that contributed information to this HOWTO. I have
|
||
anti-spammed their email addresses for their safety (and mine!). Remove the
|
||
X's from their names.
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis remap="bf">B Ediger</Emphasis> (Xbediger@csn.net) Great
|
||
Description of loop impairment.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis remap="bf">C Wiesner</Emphasis> ( Xcraig@wkmn.com) List of many ADSL URLs.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis remap="bf">J Leeuw</Emphasis> ( Xjacco2@dds.nl) Many tips on ADSL,
|
||
especially in Europe
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis remap="bf">N Silberstein</Emphasis> ( Xnick@tpdinc.com) Info on
|
||
Netrunner and his experience with US Worst.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Many and various posters from comp.dcom.xdsl and
|
||
bellsouth.net.support.adsl, too numerous to mention individually.
|
||
(HB)
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis remap="bf">Juha Saarinen</Emphasis> for suggestions and
|
||
explanations on the TCP Receive Window, and related tuning topics.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis remap="bf">Chris Jones</Emphasis>
|
||
<email>chris@black-sun.co.uk</email> for his Alcatel SpeedTouch USB mini
|
||
HOWTO which was previously incorporated into the <Link
|
||
LinkEnd="SpeedtouchUSB">Appendix</Link>. Also, Alex Bennee for clarifying
|
||
the driver situation for this modem.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<sect2 id="disclaimer">
|
||
<title>Disclaimer</title>
|
||
|
||
<para>
|
||
The authors accept no liability for the contents of this document. Use the
|
||
concepts, examples and other content at your own risk. As this is a new
|
||
edition, there may be errors and inaccuracies. Hopefully these are few and
|
||
far between. The author(s) do not accept any responsibility for incorrect or
|
||
misleading information, and would certainly appreciate any corrections. Also,
|
||
this type of technology dates itself very quickly. What may be true today, is
|
||
not guaranteed to be true tomorrow.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
All copyrights are held by their respective owners, unless specifically noted
|
||
otherwise. Use of a term in this document should not be regarded as affecting
|
||
the validity of any trademark or service mark.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
References to any particular product, brand, service or company should
|
||
not be construed as an endorsement or recommendation. Excepting Linux
|
||
itself, of course!
|
||
|
||
</para>
|
||
|
||
</sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Feedback</Title>
|
||
|
||
<Para>
|
||
Any and all comments on this document are most welcomed. Please make sure you have
|
||
the most current version before submitting corrections! These can be sent to
|
||
<email>hal@foobox.net</email>
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="usage">
|
||
<Title>Conventions, Usage and Terminology</Title>
|
||
|
||
<Para>
|
||
For the sake of simplicity and sanity, let's clarify some of the terminology
|
||
that we will be using in this document, so that we are all on the same page.
|
||
While many of the definitions below are not always 100% technically correct,
|
||
they are close enough for our purposes here. In fast moving technologies like
|
||
DSL, there are so many <Quote>ifs, ands, and buts</Quote> that it is
|
||
difficult to say anything with any degree of certainty and have it stick. And
|
||
there are exceptions to almost every rule. And sometimes exceptions to the
|
||
exceptions. We will be dealing with generalities to a large degree here,
|
||
please keep that in mind.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Quote>DSL</Quote> will be used to refer to the entire family of DSL
|
||
technologies now available -- ADSL, SDSL, IDSL, RADSL, etc. ADSL still
|
||
seems to be the most prevalent at this time, but the others are being
|
||
deployed as well. Where it is important to differentiate one type of
|
||
DSL from another, the full proper name will be used: e.g. RADSL. xDSL is
|
||
also commonly used to refer to the various DSL technologies as a group, but
|
||
we will be using just <Quote>DSL</Quote> here.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The term <Quote>telco</Quote> here refers to any potential DSL provider.
|
||
This includes the ILECs (Incumbent Local Exchange Carriers), a.k.a. the old
|
||
guard phone companies or state run phone companies, and where the
|
||
monopolies now have competition, the CLECs (Competitive Local Exchange
|
||
Carriers), or independent providers such as Covad in the U.S.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Quote>CO</Quote> is the telco acronym for <Quote>Central Office</Quote>.
|
||
Traditionally this is a building where one end of your phone line
|
||
physically terminates. The other end terminates at your home, office, or
|
||
wherever. It will be used here to refer to the telco end termination point,
|
||
regardless of whether it is a traditional Central Office building or
|
||
another, smaller, remote structure or device.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Quote>Loop</Quote> is telco speak for <Quote>phone line</Quote>.
|
||
Essentially, you should think of your loop as one dedicated pair of copper
|
||
wires that run uninterrupted from your residence or office directly to the
|
||
CO. This is perhaps an oversimplification, but will serve our purposes. DSL
|
||
availability, and signal quality, is tied directly to the characteristics
|
||
of your physical line -- or <Quote>loop</Quote> as they say.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<quote>POTS</quote> is the acronym for Plain Old Telephone Service. In other
|
||
words, traditional, non-digital devices like analog phones, faxes and answering
|
||
machines. ISDN is used for DSL in some areas, so POTS is not the only way
|
||
to piggy-back DSL. But certainly the most common in many places.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<quote>NID</quote>, or Network Interface Device, is the small telco
|
||
housing that is often typically attached to the outside wall of your house,
|
||
and is the service entrance for telco services, though may be placed
|
||
elsewhere depending on the phone company. This may variously also be
|
||
referred to as <quote>ONI</quote>, <quote>SNI</quote>, <quote>NIU</quote>,
|
||
<Quote>TNI</Quote> or other creative telco acronyms. It represents the
|
||
<quote>demarcation</quote> point that divides the customer's realm of
|
||
responsibility from the telco's. Commercial structures, and multi-family
|
||
housing will likely have something more sophisticated, and probably located
|
||
inside somewhere.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Quote>DSLAM</Quote> is the sophisticated hardware device in the telco's CO
|
||
where your phone line physically terminates, and thus makes DSL happen.
|
||
Increasingly, telcos are making use of smaller devices like the
|
||
<Quote>mini-RAM</Quote> in remote locations. We'll use <Quote>DSLAM</Quote>
|
||
here as a catch-all for any device that enables DSL service from a telco.
|
||
These are now being manufactured by a number of companies.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Quote>Modem</Quote> will be used to refer to the end user device that
|
||
enables a DSL connection. Your <quote>modem</quote> is connected to the
|
||
telco's DSLAM in the CO via your copper loop. When they are
|
||
<Quote>talking</Quote> DSL to each other, they are in <Quote>sync</Quote>.
|
||
Without <Quote>sync</Quote>, no connection to your ISP is possible.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<Quote>Modem</Quote> is indeed the correct terminology since there is
|
||
MOdulation and DEModulation of the signal, even though it doesn't
|
||
resemble an analog 56K modem like many of us have had before. These modems
|
||
incorporate other features too -- so they are more than just a
|
||
<quote>modem</quote>. Some ISPs and manufacturers may be marketing simply
|
||
<Quote>routers</Quote>, <Quote>bridges</Quote>, or even
|
||
<Quote>brouters</Quote> for this purpose. These are essentially DSL modems
|
||
with enhancements. A compatible <Quote>modem</Quote> of some kind is the
|
||
minimum hardware requirement at the customer's end of the connection. The
|
||
most commonly supplied modem is actually a combination bridge and modem.
|
||
</Para>
|
||
<para>
|
||
One distinction here may be where ADSL is provided over ISDN lines. In this
|
||
case, the term <quote>modem</quote> is not appropriate and the only
|
||
physical difference is that the ISDN Network Terminator (NT), is equipped
|
||
to handle DSL, but is still an NT. In any case, for brevity, we will take
|
||
license here to refer to all such devices as <quote>modems</quote>.
|
||
</para>
|
||
|
||
<Para>
|
||
Unless stated otherwise, we will also be assuming the <Quote>modem</Quote>
|
||
has an ethernet interface, and will connect to a standard ethernet Network
|
||
Card (NIC). This is far and away the most prevalent configuration for Linux
|
||
users, at least until more Linux drivers are available for PCI and USB
|
||
modems. USB modem are quite popular otherwise, because they are
|
||
<quote>plug 'n play</quote>, and arguably less expensive.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
It is worth noting that <Quote>routers</Quote> as supplied by DSL providers
|
||
are typically modem/router combination devices. In our context,
|
||
<Quote>router</Quote> will refer to these devices as such. There are also
|
||
SOHO broadband routers available that are only dedicated routers and lack
|
||
the modem functionality.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Previous versions of this document referred to the modem as an
|
||
<Quote>ANT</Quote> (ADSL Network Termination). While this may be
|
||
technically correct terminology, it is not used by ISPs, manufacturers,
|
||
telcos, or most users to any extent. The <Quote>modem</Quote> will be just
|
||
called a modem, regardless of whatever other features it may incorporate (i.e.
|
||
router, bridge, etc.).
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
PPPoX will be used to refer to PPPoE (PPP over Ethernet) and PPPoA
|
||
(PPPoATM, or PPP over ATM) collectively. These protocols are being used by
|
||
many DSL providers now.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The information provided in this document is based mostly on the current
|
||
state of DSL in the U.S. I will assume there are enough similarities with
|
||
DSL services outside of the US that this document would still have some
|
||
merit for everyone. Correct me if I am wrong by emailing
|
||
<email>hal@foobox.net</email>.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
A <Quote>#</Quote> will be used to denote a command that typically is run
|
||
by the root user. Otherwise, a <Quote>$</Quote> will be used as the prompt
|
||
for non-root users.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
</Sect1>
|
||
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
||
|
||
<Sect1 id="installation">
|
||
<Title>Installation</Title>
|
||
|
||
<Para>
|
||
Before actually ordering service, there are several things you may want to
|
||
explore. Please note, that there are many ways any given telco might
|
||
decide to handle qualification and installation procedures. Much of what
|
||
is described in this section, is how it is commonly done in the U.S.
|
||
|
||
</Para>
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
<Sect2>
|
||
<Title>Pre-Installation</Title>
|
||
|
||
<Para>
|
||
In many parts of the world, there is no choice on who you get DSL from: your
|
||
friendly local telco, of course! They own the copper wires, and thus they
|
||
hold all the cards.
|
||
</Para>
|
||
|
||
<Para>
|
||
However, in the U.S. de-regulation has opened this up somewhat. Beyond the
|
||
obvious consideration of price, there are reasons to investigate which
|
||
alternate providers may be offering DSL services in your area. The large
|
||
Telephone companies are everywhere, and may advertise the most. But
|
||
increasingly smaller ISPs and independents are getting into the act. This has
|
||
created some diversity in the DSL marketplace. A good thing of course, but
|
||
possibly creating a little confusion too. Conversely, in areas where there
|
||
is only one choice, then we have no choice but to accept whatever service
|
||
is being offered.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
If your telco has a monopoly on phone service and DSL, you may skip the
|
||
rest of this section. And probably the next few sections. They will probably
|
||
control the installation and qualification processes, and you just wait
|
||
for them to get finished.
|
||
</Para>
|
||
|
||
<Para>
|
||
Not all DSL services are alike. Just because two local companies are offering
|
||
<Quote>ADSL</Quote>, does not mean that necessarily there is much in common
|
||
at all. In fact, there are potentially a number of factors that make one ADSL
|
||
provider's service significantly different from another's. Some things to
|
||
consider:
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Speed vs Price.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
What hardware is provided, i.e. modem or router. It is best if this is
|
||
external ethernet in either case.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The ISP's Network architecture. PPPoX? Static IP? Servers allowed?
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Is it an <Quote>always on</Quote> service, at least theoretically? Are
|
||
there supplemental usage fees, or idle timeouts?
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Linux friendly, Linux hostile, or Linux agnostic? This is not as much of
|
||
a problem as it used to be in most areas. Some providers are still very
|
||
restrictive on allowing <quote>servers</quote>, and possibly even
|
||
LAN connections. Buyer beware. Talk to other users, and read their
|
||
TOS (Terms of Service) to get a feel for their attitude.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Quality of service. How is news, mail, etc.? News particularly seems
|
||
to be inconsistent with low-end broadband providers. Probably because
|
||
of the dramatic increase in binary news content, which is compounded by the
|
||
higher bandwidth and increased usage of such groups.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
<Para>
|
||
For a more lengthy discussion on some of these considerations and related
|
||
issues, see the <Link LinkEnd="overview">DSL Overview</Link> appendix for
|
||
more on <Link LinkEnd="dslmodems">modems</Link>,
|
||
<Link LinkEnd="qualify">qualifying for service</Link>, and
|
||
<Link LinkEnd="cproviders">choosing a provider</Link>.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Once you have chosen a provider, and ordered service, the next step is for
|
||
the telco to <Quote>qualify</Quote> your loop. This essentially means testing
|
||
your line to make sure it can handle the DSL signal, and possibly what level
|
||
of service may be available to you. This may take some time, especially if
|
||
the telco encounters problems with the loop. If no problems are found during
|
||
this phase, then possibly there will be a one to three week wait for the
|
||
installation. YMMV.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
After the telco has qualified the loop and readied their end of the
|
||
connection, the next step is installation of the necessary components at the
|
||
customer's end of the connection: wiring modifications, splitter or filters,
|
||
and, of course the modem and any necessary software.
|
||
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Installation Options -- Self Install or Not</Title>
|
||
|
||
<Para>
|
||
You may or may not have a choice on how the installation is done, or who
|
||
does it. This is totally at the discretion of the provider. In much of the
|
||
world, this is done by the telco, and there is little flexibility. Many
|
||
providers in the U.S. offer a <Quote>self install</Quote> option where you do
|
||
all the work. In this scenario, the provider will send a kit in order to save
|
||
them from sending a tech, and thus reducing cost. Typically, self install
|
||
kits will include microfilters for the POTS (Plain Old Telephone Service)
|
||
or ISDN (where ADSL over ISDN is used) phone jacks, the modem (and
|
||
maybe a NIC), and a CDROM with drivers, etc. on it. In some cases, a splitter
|
||
may be included instead of microfilters. In any case, some type of filtering
|
||
is necessary on the non-DSL lines. If not the noise generated by the DSL
|
||
signal may interfere with regula telco devices such as phones and answering
|
||
machines.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The other possibility is for the provider to do the installation. Again, this
|
||
may be your only option. Obviously, the cost is higher here, but it may have
|
||
the advantage of having a trained tech do any wiring. There is also a better
|
||
chance of getting a <quote>splittered</quote> installation with this option
|
||
(a good thing!). Another benefit is that if something is wrong with the line,
|
||
or the telco has not provisioned the line properly, an on-site tech may be
|
||
able to help sort out certain kinds of problems quickly.
|
||
</Para>
|
||
|
||
<Para>
|
||
The self-install kit should come with full instructions, regardless of whether
|
||
the installation will be splittered or filtered. So we won't go into much
|
||
detail on this aspect.
|
||
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Wiring/Installation Options</Title>
|
||
|
||
<Para>
|
||
There are various wiring schemes depending on how your service is being
|
||
provided, who is providing it, and which DSL service is being provided.
|
||
If your telco is performing the installation, you may skip this section.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Dedicated Line</Emphasis>. Some DSLs require a dedicated, or
|
||
<Quote>dry</Quote>, wire pair, e.g. IDSL. This means a separate, physical
|
||
line without dial-tone for DSL and Internet connectivity. Also, DSL
|
||
services from CLECs (independent telcos like Covad), may use a
|
||
dedicated line, depending on their line sharing agreement with the local
|
||
incumbent carrier. (Instead the CLEC will actually lease a loop from the
|
||
ILEC.) On your end, this simply means using one of the unused wire pairs
|
||
in the telco wire bundle, and connecting it to the DSL jack.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Shared Line with Splitter</Emphasis>. For DSLs like ADSL, that
|
||
are provided over the same line as regular voice service, the signal
|
||
must be filtered somehow so that voice services are not adversely effected.
|
||
Installing a splitter splits the line into two pairs, and filters the DSL
|
||
signal from one of them. This results in a inside wiring scheme where DSL
|
||
goes to only one jack, and then regular voice type service to all other
|
||
jacks. This is considered by many to be a better type of installation than
|
||
<Quote>splitterless</Quote>, i.e. with microfilters instead. See below.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Splitters are available from various manufacturers and come in various
|
||
shapes and sizes. Some are small enough to fit in the NID itself (sometimes
|
||
called SNI, this is the telco phone box on the outside of your house),
|
||
while others have a housing as large as the NID itself. Typically this is
|
||
mounted near the NID, on the customer's side of the demarcation point.
|
||
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Shared Line with Filters</Emphasis>. Again, for some DSLs that
|
||
piggyback on the POTS (or ISDN) line, the signal must be filtered or split at some
|
||
point. This is not necessary for g.lite or RADSL however. The other way of
|
||
doing this is by placing RJ11 <Quote>microfilters</Quote> in each phone
|
||
jack -- <Emphasis>except where the DSL modem will be</Emphasis>. These
|
||
filters are relatively small, plug-in devices and remove the higher
|
||
frequencies associated with DSL. This is obviously much easier since no
|
||
tools or wiring is required. This is often what is included in self-install
|
||
kits, and is often referred to as a <Quote>splitterless</Quote>
|
||
installation. This is a very common approach in the U.S. Note that
|
||
in areas where ADSL over ISDN is provided, filtering is required
|
||
also, but the filters themselves are quite different and are not
|
||
interchangeable with POTS filters!
|
||
</Para>
|
||
<Para>
|
||
Similar microfilters are sometimes used by some telcos to reduce the
|
||
excessive <Quote>whine</Quote> on the line that is produced by some modems.
|
||
This is a little different approach as the filter is put on the same
|
||
jack as the modem.
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Shared Line, Splitterless and Filterless</Emphasis>. Some newer
|
||
DSLs, like G.Lite, have no adverse effect on regular POTS devices and thus
|
||
require no filters or splitters. This would seem to be the wave of the
|
||
future. Just plug and play. Though still not very common.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
|
||
</Para>
|
||
|
||
<BridgeHead renderas=sect3>
|
||
Figure 1: DSL Block Diagram with Splitter (NID not shown)
|
||
</BridgeHead>
|
||
|
||
<Para>
|
||
<Literal>
|
||
<MSGText>
|
||
<LiteralLayout>
|
||
|
||
<--------Home/Office-----><---Loop---><--Central Office-->
|
||
|
||
POTS X-------+
|
||
phone, |
|
||
fax, |
|
||
etc, |
|
||
| CO
|
||
| -------
|
||
| | |
|
||
| | |
|
||
| ----- | |
|
||
POTS X-------+----Voice--=| S | | D |
|
||
| P | | S |=- Voice Switch
|
||
| L | 2 wire | L |
|
||
| I |=------------=| A |
|
||
| T | Local Loop | M |=- ISP --> INET
|
||
--------- | T | | |
|
||
Linux X--=| Modem |=-Data-=| E | | |
|
||
--------- | R | | |
|
||
----- | |
|
||
-------
|
||
|
||
</LiteralLayout>
|
||
</MSGText>
|
||
</Literal>
|
||
</Para>
|
||
|
||
<BridgeHead renderas=sect3>
|
||
Figure 2: DSL Splitterless (a.k.a. filtered) Block Diagram
|
||
</BridgeHead>
|
||
|
||
<Para>
|
||
<Literal>
|
||
<MSGText>
|
||
<LiteralLayout>
|
||
|
||
<--------Home/Office-------><----Loop---><--Central Office-->
|
||
|
||
|
||
POTS X--Voice---[RJ11]------+
|
||
phone, (filter) |
|
||
fax, D CO
|
||
etc, a -------
|
||
t | |
|
||
a | |
|
||
POTS X--Voice---[RJ11]----- & | D |
|
||
(filter) V ----- | S |=- Voice Switch
|
||
o | N | 2 wire | L |
|
||
i-=| I |=-----------=| A |
|
||
c | D | Local Loop | M |=- ISP --> INET
|
||
e ----- | |
|
||
----------- | | |
|
||
Linux X--=| Modem |=-------| | |
|
||
----------- -------
|
||
|
||
|
||
</LiteralLayout>
|
||
</MSGText>
|
||
</Literal>
|
||
</Para>
|
||
|
||
|
||
</Sect2>
|
||
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="wiring">
|
||
<Title>Self Install - Wiring</Title>
|
||
|
||
<Para>
|
||
If you are not doing a self-install, then you may skip this section
|
||
and move to <Link LinkEnd="configure">Configuring Linux</Link>. If you are
|
||
doing a self-install with microfilters, skip to the
|
||
<Link LinkEnd="micro">mircofilter section</Link>. The following procedures
|
||
are meant to illustrate the wiring process. Please note that your procedures
|
||
may be different at your location. Make sure you follow any warnings or
|
||
safety instructions provided, that you RTFM, and that you are familiar with
|
||
telco wiring procedures.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The first step will be to wire up the connections from your provider. Identify
|
||
the line on which service will be installed, and the locations of your
|
||
splitter and DSL jack(s). (For perhaps a better wiring scheme, see the
|
||
Homerun section immediately below.)
|
||
</Para>
|
||
|
||
<Para>
|
||
Be aware that typical telco wire has more than one pair per bundle. Often,
|
||
two pairs, but sometimes more. If you have but one phone line, the other
|
||
pair(s) are unused. This makes them available for use with wiring for DSL.
|
||
Wire pairs are color coded for easy identification. SDSL and IDSL require a
|
||
dedicated, or <Quote>dry</Quote>, pair. If an unused pair is available, then
|
||
no real re-wiring is required. It is just a matter of re-wiring an existing
|
||
jack for the correct pair of wires, and attaching the modem.
|
||
|
||
</Para>
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3 id="homerun">
|
||
<Title>The Homerun</Title>
|
||
|
||
<Blockquote>
|
||
<attribution>A retired BellSouth ADSL installer</attribution>
|
||
<Para>
|
||
<quote>
|
||
<emphasis>
|
||
I would not use microfilters if I lived across the street from my CO. A
|
||
splitter is the only way to go.
|
||
</emphasis>
|
||
</quote>
|
||
</Para>
|
||
</Blockquote>
|
||
|
||
|
||
<Para>
|
||
The optimum method of wiring for the DSL modem is sometimes
|
||
called a <Quote>homerun</Quote>. It is called this because it is one,
|
||
straight shot from the splitter to the modem's DSL jack. What this does is
|
||
bypass the existing inside wiring altogether, and any problems that might be
|
||
lurking there -- like a corroded connection somewhere on a voice jack. Inside
|
||
wiring deficiencies can cause a degradation of the DSL signal.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
This also allows you to route the cable to avoid any potential
|
||
RFI (Radio Frequency Interference) sources. RFI anywhere in the
|
||
circuit can be a DSL killer. Routing the cable away from items that
|
||
may have electric motors, transformers, power supplies, high
|
||
intensity lighting fixtures, dimmer switches and such, is a smart way
|
||
to go. And you are also less likely to have a failing microfilter
|
||
cause problems -- one potential point of failure instead of several. You can
|
||
also use a better grade of cable such as CAT 5.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
If your existing installation is <quote>splitterless</quote> (i.e. using
|
||
microfilters) now, converting to a homerun will entail purchasing a splitter.
|
||
And, of course, will also mean some new wiring will need to be run.
|
||
Microfilters also add to the effective loop length -- as much as 700 ft per
|
||
filter in some cases! So if you have several microfilters installed, and your
|
||
sync rate or distance is marginal, eliminating these filters may result in a
|
||
significant improvement.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
A poor man's splitter can be rigged by using a microfilter inside the NID.
|
||
This is not <quote>by the book</quote>, but seems to work just fine for many.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Wire the Splitter</Title>
|
||
|
||
<Para>
|
||
If you have the splitterless design (i.e. using <Quote>microfilters</Quote>)
|
||
or a dedicated line, you may skip this part.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The splitter will typically consist of two parts, the splitter and a small
|
||
outdoor housing. Mount the splitter and accompanying housing per the telco's
|
||
instructions at the Network Interface Device (NID) point (also sometimes
|
||
called the SNI or ONI), usually the side of your house where the phone line
|
||
is located. Put it on your side of the NID. The phone company may need
|
||
to access the splitter for maintenance, so its advisable to locate it on the
|
||
outside where they can get at it, but outside is not absolutely
|
||
necessary.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The wire bundle should have at least two separate wire pairs. The splitter
|
||
takes one pair, and separates the signal onto two pairs. One pair in the
|
||
bundle will then go to all phone jacks, and the other to the modem's DSL wall
|
||
jack. So connect the incoming telco line to the LINE side of the splitter.
|
||
Then wire the inside pair for your telephone to the VOICE, and your inside
|
||
wire pair for the modem to DATA.
|
||
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
<Emphasis remap="bf">Checkstep </Emphasis> At this point, you should be able
|
||
to pull dial tone off the voice side of the splitter. If this doesn't work,
|
||
then you've wired it wrong. You can also plug the modem into the test jack in
|
||
the NID box (most should have this). Plug in the modem's power cord, and
|
||
if the line is provisioned correctly, you should <Quote>sync</Quote> in less
|
||
than a minute. This test only requires the modem. (Internal and USB modems
|
||
will require a driver to be loaded before syncing. This would mean having the
|
||
computer there too.)
|
||
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Wire the DSL Jack</Title>
|
||
|
||
<Para>
|
||
Wire the DSL wall jack (RJ11) at your computer location, which should already
|
||
be connected to the DATA side of the splitter. The specifics differ for each
|
||
situation, but basically you will have a wire pair that you will connect to
|
||
the DSL jack. Make sure you <Emphasis>read the directions</Emphasis>, as the
|
||
DSL-RJ11 wiring may be different for phones and DSL jacks.
|
||
<Emphasis>AND</Emphasis> -- different modems may expect the signal on
|
||
different pairs -- most on the inside pair, but some on the outside pair.
|
||
|
||
</Para>
|
||
|
||
<BridgeHead renderas=sect3>
|
||
Figure 3: RJ11 Wiring options
|
||
</BridgeHead>
|
||
|
||
<Para>
|
||
<Literal>
|
||
<MSGText>
|
||
<LiteralLayout>
|
||
|
||
||
|
||
||
|
||
||
|
||
/ \
|
||
|RJ11|
|
||
| |
|
||
----
|
||
||||
|
||
|
||
^^ <-- Inside Most modems on inside pair
|
||
^ ^ <-- Outside Some on outside, e.g. Alcatel 1000, SpeedTouch Home
|
||
|
||
</LiteralLayout>
|
||
</MSGText>
|
||
</Literal>
|
||
</Para>
|
||
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id='micro'>
|
||
<Title>Installing Microfilters</Title>
|
||
|
||
<Para>
|
||
Pretty much a no-brainer here. If you are doing a
|
||
<Quote>splitterless</Quote>, self-install installation, then install the
|
||
provided microfilters in all phone jacks <Emphasis>except</Emphasis> the one
|
||
where the DSL modem will be connected. Don't forget devices like fax machines
|
||
and analog modems. The filters filter out the higher DSL frequencies and will
|
||
keep the DSL noise from interfering with POTS (or ISDN) equipment.
|
||
</Para>
|
||
|
||
<Para>
|
||
<Emphasis>Warning!</Emphasis>
|
||
Alarm systems can present various problems, depending on the type of alarm
|
||
and how it is installed. This may require telco help for proper installation
|
||
so the one does not interfere with the other. Common microfilters tend not to
|
||
work because most alarm boxes use a different size jack. Filters are now
|
||
available just for alarm boxes, though traditionally this has been handled
|
||
with a splitter type installation.
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Installing an Ethernet Modem</Title>
|
||
|
||
<Para>
|
||
To install, connect the modem's (or router's) power cord, and connect
|
||
the phone line between the DSL wall jack and the modem. This cable should be
|
||
provided. If not, a regular phone cord will suffice. With the ethernet
|
||
interfaced modems, you may also connect the ethernet cable between the NIC
|
||
and the modem (but not really necessary at this point just to verify an
|
||
ethernet modem is working).
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<Emphasis remap="bf">Checkstep </Emphasis> At this point, verify that
|
||
the modem syncs with the telco's DSLAM signal. Most modems have a
|
||
green LED that lights up when the signal is good, and red or orange
|
||
if not in sync. The modem's manual will have more details on the
|
||
LEDs. If it doesn't sync, then check your wiring, or make sure that
|
||
the DSL signal is being sent. Do this by calling your telco and
|
||
verifying they have activated the service. Or by testing the modem at
|
||
the test jack on the NID (see above). Note that having dial tone
|
||
on the line does NOT confirm the presence of the DSL data signal. And
|
||
vice versa -- perfectly possible to have dial tone and no DSL, or DSL
|
||
and no dial tone. There should also be no static or noise on the
|
||
voice line when everything is installed and functioning properly.
|
||
|
||
</Para>
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>Installing the Ethernet Network Card (NIC)</Title>
|
||
|
||
<Para>
|
||
Ethernet modems will, of course, require an ethernet network card.
|
||
If you haven't already done so, install the NIC in your Linux machine,
|
||
configure the kernel, or load modules, etc., etc. This is sometimes the
|
||
biggest stumbling block -- getting the NIC recognized and working. See the
|
||
various Linux references for doing this, such as the <Ulink
|
||
url="http://www.tldp.org/HOWTO/Ethernet-HOWTO.html">Ethernet
|
||
HOWTO</Ulink> for more information. Also, see the <Link
|
||
LinkEnd="tuning">Troubleshooting Section</Link> below. This is certainly
|
||
something you could conceivably do ahead of time if you already have the NIC.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Be sure the RJ45 cable between the NIC and the modem is now connected. You
|
||
can <quote>hot plug</quote> this cable, meaning there is no need to power
|
||
down to do this.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
We can do a few quick tests now to see if the NIC seems to be functioning
|
||
properly. First we'll attempt to bring up the interface. Then we'll see how
|
||
well it is responding by <Command>pinging</Command> it. And lastly use
|
||
<Command>ifconfig</Command> to check for errors:
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
# ifconfig eth0 10.0.0.1 up
|
||
|
||
|
||
$ ping -c 50 10.0.0.1
|
||
PING 10.0.0.1 (10.0.0.1) from 10.0.0.1: 56(84) bytes of data.
|
||
64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.2 ms
|
||
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.2 ms
|
||
64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=0.1 ms
|
||
<snip>
|
||
|
||
- 10.0.0.1 ping statistics -
|
||
50 packets transmitted, 50 packets received, 0% packet loss
|
||
round-trip min/avg/max = 0.1/0.1/0.2 ms
|
||
|
||
|
||
$ ifconfig eth0
|
||
eth0 Link encap:Ethernet HWaddr 00:50:04:C2:09:AC
|
||
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0
|
||
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
||
RX packets:428 errors:0 dropped:0 overruns:0 frame:0
|
||
TX packets:421 errors:0 dropped:0 overruns:0 carrier:0
|
||
collisions:0 txqueuelen:100
|
||
Interrupt:10 Base address:0xc800
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
If <Quote>eth0</Quote> comes up without errors, and you can
|
||
<Command>ping</Command> it without errors, and <Command>ifconfig</Command>
|
||
shows no errors, we most likely have all our hardware in working order now, and
|
||
are ready to start configuring Linux. If not, see the <Link
|
||
LinkEnd="tuning">Troubleshooting section</Link> below.
|
||
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
<Emphasis remap="bf">Gotcha:</Emphasis> A few modems may already be wired as
|
||
a 10baseT crossover, and require a direct Category 5 cable for a direct
|
||
connection to a NIC, rather than a crossover cable. I lost around 12 hours
|
||
figuring this one out, so don't make the same mistake - make sure you RTFM
|
||
first.
|
||
</Para>
|
||
|
||
|
||
</Sect3>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Installing a USB Modem</Title>
|
||
|
||
<Para>
|
||
The physical installation of a USB modem is similar to an ethernet modem.
|
||
There is no ethernet card necessary obviously. So connect the phone
|
||
line between the DSL wall jack and the modem's DSL port, and attach the
|
||
USB cable to the computer's USB port.
|
||
</Para>
|
||
|
||
<Para>
|
||
USB modems will require vendor and model specific drivers in order to sync
|
||
and function properly. Assuming you are using the Alcatel SpeedTouch USB,
|
||
this will require both a binary firmware driver available from Alcatel's
|
||
driver page: <Ulink
|
||
URL="http://www.speedtouchdsl.com/support.htm">http://www.speedtouchdsl.com/support.htm</Ulink>,
|
||
and a separate modem driver.
|
||
</Para>
|
||
|
||
<Para>
|
||
This driver also supports both PPPoE and PPPoA, though the steps for getting
|
||
either to work are quite different. See the
|
||
<Link LinkEnd="SpeedtouchUSB">Appendix</Link> for more on this modem.
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
The Eci Hi Focus ADSL Modem has some support in Linux now too. See
|
||
<ulink url="http://eciadsl.sourceforge.net/">http://eciadsl.sourceforge.net/</ulink>.
|
||
</para>
|
||
</Sect2>
|
||
|
||
</Sect1>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
||
|
||
|
||
<Sect1 id="configure">
|
||
<Title>Configuring Linux</Title>
|
||
|
||
<Para>
|
||
After you have connected the modem and it's getting sync, then you're ready
|
||
to configure Linux and verify your connection to your ISP. Although I will
|
||
refer to a Linux System, you could conceivably connect any type of 10baseT
|
||
device to the modem. This includes a router, hub, switch, PC, or any other
|
||
system that you wish to use. We'll just cover the Linux aspects here.
|
||
|
||
</Para>
|
||
|
||
<Warning>
|
||
<Para>
|
||
|
||
<Emphasis>Before you connect to your ISP</Emphasis>, make sure you understand
|
||
all security issues of having a direct connection to the Internet via DSL.
|
||
Depending on your ISP, most outside users can access your system, and you
|
||
should setup any firewalls, deactivate ports/services, and setup any
|
||
passwords prior to connecting your machine to the world. See the <Link
|
||
LinkEnd="secure">Security section below</Link>, and the <Link
|
||
LinkEnd="links">links section</Link> for more on this <Emphasis>very
|
||
important</Emphasis> topic. Do not make this an afterthought! Be ready.
|
||
|
||
</Para>
|
||
</Warning>
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="bridgevsppp">
|
||
<Title>Bridged vs PPPoX Networks</Title>
|
||
|
||
<Para>
|
||
Before we get too far into the final stages of installing and
|
||
configuring our system, let's look at how various DSL ISPs set up
|
||
their networks. It will be very important for you to know how your ISP does
|
||
this, as there is more than one possibility and the steps involved are quite
|
||
different for each. This may not be the kind of thing the ISP is advertising,
|
||
and since you are not using Windows, you may not have access to the setup
|
||
disk that the ISP provides. If you're not sure, ask the ISP's tech support
|
||
staff, or better, find other knowledgable users of the same service.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
To muddy the waters even more, some ISPs may be offering more than one kind
|
||
of service (over and above the various bit rate plans). Example: Verizon
|
||
(formerly Bell Atlantic) originally offered static IPs with a Bridged
|
||
connection. Now all new installs use PPPoE with dynamic IPs. For installation
|
||
and configuration purposes, this is very different.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The two most common DSL network implementations are Bridged/DHCP and PPPoX.
|
||
Both have mechanisms for obtaining an IP address and other related networking
|
||
configuration details so we shouldn't have to worry about this. But there are
|
||
indeed other, less common, means of connecting. Our job will be finding the
|
||
right client, and doing what we have to, to get it up and running. The most
|
||
common ones are discussed below.
|
||
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
<Emphasis>Important!</Emphasis> You need to know beforehand how your ISP is
|
||
setup for connecting to his network. To re-iterate, the two main
|
||
possibilities are Bridged/DHCP and PPPoE. These are mutually exclusive
|
||
implementations. And there are indeed other possibilities as well. So you will
|
||
need to know exactly what this is beforehand. And it must be the right one or
|
||
you will waste a lot of time and effort. You cannot choose which one either.
|
||
It is a matter of how the ISP is doing his network. Note that PPPoE can run
|
||
over Bridged networks, so just knowing whether you are Bridged or not, is not
|
||
necessarily good enough. If your provider is giving you a router, there is a
|
||
good chance that the router's firmware will handle all of this for you.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
If you are subscribing with one of the Baby Bells in the U.S., you can
|
||
count on that being PPPoE, and thus you will need a PPPoE client.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
There are a few provider specific FAQs and HOWTOs in the <Link
|
||
LinkEnd="links">Links section</Link> below.
|
||
|
||
</Para>
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
<Sect3>
|
||
<Title>Bridged/DHCP</Title>
|
||
|
||
<Para>
|
||
In the good old days of a year or two ago, purely <Quote>Bridged</Quote>
|
||
connections were the norm. PPPoE had not been invented yet. This type of
|
||
network puts you on a local subnet just like a big LAN. You are exposed to
|
||
much of the local subnet traffic, especially ARP and broadcast traffic. The
|
||
typical means of authenticating in this set up, is via DHCP.
|
||
</Para>
|
||
|
||
<Para>
|
||
DHCP is a standard, established networking protocol for obtaining an IP
|
||
address and other important network parameters (e.g. nameservers). This is a
|
||
standard, well documented networking scheme and is very easy to set up
|
||
from the end user's perspective. It is also a very stable connection. You
|
||
can actually unplug the modem for say 10 minutes, plug it back in, let it
|
||
re-sync, and the connection is still there -- same IP and everything.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>PPPoX</Title>
|
||
|
||
<Para>
|
||
The main alternative now is PPPoX, meaning either PPPoE (PPP over Ethernet)
|
||
or PPPoA (PPP over ATM, aka PPPoATM). Both of these related protocols are
|
||
currently being deployed, but at the moment, PPPoE seems to be the more
|
||
common of the two. PPPoX is a relative newcomer, and, as the name implies, is
|
||
a variation of Point-to-Point Protocol that has been adapted specifically for
|
||
DSL networks.
|
||
</Para>
|
||
|
||
<Para>
|
||
There are several PPPoE clients for Linux (<Link LinkEnd="pppoe">see
|
||
below</Link>). PPPoX simulates a dialup type environment. The user is
|
||
authenticated by user id and password which is passed to a RADIUS server,
|
||
just like good ol' dialup PPP. A routable IP address, and other related
|
||
information, is returned to the client. Of course, no actual dialing takes
|
||
place. The mechanics of how this is handled, will vary from client to client,
|
||
so best to RTFM closely. Typically you will set up configuration files like
|
||
<Filename>pap-secrets</FileName>, etc.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
It is worth noting that PPPoE will also work on non-ethernet devices like USB,
|
||
provided the correct drivers are installed.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
From the ISPs perspective, PPP is much easier to maintain and troubleshoot.
|
||
From the end user's perspective, it is often more work to set up, often uses
|
||
more CPU, and the connection is maybe not as stable. So anyway, this seems to
|
||
be the coming trend. Many of the large telcos around the world, especially
|
||
the RBOCs (Baby Bells) in the U.S., have committed to PPPoX already. Setting
|
||
up a PPPoX connection is completely different from setting up a bridged/DHCP
|
||
connection.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>ATM</Title>
|
||
|
||
<Para>
|
||
Since the traffic on the wire from the DSLAM to the modem is typically ATM, a
|
||
raw ATM connection would seem to make sense. While possible, this is rare, if
|
||
it exists at all in the U.S, and would require a modem in addition to a PCI
|
||
ATM card, such as the Efficient Networks 3010. Recent 2.4 kernels
|
||
do have ATM support. (See the <Link LinkEnd="links">Links section</Link> for
|
||
more information.)
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
This may be a viable solution at some point, but it is just not
|
||
<Quote>there</Quote> yet, mostly because this is more costly to implement.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Configuring the WAN Interface</Title>
|
||
|
||
<Para>
|
||
The most common configuration is a DSL modem in <Quote>bridging</Quote> mode.
|
||
Both PPPoX and DHCP can use this setup. In this scenario, the WAN interface
|
||
typically means your NIC. This is where your system meets the outside world.
|
||
(If you have a router see <Link LinkEnd="router">below</Link> for router
|
||
specific instructions.) So essentially we will be configuring the NIC,
|
||
typically <Quote>eth0</Quote> since it is an ethernet interface.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
With PPPoX, once the connection comes up, there will be a
|
||
<Quote>ppp0</Quote>, or similar, interface, just like dialup. This will
|
||
become the WAN interface once the connection to the PPP server is up, but for
|
||
configuration purposes we will we be concerned with <Quote>eth0</Quote>
|
||
initially.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
There are various ways an ISP may set up your IP connection:
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Static IP.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Dynamic IP on Bridged Network via DHCP.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Dynamic IP via PPPoX.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Static IP via PPPoX.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
<Para>
|
||
Let's look at these individually.
|
||
|
||
</Para>
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>Static IP Configuration</Title>
|
||
|
||
<Para>
|
||
A <Quote>static</Quote> IP address is an IP that is guaranteed not to change.
|
||
This is the preferred way to go for those wanting to host a domain or run
|
||
some type of public server, but is not available from all ISPs. Note that
|
||
while there are some noteworthy benefits to having a static IP, the
|
||
disadvantage is that is more difficult to remain <quote>invisible</quote>. It
|
||
is harder to hide from those with malicious intentions. Skip this section if
|
||
you do not have a static IP, or if you have a router, and the router will be
|
||
assigned the static IP.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Configure the IP address, subnet mask, default gateway, and DNS server
|
||
information as provided by the ISP. Each Linux Distribution (Redhat, Debian,
|
||
Slackware, SuSE, etc.) has a different way of doing this, so check on your
|
||
distro's docs on this. Each may have their own tools for this. Redhat has
|
||
<Command>netcfg</Command> for example. You can also do this manually using
|
||
the <Command>ifconfig </Command> and <Command>route</Command> commands. See
|
||
the man pages on these or the <Ulink
|
||
url="http://www.tldp.org/HOWTO/Net-HOWTO">Net HOWTO</Ulink> for more
|
||
information and specifics. A quick command line example with bogus IPs:
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
# ifconfig eth0 111.222.333.444 up netmask 255.255.255.0
|
||
# route add default gw 111.222.333.1 dev eth0
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
Be sure to add the correct nameservers in <Filename>/etc/resolv.conf</FileName>.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>Bridged/DHCP Configuration</Title>
|
||
|
||
<Para>
|
||
ISPs that have Bridged networks typically use DHCP to assign an IP addresses,
|
||
and authenticate the user. All distributions come with one or more DHCP
|
||
clients. <Command>dhcpcd</Command> seems to be the most common.
|
||
<Command>pump</Command> comes with Redhat based distributions as of Redhat
|
||
6.0. The DHCP client will obtain an IP <Quote>lease</Quote> from the ISP's
|
||
server as well as other related information: gateway address, DNS servers,
|
||
and network mask. The lease will be <Quote>renewed</Quote> at regular
|
||
intervals according to the ISP's configuration.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
You will want the DHCP client started on boot, so use your distribution's
|
||
means of doing this. There generally is little to configure with DHCP as it
|
||
is fairly straightforward and easy to use. You may need to tell it which
|
||
interface to listen on if the NIC is something other than
|
||
<Quote>eth0</Quote>. You can also start it from the command line to get
|
||
started. See the respective man pages for more.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Unless you have a static IP, the ISP will need some way to know who you are
|
||
when you connect. There are two ways this authentication process is
|
||
accomplished with DHCP. The first and most common method is via the MAC (or
|
||
hardware) address of the network device. Typically this would be the NIC. The
|
||
MAC address is a unique identifier and can be found among the boot messages,
|
||
or with <Command>ifconfig</Command>, and looks something like
|
||
<Literal>00:50:04:C2:19:BC</Literal>. You will need to give the ISP the MAC
|
||
address before your first connection.
|
||
</Para>
|
||
|
||
<Para>
|
||
The other DHCP authentication method is via an assigned hostname. In this
|
||
case, the ISP will have provided you with this information. Your DHCP client
|
||
will need to pass this information to the server in order for you to connect.
|
||
Both <Command>dhcpcd</Command> and <Command>pump</Command> accept the
|
||
<Quote>-h</Quote> command line option for this purpose. See the client's man
|
||
page, or your distribution's documentation, for specifics.
|
||
|
||
</Para>
|
||
|
||
<note><title>Note</title>
|
||
<Para>
|
||
If your ISP uses MAC address authentication, and you change your network
|
||
device (e.g. NIC), you will need to register the new address with the ISP or
|
||
you won't be able to connect.
|
||
|
||
</Para>
|
||
</note>
|
||
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3 id="pppoe">
|
||
<Title>PPPoE Configuration</Title>
|
||
|
||
<Para>
|
||
PPPoE (PPP over Ethernet) is an alternate way for ISPs to control your
|
||
connection, and is becoming increasingly popular with ISPs. Setting this up
|
||
is quite different, and may be a little more work than with static IPs or
|
||
DHCP above. Recent distro releases are now shipping PPPoE clients. If this is
|
||
not the case for you, then you will have to download one. Check any Linux
|
||
archive site like <Ulink
|
||
URL="http://freshmeat.net">http://freshmeat.net</Ulink>, etc. or look below.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Some of the current GPL PPPoE clients available:
|
||
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The Roaring Penguin (rp-pppoe): <Ulink
|
||
URL="http://www.roaringpenguin.com/pppoe/">http://www.roaringpenguin.com/pppoe/</Ulink>,
|
||
by David F. Skoll. Reportedly very easy to set up, and get started with.
|
||
This is a popular Linux PPPoE clients due to it's reputation for ease of
|
||
installation, and is now being bundled with some distributions. rp-pppoe
|
||
works as a user-mode client on 2.0 and 2.2 kernels, and in kernel-mode
|
||
on 2.4 kernels.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
PPPoEd: <Ulink URL="http://www.davin.ottawa.on.ca/pppoe/">
|
||
http://www.davin.ottawa.on.ca/pppoe/</Ulink> by Jamal Hadi Salim is
|
||
another popular Linux client and is also bundled with some
|
||
distros. This is a kernel based implementation for 2.2 kernels. A setup
|
||
script is now included so no patching is required, making installation
|
||
quick and easy. Also, less CPU intensive than user space alternatives like
|
||
rp-pppoe (2.0/2.2 kernels).
|
||
|
||
<Comment>
|
||
HB
|
||
jamal hadi@cyberus.ca pppoed author
|
||
|
||
very helpful on this part
|
||
|
||
"David F. Skoll" dfs at roaringpenguin.com
|
||
Some feedback too.
|
||
|
||
</Comment>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
PPPoE Redirector: <Ulink
|
||
URL="http://www.ecf.toronto.edu/~stras/pppoe.html">
|
||
http://www.ecf.toronto.edu/~stras/pppoe.html</Ulink>. This is a redirector
|
||
which allows the use of PPPoE with pppd-2.3.7 or later. No recompiling of
|
||
other system components are required. It is meant as an interim solution
|
||
until the 2.4.x series, which will include kernel support of PPPoE/A. (Does
|
||
not seem to be under active development at this time.)
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
|
||
<Para>
|
||
2.4.x kernels include native PPPoE support. The PPPoE for 2.4 page is
|
||
<Ulink
|
||
URL="http://www.shoshin.uwaterloo.ca/~mostrows/">http://www.shoshin.uwaterloo.ca/~mostrows</Ulink>
|
||
[link is dead, sorry, can't find new page] and is by Michal Ostrowski, the maintainer for kernel PPPoE. This
|
||
includes detailed instructions for installing and configuring kernel
|
||
mode PPPoE.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
EnterNet is a non-GPL'd PPPoE client from NTS, <Ulink
|
||
URL="http://www.nts.com">http://www.nts.com</Ulink>, that is being
|
||
distributed by some ISPs as the Linux client. It does come with
|
||
source code but the it is not available for free download. (I haven't
|
||
found anyone that is impressed by this one.)
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
Depending on which client you have chosen, just follow the
|
||
<Filename>INSTALL</FileName> instructions and other documentation included
|
||
with that package (<Filename>README</FileName>, <Filename>FAQ</FileName>, etc.).
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Once a PPPoE client connects, your connection should look something like the
|
||
below example from Roaring Penguin, where <Quote>eth0</Quote> is connected to
|
||
the modem:
|
||
</Para>
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
$ route -n
|
||
|
||
Kernel IP routing table
|
||
Destination Gateway Genmask Flags Metric Ref Use Iface
|
||
192.168.0.254 * 255.255.255.255 UH 0 0 0 eth1
|
||
208.61.124.1 * 255.255.255.255 UH 0 0 0 ppp0
|
||
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
|
||
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
|
||
default 208.61.124.1 0.0.0.0 UG 0 0 0 ppp0
|
||
|
||
|
||
$ ifconfig
|
||
|
||
eth0 Link encap:Ethernet HWaddr 00:A0:CC:33:74:EB
|
||
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
||
RX packets:297581 errors:0 dropped:0 overruns:0 frame:0
|
||
TX packets:266104 errors:1 dropped:0 overruns:0 carrier:2
|
||
collisions:79 txqueuelen:100
|
||
Interrupt:10 Base address:0x1300
|
||
|
||
eth1 Link encap:Ethernet HWaddr 00:A0:CC:33:8E:84
|
||
inet addr:192.168.0.254 Bcast:192.168.0.255 Mask:255.255.255.0
|
||
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
||
RX packets:608075 errors:0 dropped:0 overruns:0 frame:0
|
||
TX packets:578065 errors:0 dropped:0 overruns:0 carrier:0
|
||
collisions:105408 txqueuelen:100
|
||
Interrupt:9 Base address:0x1200
|
||
|
||
lo Link encap:Local Loopback
|
||
inet addr:127.0.0.1 Mask:255.0.0.0
|
||
UP LOOPBACK RUNNING MTU:3924 Metric:1
|
||
RX packets:1855 errors:0 dropped:0 overruns:0 frame:0
|
||
TX packets:1855 errors:0 dropped:0 overruns:0 carrier:0
|
||
collisions:0 txqueuelen:0
|
||
|
||
ppp0 Link encap:Point-to-Point Protocol
|
||
inet addr:208.61.124.28 P-t-P:208.61.124.1 Mask:255.255.255.255
|
||
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
|
||
RX packets:297579 errors:0 dropped:0 overruns:0 frame:0
|
||
TX packets:266102 errors:0 dropped:0 overruns:0 carrier:0
|
||
collisions:0 txqueuelen:10
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Note><title>Note</title>
|
||
<Para>
|
||
PPPoE adds 8 bytes of extra overhead to the ethernet frames and the correct
|
||
initial maximum setting for the ppp0 interface MTU is 1492. If the MTU is
|
||
set too high, it may cause a fubar packet fragmentation scenario, known as
|
||
the Path MTU Discovery blackhole where the two ends of the connection fail
|
||
to communicate. A typical symptom would be the failure of some web pages to
|
||
load properly, and possibly other annoying problems. You may need to also
|
||
set the MTU for interfaces on any masqueraded LAN connections MTU to 1452.
|
||
This does not apply to PPPoA, bridged, or routed configurations, just PPPoE!
|
||
See rfc2923 for a technical explanation.
|
||
</Para>
|
||
</Note>
|
||
|
||
|
||
<Para>
|
||
Actually, for PPPoE the real setting should be at least 8 bytes less (the
|
||
extra PPPoE protocol overhead) than any interface between you and the
|
||
ultimate destination. All routers normally would be set to 1500, thus 1492 is
|
||
correct from your end. But, it may happen that somewhere a router is
|
||
configured at a lower setting, and this can cause problems, especially
|
||
with web pages loading, and other traffic failures. The way to test this is
|
||
to keep dropping the MTU until things 'work'.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3 id="pppoa">
|
||
<Title>PPPoA</Title>
|
||
|
||
<Para>
|
||
PPPoA (PPPoATM, or PPP over ATM) is a cleaner solution than PPPoE since most
|
||
of the work is done in hardware, and since the raw DSL traffic is ATM. There
|
||
is no user space client necessary to manage the connection as with PPPoE, and
|
||
the additional ethernet protocol layer is not required. Authentication is
|
||
still the same: user id and password to connect, but the mechanics are
|
||
different since no ethernet encapsulation takes place.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
PPPoA is either done completely in hardware or is implemented as a device
|
||
specific driver. There is no such thing as a generic PPPoA software client
|
||
like there is for PPPoE. There is an ATM patch for 2.2 kernels, support for
|
||
ATM in the 2.4.x kernel, and a project based on the Efficient Networks 3010,
|
||
as well as other ATM cards. The ATM on Linux homepage is here: <Ulink
|
||
URL="http://linux-atm.sourceforge.net/">
|
||
http://linux-atm.sourceforge.net/</Ulink>. And even more info is at <Ulink
|
||
URL="http://www.sfgoth.com/~mitch/linux/atm/pppoatm/">
|
||
http://www.sfgoth.com/~mitch/linux/atm/pppoatm/</Ulink> from the kernel
|
||
developer of this project. Existing PPPoA implementations are hardware/driver
|
||
based, and Linux PPPoA modem drivers are scarce as hen's
|
||
teeth at this time. The above modem does not seem to be available through
|
||
normal retail channels. This may be a problem, if this is the only protocol
|
||
an ISP delivers, and an external modem that supports PPPoA is not available.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
If PPPoA is your ISP's only option, you might consider one of the
|
||
router/modems that can handle PPPoA connections, and let the hardware handle
|
||
everything.
|
||
</Para>
|
||
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3 id="pptp">
|
||
<Title>PPTP/PPPoA with Alcatel Ethernet Modems</Title>
|
||
|
||
<Para>
|
||
Alcatel SpeedTouch Home ethernet modems (supersedes the Alcatel 1000)
|
||
support both bridged and PPPoA connections. The modem itself handles the
|
||
PPPoA protocol internally. When in PPTP/PPPoA mode (as opposed to RFC1483 bridging
|
||
mode), Linux will connect to the modem via PPTP (MS VPN). The Linux PPTP
|
||
homepage is <Ulink
|
||
URL="http://cag.lcs.mit.edu/~cananian/Projects/PPTP/">http://cag.lcs.mit.edu/~cananian/Projects/PPTP/</Ulink>,
|
||
and works well with this modem.
|
||
<!--
|
||
RPMs can be found as
|
||
<Filename>pptp*rpm</FileName> at freshmeat or other download locations.
|
||
-->
|
||
In addition to installing pptp, your kernel must also have support for PPP.
|
||
</Para>
|
||
|
||
<Para>
|
||
The modem has internal configuration pages than can be reached by pointing
|
||
a browser to the default IP address of http://10.0.0.138. (You will of course
|
||
have to have your NIC set up for a 10.0.0.0 network with similar IP such
|
||
as 10.0.0.1, in order to reach the modem's configuration pages.) For PPPoA,
|
||
the connection type is 'PPTP'. You will have to get the other settings from
|
||
your provider if the defaults do not work. Settings such as 'VPI/VCI' and
|
||
'encapsulation' can vary from provider to provider. Of course, if the modem
|
||
is coming from your provider, all this should be already configured.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The next step is to configure <Command>pptp</Command>, which is done by
|
||
configuring the <Command>pppd </Command>files
|
||
<Filename>/etc/ppp/pap-secrets</FileName> (or
|
||
<Filename>chap-secrets</FileName>) and <Filename>/etc/ppp/options</FileName>.
|
||
This is where the username and password is entered. For example:
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
|
||
<Filename>/etc/ppp/pap-secrets</FileName>:
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<Literal>
|
||
<MSGText>
|
||
<LiteralLayout>
|
||
|
||
# client secret server IP address
|
||
login@isp.com * my_password_here *
|
||
|
||
</LiteralLayout>
|
||
</MSGText>
|
||
</Literal>
|
||
</Para>
|
||
|
||
<Para>
|
||
and <Filename>/etc/ppp/options</FileName>:
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<Literal>
|
||
<MSGText>
|
||
<LiteralLayout>
|
||
|
||
name "login@isp.com"
|
||
noauth
|
||
noipdefault
|
||
defaultroute
|
||
|
||
</LiteralLayout>
|
||
</MSGText>
|
||
</Literal>
|
||
</Para>
|
||
|
||
<Para>
|
||
Once everything is configured properly, it should be just a matter of
|
||
starting pptp, pointing it to the modem's address:
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<screen>
|
||
|
||
#pptp 10.0.0.138
|
||
|
||
</screen>
|
||
</para>
|
||
|
||
|
||
<note><title>Note</title>
|
||
<Para>
|
||
Alcatel supplies many sub-models of these modems. These features may not be
|
||
available on all models, or may be altered from the defaults. This is
|
||
something to be aware of, if buying a used modem.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
This modem only supports one concurrent PPTP connection.
|
||
|
||
</Para>
|
||
</note>
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3 id="router">
|
||
<Title>Modem/Router Configuration</Title>
|
||
|
||
<Para>
|
||
Some ISPs are providing <Quote>routers</Quote> as the connection device.
|
||
Essentially these are mini routers with built in modems. These are all
|
||
ethernet based devices too, so Linux should be good to go here as well.
|
||
Again, a compatible, working NIC should be all that is required to make this
|
||
work.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
A <Quote>router</Quote> has many advantages. The better ones can handle the
|
||
connection management, IP encapsulation, and authentication, as well as
|
||
providing a means of segregating your LAN from outside traffic, and possibly
|
||
other features too. In short they can do it all. One big advantage is that
|
||
they can handle whatever protocols your ISP requires in order to connect.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
If the ISP is requiring PPPoX, then this makes life a little easier since you
|
||
will not have to install or configure any additional software just to use
|
||
their network. The modem's firmware will handle this. The downside is that
|
||
most of these do not have the flexibility of a Linux router, or other
|
||
software solution. Of course, you could set up a Linux router behind the
|
||
router, and have the best of both worlds. The ones with more and better
|
||
features are also going to cost significantly more.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
While the physical installation of a router is very similar to the modem
|
||
installation (see above), the router configuration itself is different
|
||
since your first <Quote>hop</Quote> will be the router's interface and not
|
||
the ISP's gateway. Routers will actually have two interfaces -- one that you
|
||
connect to from the LAN side, and one that connects to your ISP on the WAN
|
||
side. Your point of exposure here is the WAN interface of the router.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The router will also have a pre-configured, private IP address that you will
|
||
connect to from the LAN side. This will be your gateway. The public IP
|
||
address will be assigned to the WAN side interface. Typically these devices
|
||
also act as DHCP servers for the LAN side as well. So possibly all you have
|
||
to do is to start a DHCP client such as <Command>dhcpcd</Command> or
|
||
<Command>pump</Command> (Redhat based distros) to get up and running. Just
|
||
make sure the modem/router is syncing first. The appropriate steps and
|
||
configuration should be in the owner's manual, or available from your
|
||
provider.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
If you are a PPPoX customer, and the router is handling this part of the
|
||
connection, then you will have to configure at least your user id and
|
||
password before connecting. If a Bridged/DHCP customer, you should just have
|
||
to activate DHCP on the router, and possibly register the MAC (hardware
|
||
address) of the router with your provider. Some routers have <Quote>MAC
|
||
cloning</Quote> which means that they will report the MAC address of the
|
||
attached NIC. If static IP, then you will have to configure this as well.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
If you need to access the router directly, you will need to know the
|
||
manufacturer's default setting for its IP address. See the owner's manual, or
|
||
ask your provider. You will then have to set your NIC's interface to the same
|
||
network as the router. For instance, if the router has an IP of 10.0.0.1, set
|
||
your interface's address to 10.0.0.2 (typically eth0), and netmask to
|
||
255.0.0.0.
|
||
|
||
</Para>
|
||
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
# ifconfig eth0 10.0.0.2 up netmask 255.0.0.0
|
||
# route add -net 10.0.0.0
|
||
$ ping 10.0.0.1
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
If everything is in working order, the router should respond to pings. How to
|
||
configure this permanently will vary from distro to distro. So check your
|
||
distribution's documentation. Now you should be able to ping the
|
||
modem/router, and, if all is well, beyond. Then use telnet or a web browser
|
||
to do any further configuration of the router.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Even if the ISP is not offering any router options, there are quite a few
|
||
available from third party manufacturers such as Netgear, Linksys, Cisco,
|
||
Zyxel, Cayman, Alcatel and others. These will have all the features already
|
||
mentioned and maybe more. Just make sure it matches your provider's DSL. This
|
||
is one good way around the PPPoX bugaboo.
|
||
|
||
</Para>
|
||
|
||
<Caution>
|
||
<Para>
|
||
Some manufacturers may be marketing these as having <Quote>firewall</Quote>
|
||
capabilities. In some cases, this amounts to nothing more than basic NAT
|
||
(Network Address Translation or masquerading). Not a full, true firewall by
|
||
most measures. Be sure to read the fine print before buying and make sure you
|
||
know how much real firewalling is included.
|
||
|
||
</Para>
|
||
</Caution>
|
||
|
||
</Sect3>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
<Sect2 id="connect">
|
||
<Title>Connect</Title>
|
||
|
||
<Para>
|
||
Everything should be in place now. You probably have already tested your
|
||
connection. You should be seeing ping roundtrip times of 10-75 ms to the ISP's
|
||
gateway. If something has gone wrong, and you cannot connect, either
|
||
retrace the above steps, or see the <Link LinkEnd="trouble">Troubleshooting
|
||
Section</Link> below.
|
||
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
</Sect1>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
||
|
||
<Sect1 id="secure">
|
||
<Title>Securing Your Connection</Title>
|
||
|
||
<Para>
|
||
This section is intended for those who have not previously dealt with the
|
||
security implications of having a full-time Internet connection. Or may not
|
||
understand some of the basic concepts of security. This is meant to be just a
|
||
quick overview, not a comprehensive examination of all the issues! Just
|
||
enough to give you a gentle shove in the right direction. Please see the <Link
|
||
LinkEnd="links">Links section</Link> for sites with more details. Also, your
|
||
distribution surely has plenty of good information as well.
|
||
|
||
</Para>
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Security Quick-start</Title>
|
||
|
||
<Para>
|
||
Before going on-line full-time, do not underestimate the need for securing
|
||
your connection. You will have two things that mischief makers and crackers
|
||
of the world are looking for: bandwidth, and a Unix-like OS. You instantly
|
||
become an inviting target. It is just a matter of time before someone
|
||
comes knocking. Possibly a very short time. A quick start:
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Turn off any daemons and services that aren't absolutely essential, and
|
||
can be accessed from outside. You can't get compromised through a port
|
||
that isn't open. Use <Command>ps</Command> and <Command>netstat</Command>
|
||
to see what services are running. (See man pages for specifics). Do you
|
||
really need <Command>named</Command>, <Command>sendmail</Command>,
|
||
<Command>telnet</Command>, <Command>ftp</Command> running and accessible
|
||
to one and all? If not sure, then they should not be running. Then take
|
||
whatever steps necessary to make sure they don't start again on the next
|
||
boot. See your distribution's documentation on this.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Many distributions start some well known services by default. You may not
|
||
have done anything yourself explicitly to start these. And may not even
|
||
realize these are indeed running. But it is up to you to know what is
|
||
running, and how safe it is. Don't rely on a <Quote>default</Quote>
|
||
installation of any distribution to do this for you, or to be secure.
|
||
Chances are it isn't.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If you decide some services are essential, make sure you are running the
|
||
most current version. Exploits are found, and then get fixed quickly.
|
||
Don't get caught with your pants down. A full-time connection makes
|
||
staying updated very easy -- and very important. Check with your
|
||
distribution to see what new packages are available. Then stay in
|
||
touch. If they have a security mailing list, get on it.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Take passwords seriously, using non-dictionary <Quote>words</Quote>. Use
|
||
shadow passwords (this should be a standard feature of newer
|
||
distributions). Do not allow remote root logins. See the
|
||
<Ulink URL="http://www.tldp.org/HOWTO/Security-HOWTO.html">Security
|
||
HOWTO</Ulink> for more details and ideas.
|
||
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
|
||
<Para>
|
||
Use <Command>ssh</Command> instead of <Command>telnet</Command>
|
||
or <command>rsh</command>.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Set up a firewall to limit access, and log connection attempts. This will
|
||
be different depending on which kernel series you are using:
|
||
<Command>ipfwadm</Command> for 2.0, <Command>ipchains</Command> for 2.2,
|
||
and <Command>iptables</Command> for 2.4. See the below HOWTOs for a more
|
||
in depth discussion on this and other security related topics:
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<listitem>
|
||
<para>
|
||
<ulink url="http://tldp.org/HOWTO/Security-Quickstart-HOWTO/index.html">Security-Quickstart-HOWTO</ulink>
|
||
and for Redhat based distros
|
||
<ulink url="http://tldp.org/HOWTO/Security-Quickstart-Redhat-HOWTO/index.html">Security-Quickstart-Redhat-HOWTO</ulink>
|
||
</para>
|
||
</listitem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink
|
||
URL="http://www.tldp.org/HOWTO/Firewall-HOWTO.html">Firewall
|
||
HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
|
||
<Ulink
|
||
URL="http://www.tldp.org/HOWTO/Security-HOWTO.html">Security
|
||
HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
|
||
<Ulink
|
||
URL="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html">IPCHAINS
|
||
HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<listitem>
|
||
<para>
|
||
<ulink url="http://netfilter.samba.org">Netfilter/Iptables docs</ulink>
|
||
</para>
|
||
</listitem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO.html">IP
|
||
Masquerade HOWTO</Ulink>
|
||
|
||
</Para>
|
||
|
||
|
||
</ListItem>
|
||
</ItemizedList>
|
||
|
||
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Additional references are in the <Link LinkEnd="links">Links Section</Link>
|
||
below.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
</Sect1>
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
||
|
||
<Sect1 id="tuning">
|
||
<Title>Performance Tuning and Troubleshooting</Title>
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
<Sect2>
|
||
<Title>Tuning</Title>
|
||
|
||
<Para>
|
||
OK, now we are up and running, and we want to be running at warp factor nine.
|
||
No such thing as too fast, right?
|
||
</Para>
|
||
|
||
<Para>
|
||
Linux networking is pretty robust, even a default installation with no
|
||
<Quote>tuning</Quote>. You may well not need to do anything else. But if your
|
||
connection is not performing up to what you think it should be, then possibly
|
||
there is a problem somewhere. This may be a more worthwhile approach than
|
||
the pursuit of any magical <Quote>tweak</Quote>.
|
||
</Para>
|
||
|
||
<Para>
|
||
A <Emphasis>very</Emphasis> rough guideline on what you might reasonably
|
||
expect as a maximum sync rate, based on distance from DSLAM/CO:
|
||
|
||
</Para>
|
||
<!--
|
||
<LiteralLayout>
|
||
0-12 K ft (0-3.6 km) - 2000 Kbps or more (8100 max for ADSL)
|
||
12-16 K ft (3.6-4.6 km) - 1500 Kbps -> 1000 Kbps
|
||
16-18 K ft (4.6-5.4 km) - 1200 Kbps -> 512 Kbps
|
||
18-?? K ft (5.4-?? km) - 512 Kbps -> 128 Kbps or less :(
|
||
</LiteralLayout>
|
||
-->
|
||
<informaltable label="Distances" pgwide="1">
|
||
<tgroup cols=2 align="left" colsep=1 rowsep=1>
|
||
<colspec colname=c1 align="center" colwidth="40">
|
||
<colspec colname=c2 align="center" colwidth="40">
|
||
<tbody>
|
||
<row>
|
||
<entry align="right" colname="c1">
|
||
0-12 K ft (0-3.6 km)
|
||
</entry>
|
||
<entry align="left" colname="c2">
|
||
2000 Kbps or more (8100 max for ADSL)
|
||
</entry>
|
||
</row>
|
||
<row>
|
||
<entry align="right" colname="c1">
|
||
12-16 K ft (3.6-4.6 km)
|
||
</entry>
|
||
<entry align="left" colname="c2">
|
||
1500 Kbps to 1000 Kbps
|
||
</entry>
|
||
</row>
|
||
<row>
|
||
<entry align="right" colname="c1">
|
||
16-18 K ft (4.6-5.4 km)
|
||
</entry>
|
||
<entry align="left" colname="c2">
|
||
1200 Kbps to 512 Kbps
|
||
</entry>
|
||
</row>
|
||
<row>
|
||
<entry align="right" colname="c1">
|
||
18-?? K ft (5.4-?? km)
|
||
</entry>
|
||
<entry align="left" colname="c2">
|
||
512 Kbps to 128 Kbps or less :(
|
||
</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
|
||
<Para>
|
||
There are many conceivable factors that could effect this one way or the
|
||
other. Newer generations of DSL will surely improve this, as will related
|
||
technologies like repeaters.
|
||
</Para>
|
||
|
||
<Para>
|
||
You will loose 10-20% of the modem's attainable sync rate to networking
|
||
overheads (TCP, ATM, ethernet). So a 1500 Kbps connection, is only going to
|
||
realize about 1100-1300 Kbps or so of real world throughput. No tweaking is
|
||
going to change the built-in protocol overheads. Also, if your
|
||
service is capped at a lesser speed by your provider, then you can't get
|
||
above that speed no matter what. <Emphasis>AND</Emphasis> -- that there are
|
||
numerous variables that can effect your loop/signal quality, and subsequently
|
||
your speed (aka sync rate). Some of these may be beyond your control.
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
But there are a few things that you might want to look at.
|
||
|
||
</para>
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>TCP Receive Window</Title>
|
||
|
||
<Para>
|
||
For many of us, a default Linux installation is going to give something close
|
||
to optimum performance. Windows 9x users often get a big boost by increasing
|
||
their TCP Receive Window (RWIN). But this is because it is too small to start
|
||
with. This is just not the case with Linux where the default value is 32KB.
|
||
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
The exception here is if you have to routinely deal with a high latency
|
||
connection. For instance, if your provider has a satellite uplink that is
|
||
consistently adding unusual latency (250ms or greater?). Then a larger
|
||
TCP Window will likely help. For more on TCP Receive Window and related
|
||
issues, look at <Ulink
|
||
URL="http://www.psc.edu/networking/perf_tune.html">http://www.psc.edu/networking/perf_tune.html</Ulink>.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The Receive Window is a buffer that helps control the flow of data. If
|
||
set too low, it can be a bottleneck and restrict throughput. The optimum
|
||
value for this depends completely on your bandwidth and latency. Latency being
|
||
what you would find as average roundtrip time (RTT) based on
|
||
<Emphasis>your</Emphasis> typical destinations and conditions. This can be
|
||
determined with <Command>ping</Command>. For example, the Linux default of
|
||
32KB is acceptable up to speeds of 2 Mbps and a typical latency of 125ms or so,
|
||
or 1.0 Mbps and latency of 250ms. Setting this value too high can also
|
||
adversely effect throughput, so don't over do it.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
An example courtesy of Juha Saarinen of New Zealand:
|
||
|
||
</Para>
|
||
|
||
<Blockquote>
|
||
<Para>
|
||
The commonly used formula for working out the tcp buffer is the
|
||
<Quote>bandwidth delay product</Quote> one:
|
||
</para>
|
||
<Para>
|
||
Buffer size = Bandwidth (bits/s) * RTT (seconds)
|
||
</Para>
|
||
<Para>
|
||
In my case, I have roughly 8Mbps downstream, but the ATM network can only
|
||
support ~3.5Mbps sustained. I'm far away from the rest of the world, so to
|
||
squeeze in a sufficient amount of 1,500 byte packets, with average RTTs of
|
||
250ms, I should probably have a buffer of (3,500,000/8)*.25 = 106KB. (I've
|
||
got 128KB at the moment, which works fine.)
|
||
</Para>
|
||
|
||
</Blockquote>
|
||
|
||
<Para>
|
||
The Receive Window can be dynamically set in the /proc filesystem. This
|
||
requires entering a value that is twice the desired buffer size:
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<screen>
|
||
|
||
#echo 262144 > /proc/sys/net/core/rmem_default
|
||
#echo 262144 > /proc/sys/net/core/rmem_max
|
||
|
||
</screen>
|
||
</para>
|
||
|
||
<Para>
|
||
The above example actually sets the value to 128K. The Send Window can also
|
||
be set, but is not as likely to be a limiting factor on DSL connections as
|
||
the Receive Window:
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<screen>
|
||
|
||
#echo 262144 > /proc/sys/net/core/wmem_default
|
||
#echo 262144 > /proc/sys/net/core/wmem_max
|
||
|
||
</screen>
|
||
</para>
|
||
|
||
<Para>
|
||
These values can also be set using the <Command>sysctl</Command> command. See
|
||
the man page.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Other suggested kernel options for those who want to squeeze every last bit
|
||
out of that copper (selected entries only):
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<screen>
|
||
|
||
# sysctl -a
|
||
net.ipv4.tcp_rfc1337 = 1
|
||
net.ipv4.ip_no_pmtu_disc = 0
|
||
net.ipv4.tcp_sack = 1
|
||
net.ipv4.tcp_fack = 1
|
||
net.ipv4.tcp_window_scaling = 1
|
||
net.ipv4.tcp_timestamps = 1
|
||
net.ipv4.tcp_ecn = 0
|
||
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
A brief description of these, and other, options may be found in
|
||
<filename>/usr/src/linux/Documentation/networking/ip-sysctl.txt</filename>,
|
||
in the kernel source directory.
|
||
|
||
</para>
|
||
|
||
</sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>Interleaving</Title>
|
||
|
||
<Para>
|
||
<Quote>Interleaving</Quote> is an error control mechanism of ADSL with DMT
|
||
line encoding. DMT is now the standard for ADSL, and is by far and away the
|
||
most prevalent form of ADSL. Interleaving buffers the raw data and corrects
|
||
errors on the fly at the DSLAM. This can significantly help marginal loops
|
||
that may be prone to line errors. The downside is that this buffering also adds
|
||
significant latency to the connection. So for those with reasonable quality
|
||
lines, interleaving is of no real benefit, and may actually add unnecessary
|
||
latency.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Interleaving is an adjustable parameter and can be turned on or off by the
|
||
telco. Many telcos seem to like to have this on by default, since it probably
|
||
reduces tech support calls in those cases where it does help stabilize a line.
|
||
But everyone else pays a price.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
How to know if your line is interleaved or not, and how to change it? Good
|
||
question. Generally speaking, if your first hop or two on a traceroute is
|
||
less than 25ms or so, you can pretty much figure that interleaving is off.
|
||
But there may be other factors such as how far away those hops actually are.
|
||
Unless your modem accurately reports this, the only other real way to know is
|
||
to talk to someone at the telco. This may prove easier said than done.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<Quote>FastPath</Quote> DMT is synonymous with <Quote>interleaving
|
||
off</Quote>. Again, this <Emphasis>only</Emphasis> applies to ADSL/DMT.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New section ~~~~~ -->
|
||
|
||
<sect3 id="bottlenecks">
|
||
<title>TCP Bottlenecks</title>
|
||
<para>
|
||
DSL connections may suffer performance degradations under certain
|
||
circumstances. Thankfully, Linux has very robust and flexible networking
|
||
tools to help us deal with these.
|
||
</para>
|
||
|
||
<para>
|
||
One such common situation is where traffic bottlenecks are created whenever
|
||
data from a fast network segment hits a slower one. Such as ethernet hitting
|
||
a DSL modem/router. This can cause short term traffic backlogs, known as
|
||
<quote>queues</quote> in the device. Queuing can result in degraded
|
||
performance, particularly for interactive protocols (like telnet or ssh) and
|
||
streaming protocols (like RealAudio), and increased latency for ICMP and
|
||
other network protocols. This is most evident when the upstream link is
|
||
saturated (since downstream data is queued at the ISP's end and we can't do
|
||
as much about that). The queued traffic is processed such that lower volume
|
||
traffic protocols (like ssh) often get drowned out so to speak, by the higher
|
||
volume, bulk traffic (like http or ftp), as there isn't any special
|
||
prioritizing in default usage.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
And if the upstream queuing, or other factors, causes enough of a delay, it
|
||
can even decrease downstream bandwidth utilization by slowing the
|
||
ACKnowledgements (which are heading upstream), that are required to keep a
|
||
download moving at optimal rates. So it is possible that an upload can hurt
|
||
a simultaneous download.
|
||
|
||
</para>
|
||
|
||
<!--
|
||
<para>
|
||
Another effect can occur on asymmetric networks, like some ADSL offerings
|
||
where the downstream has significantly greater bandwidth than the upstream.
|
||
While both the up and down channels can be used at the same time, the
|
||
saturation of both can adversely effect the downstream performance under
|
||
some conditions. TCP necessitates a certain amount of back and forth
|
||
communication. So that during a download, for instance, there is always a
|
||
small percentage of upstream bandwidth being utilized by the downstream
|
||
traffic. The greater the downstream bandwidth being utilized, the more
|
||
upstream bandwidth is required to maintain the two-way TCP
|
||
<quote>conversation</quote>. It can happen that the combined upstream
|
||
pressures from both an upload, and a simultaneous download, degrades
|
||
performance and results in a reduction of available downstream bandwidth.
|
||
This is caused by the ACKnowledgements for the downstream traffic (which are
|
||
headed upstream), getting delayed or possibly even lost, on route for a
|
||
variety of reasons. The sender will only send as fast as we can tell it to.
|
||
If our communications to the sender are impeded, then so is our speed coming
|
||
back from the sender. This effect can be more pronounced on highly asymmetric
|
||
connections.
|
||
</para>
|
||
-->
|
||
|
||
<para>
|
||
Such effects can be largely mitigated with Linux's built-in traffic
|
||
shaping abilities. The user space tool for manipulating the kernel's
|
||
advanced traffic routing features is <application>iproute</application>,
|
||
sometimes packaged as <application>iproute2</application>. This includes various
|
||
tools that can classify and prioritize traffic with a considerable degree of
|
||
flexibility. It also requires various kernel config options to be turned on.
|
||
And is also fairly close to Black Magic ;-) The definitive document on this
|
||
is the Advanced Routing and Traffic Control HOWTO (<ulink
|
||
url="http://tldp.org/HOWTO/Adv-Routing-HOWTO.html">http://tldp.org/HOWTO/Adv-Routing-HOWTO.html</ulink>).
|
||
Pay particular attention to the <quote>Cookbook</quote> Section #15, and in
|
||
particular #15.8, <quote>The Ultimate Traffic Conditioner: Low Latency, Fast
|
||
Up & Downloads</quote>. A great read!
|
||
|
||
</para>
|
||
|
||
</sect3>
|
||
|
||
<!-- ~ End section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New section ~~~~~ -->
|
||
|
||
<sect3>
|
||
<title>Dropped PPP Connections</title>
|
||
<para>
|
||
PPPoE and PPPoA both rely on the venerable PPP protocol. This
|
||
protocol incorporates the Link Control Protocol (LCP), which is used to
|
||
maintain the viability of the connection. Each end can send LCP echoes to other
|
||
end, and if there is no response in the alloted time frame, the session is
|
||
presumed dead, and is torn down. Again, either end can initiate this process.
|
||
The client should then negotiate a new connection. But, this normally means a
|
||
new IP address is assigned along with the new session.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
Perhaps this is undesirable? While you certainly can't control what happens on
|
||
the remote end in this regard, you can adjust PPP's very flexible way of
|
||
dealing with LCP echoes on your end, to increase the number of echoes, extend
|
||
the interval and timeout period on your end. This might help prolong the life
|
||
of an unstable connection in situations with marginal line conditions, or a
|
||
buggy peer on the other end. Read your client's documentation. YMMV.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
Some providers may deliberately enforce some time limit. There is not much
|
||
you can do about this.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
Also, frequently dropped connections are often an indication of a line
|
||
problem of some kind. This is something the telco should investigate.
|
||
|
||
</para>
|
||
|
||
</sect3>
|
||
|
||
<!-- ~ End section ~ -->
|
||
|
||
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="trouble">
|
||
<Title>Installation Problems</Title>
|
||
|
||
<Para>
|
||
Read this section, if you have no sync at all or are completely unable to
|
||
connect. See your modem's owner's manual for interpreting the modem's LEDs.
|
||
(Many will show a solid red (or orange) light if not in sync.)
|
||
|
||
</Para>
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3 id="nosync">
|
||
<Title>No sync</Title>
|
||
|
||
<Para>
|
||
The modem sync LED has never been green.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If doing a self-install, the DSL jack may be wired wrong, or the splitter
|
||
may be wired wrong. Also, the modem may be wired differently than standard
|
||
telco devices. See above.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Is the modem Linux compatible? If ethernet interfaced, this should not be
|
||
a problem. But PCI or USB modems may require drivers just to achieve sync.
|
||
This could be a show stopper since many PCI and USB modems are not
|
||
Linux compatible.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Call your provider and make sure the line was provisioned. It is always
|
||
possible someone dropped the ball. They may even be able to run a remote
|
||
test on your line just to verify. There is a also remote possibility that
|
||
the DSLAM is down. They should know this as well.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Disconnect the modem power cord and disconnect the DSL cord from the wall
|
||
jack. Plug it into the test jack inside the NID (outside phone box), and
|
||
run an extension cord if necessary for power. Temporarily disconnect the
|
||
wiring to the inside phone circuit. This should effectively bypass any
|
||
inside wiring and environmental issues. The ethernet cable to the NIC does
|
||
not need to be connected to run this test (true <Emphasis>only</Emphasis>
|
||
for ethernet modems). The modem will sync fine without it. (Easier said
|
||
than done, I know.) But if possible, move enough of your system where you
|
||
can view the modem's diagnostics (if available) and get the sync rate. If
|
||
this works, there is probably something wired incorrectly inside, or a
|
||
short in a connection somewhere, or there is severe electrical
|
||
interference on the DSL line. Double check the splitter and wall jack
|
||
connections. If a splitterless installation, look for bad wiring, bad
|
||
(e.g. corroded) connections on <Emphasis>all</Emphasis> jacks, bad
|
||
splices, or defective microfilters!
|
||
</Para>
|
||
|
||
<Para>
|
||
If no sync on the above test, either the line was not readied, the
|
||
modem is defective, or the DSLAM is down. Note that PCI and USB
|
||
modems will need to load drivers before syncing, and thus make
|
||
this test a little more complicated.
|
||
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If you installed microfilters, remove these temporarily and unplug
|
||
<Emphasis>all</Emphasis> telco devices, such as fax machines, etc. Possibly
|
||
a mircofilter is defective and shorting out the line.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>Network Card (NIC) Problems</Title>
|
||
|
||
<Para>
|
||
Symptoms here are: NIC is not recognized, modules won't load, or
|
||
<Command>ifconfig</Command> shows the interface is not up, or is generating
|
||
lots of errors, etc.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Turn off Plug 'n Pray in BIOS. This may be labeled as <Quote>non-Microsoft
|
||
OS</Quote> or similar. A sometimes symptom here is that the NIC is
|
||
assigned IRQ 0. Or there may be an error message like <Quote>resource
|
||
temporarily unavailable</Quote>.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Check for IRQ conflicts with <Command>cat /proc/interrupts</Command>. If
|
||
the NIC is sharing an IRQ, try moving cards around in slots, or tinker
|
||
with BIOS IRQ settings. If an ISA card, you may need to get the setup
|
||
utility from the manufacturer and use it to set IRQ, etc. This may
|
||
require booting to DOS. Modern systems should theoretically be
|
||
able to handle IRQ sharing, so it is not necessarily a problem in and of
|
||
itself. Only if something is misbehaving.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Possibly the wrong module is being loaded. Look through the kernel source
|
||
documentation in <Filename>/usr/src/linux/Documentation/*</FileName> for
|
||
your card or chipset. Also, for comments and update information in
|
||
<Filename>/usr/src/linux/drivers/net/*.c</FileName> for your respective
|
||
chipset. It is worth noting that there is more than one module for some
|
||
card types. This seems to be true of tulip and 3Com cards. Check boot
|
||
messages or use <Command>lspci -v</Command> to see how the kernel is
|
||
identifying your card. You can use <Command>insmod</Command>,
|
||
<Command>rmmod</Command>, and <Command>modprobe</Command> to test
|
||
different modules. See the respective man pages for more information.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Check the manufacturer's web site for Linux documentation. Or look at
|
||
Donald Becker's informative site at <Ulink
|
||
URL="http://www.scyld.com/network/">http://www.scyld.com/network/</Ulink>.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Some Linux NIC drivers reportedly work better as non-modular. In other
|
||
words, compile them into the kernel instead of as a module.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
It is also possible that the card is bad, or the drivers just aren't up to
|
||
snuff. Try another card. And you don't need an expensive, high quality
|
||
card necessarily either.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>IP Connection Problems</Title>
|
||
|
||
<Para>
|
||
Read this section if you are sure the modem is syncing, the NIC is recognized
|
||
and seems to be working properly, client software is installed and running
|
||
without error, but the connection to the ISP fails. Verify the modem is indeed
|
||
syncing by the LED(s). An IP connection failure may be evidenced by
|
||
<Command>ifconfig</Command> not showing an active eth0 interface (or ppp0 for
|
||
PPPoX), or <Command>pinging</Command> gateway and other destinations
|
||
generates '<Literal>network unreachable</Literal>' or similar errors.
|
||
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Make sure you know which protocol your ISP is using. Are they using DHCP?
|
||
PPPoX? It is critical that you have this right. You may have to ask tech
|
||
support.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If you are using DHCP, does the ISP require MAC address authentication,
|
||
and if so, do they have the right address? Did they or you typo it? If
|
||
the ISP requires hostname authentication, is your DHCP client passing
|
||
the required hostname? This is done with the <Quote>- h</Quote> command
|
||
line option.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Look at <Filename>/var/log/messages</FileName> and see if any useful clues
|
||
are there. Also, run <Command>tcpdump</Command> while trying to initiate
|
||
the connection. <Command>tcpdump</Command> output is fairly cryptic, but
|
||
you should be able to determine if there is any response at all.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If PPPoX, is the ISP using <Literal>username</Literal> as an id, or
|
||
<Literal>username@isp.com</Literal>?
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<listitem>
|
||
<para>
|
||
CHAP, PAP, or other? I would set up both CHAP and PAP (see
|
||
<command>man pppd</command>) just to be safe.
|
||
</para>
|
||
</listitem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Try pinging the default gateway's address. Get this with '<Command>route
|
||
-n</Command>'. If you can <Command>ping</Command> by IP address (i.e.
|
||
111.222.333.444), but not by hostname, then likely nameservers are not
|
||
correctly setup in <Filename>/etc/resolv.conf</FileName>. This is
|
||
configurable as to whether your connection protocol (e.g. PPPoE) does this
|
||
automatically or not. And different distributions may have their own
|
||
way of setting this up, so check their documentation first. In a pinch,
|
||
just add them manually to <filename>/etc/resolv.conf</filename>.
|
||
<command>pppd</command> also has the <quote>usepeerdns</quote> option
|
||
that can be enabled.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
For <application>rp-pppoe</application>, let the PPPoE client bring up the ethernet interface. Do not
|
||
have it come up on boot. Make sure there is no existing default route
|
||
before starting PPPoE. For rp-pppoe, David Skoll recommends that
|
||
<Filename>/etc/ppp/options</FileName> be left empty.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If running a firewall (e.g. with <application>ipchains</application>), try
|
||
temporarily taking it down. Possibly this is misconfigured, and not
|
||
allowing packets through.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<listitem>
|
||
<para>
|
||
Roaring Penguin has a very nice debug output with all kinds of
|
||
system info, and even tips for correcting problems. See the docs
|
||
for turning this well-done feature on.
|
||
</para>
|
||
</listitem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If the modem was purchased from a source other than your ISP, it may the
|
||
wrong kind of modem. SDSL needs an SDSL modem, for instance. Also, for
|
||
ADSL there are CAP and DMT encodings, and these are incompatible with
|
||
each other.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The modem may need to be configured for your ISP's service. All modems
|
||
have configurations for VCI, VPI, encapsulation, etc. Call tech support
|
||
for this information. Modem configuration is usually done by either
|
||
telnetting or web browsing to the modem's IP address.
|
||
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
|
||
</Sect3>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="synctr">
|
||
<Title>Sync Problems</Title>
|
||
|
||
<Para>
|
||
Read this section if you have had a working connection, but now have lost
|
||
sync, are intermittently losing sync, your sync rate has dropped
|
||
significantly, or are getting a <Quote>sync/no surf</Quote> condition.
|
||
(Better quality modems will have a way to report sync rate, usually via
|
||
telnet or a web browser interface. See the owner's manual.)
|
||
</Para>
|
||
|
||
<Para>
|
||
A loss of sync indicates a problem with the DSLAM, your line (inside or
|
||
outside) or your modem. DSLAMs typically have <Quote>shelves</Quote> with
|
||
<Quote>cards</Quote>. Alcatel DSLAM cards, just for instance, have a capacity
|
||
of four connections each. If the card goes bad, at most four customers are
|
||
effected. The point being that sync loss outages can be very isolated. Unlike
|
||
network outages that tend to effect large numbers of users. Sync outages are
|
||
a telco problem, not an ISP problem. If your service agreement is with the
|
||
ISP, you will need to contact them, who will in turn contact the telco.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Degraded sync rates, and disruption of the DSL signal, can cause various
|
||
problems. Obviously, you will never get your maximum throughput under these
|
||
conditions. But, the symptoms are not always obvious as to whether the
|
||
problem is on your end or the provider's.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
For instance, a poor inside wire connection may result in retransmissions of
|
||
packets that have been dropped. This can really reduce throughput and slow a
|
||
connection down. It is tempting to think of packet loss as a traditional
|
||
networking problem, but with DSL it is possible to be the result of a bad
|
||
line, impaired signal, or even the modem itself.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Some things to try:
|
||
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Power cycle the modem. Turn off the power button/switch, and physically
|
||
unplug the cable to the wall jack for 30 seconds or so. Turn back on, and
|
||
re-attach to the wall jack. This will force a resync. Unfortunately, the only
|
||
way to power down a PCI modem, is to reboot. This may fix a
|
||
<Quote>sync/no surf</Quote> condition that is caused by the modem, and
|
||
maybe other conditions too.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
|
||
See the <Link LinkEnd="nosync">above section</Link> on moving the modem
|
||
lock, stock and barrel to the NID and thus bypassing all inside wiring.
|
||
If the situation is improved there, then the problem is inside somewhere. If
|
||
not, it is a telco problem.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
RFI Bear-hunt: The DSL signal is fragile. There are a number of
|
||
things that can degrade it. RFI, or Radio Frequency Interference,
|
||
from sources in and around the home/office is one common source of
|
||
reduced signal strength, intermittent sync loss, low
|
||
sync rates and high line error rates that can cause retransmissions and
|
||
slow things down. DSL frequencies just happen to be in a range that is
|
||
susceptible to many potential RFI sources. Our test tool here is simply a
|
||
portable AM radio. Tune it to any channel where you can get clear reception
|
||
-- it makes no difference where. The AM radio will pick up RFI that is in
|
||
the same frequency range as the DSL signal. It will sound like
|
||
<Quote>frying bacon</Quote> type static. Put it against your computer's
|
||
power supply. You should hear some static. Move it away and the static
|
||
should fade pretty quickly. This will give you an idea of what RFI sounds
|
||
like. A decent quality power supply should produce only weak RFI --
|
||
probably not enough to cause a problem. Use the radio like a Geiger counter
|
||
and move it around your modem and DSL line. If you hear static, follow it
|
||
to the source. Things to be suspicious of: power supplies, transformers,
|
||
ballasts, electric motors, dimmer switches, high intensity lighting. Moving
|
||
the modem, or rerouting cables is sometimes enough. Keeping the line
|
||
between the modem and the wall jack as short as possible is a good idea
|
||
too.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Chronic sync problems are often due to a line problem somewhere.
|
||
Sometimes it is something as simple as a bad splice or corroded jack, and
|
||
easily remedied if it can be found. Most such conditions can be isolated
|
||
by a good telco tech. Check with your provider, and politely harass them
|
||
if you have to. If you get the run-around, ask to go over their heads.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If you are near the distance limits of DSL, and having off and on sync
|
||
problems, try the <Quote>Homerun</Quote> installation. See <Link
|
||
LinkEnd="homerun">above</Link>. This can be effective in improving
|
||
marginal signal/sync conditions.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
If using a surge protector, try it without the surge protector. Some may
|
||
interfere with the DSL signal.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
<Para>
|
||
Another possibility is a nearby AM radio station, or bandit ham radio
|
||
operator that are disrupting the DSL signal since they operate in a similar
|
||
frequency range. These may only cause problems at certain times of day, like
|
||
when the station boosts its signal at night. A good telco DSL tech may be
|
||
able to help minimize the impact of this. YMMV.
|
||
|
||
</Para>
|
||
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Network and Throughput Problems</Title>
|
||
|
||
<Para>
|
||
Read this section if your connection is up, but are having throughput
|
||
problems. In other words, your speed isn't what it should be based on your
|
||
bit rate plan, and your distance from the CO. <Quote>Network</Quote> here is
|
||
the WAN -- the ISP's gateway and local subnet/backbone, etc. Remember that a
|
||
marginal line can cause a reduced sync rate, and this will impact throughput.
|
||
See <Link LinkEnd="synctr">above</Link>.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The two factors we will be looking for are <Quote>latency</Quote> and
|
||
<Quote>packet loss</Quote>. Both are pretty easy to track down with the
|
||
standard networking tools <Command>ping</Command> and
|
||
<Command>traceroute</Command>. If either of these occur in our path, they
|
||
will impact performance. Latency means <Quote>responsiveness</Quote> or
|
||
<Quote>lag time</Quote>. Actually what we are interested in is abnormally
|
||
high latency, since there is always some latency. Packet loss is when a
|
||
packet of data gets dropped somewhere along the way. TCP/IP will know
|
||
it's been <Quote>lost</Quote>, and there will be a retransmission of the lost
|
||
data. Enough of this can really slow things down. Ideally packet loss should
|
||
be 0%.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
What we really need to be concerned about is that part of the WAN
|
||
route that we routinely traverse. If you do a traceroute to several different
|
||
sites, you will probably see that the first few <Quote>hops</Quote> tend to
|
||
be the same. These are your ISP's local backbone, and your ISP's upstream
|
||
provider's gateway. Any problem with any of this, and it will effect
|
||
everywhere you go and everything you do.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
We can start looking for packet loss and latency by pinging two or three
|
||
different sites, hopefully in at least a couple of different directions. We
|
||
will be looking for packet loss and/or unusually high latency.
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
$ ping -c 12 -n www.tldp.org
|
||
PING www.tldp.org (152.19.254.81) : 56(84) bytes of data.
|
||
64 bytes from 152.19.254.81: icmp_seq=0 ttl=242 time=62.1 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=1 ttl=242 time=60.8 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=2 ttl=242 time=59.9 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=3 ttl=242 time=61.8 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=4 ttl=242 time=64.1 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=5 ttl=242 time=62.8 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=6 ttl=242 time=62.6 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=7 ttl=242 time=60.3 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=8 ttl=242 time=61.1 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=9 ttl=242 time=60.9 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=10 ttl=242 time=62.4 ms
|
||
64 bytes from 152.19.254.81: icmp_seq=11 ttl=242 time=63.0 ms
|
||
|
||
--- www.tldp.org ping statistics ---
|
||
12 packets transmitted, 12 packets received, 0% packet loss
|
||
round-trip min/avg/max = 59.9/61.8/64.1 ms
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
The above example is pretty normal from here. (You probably have a very
|
||
different route to this site, and your results may thus be quite different.)
|
||
Apparently no serious underlying problems that would slow me down. The below
|
||
example reveals a problem:
|
||
|
||
</Para>
|
||
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
$ ping -c 20 -n www.debian.org
|
||
|
||
PING www.debian.org (198.186.203.20) : 56(84) bytes of data.
|
||
64 bytes from 198.186.203.20: icmp_seq=0 ttl=241 time=404.9 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=1 ttl=241 time=394.9 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=2 ttl=241 time=402.1 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=4 ttl=241 time=2870.3 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=7 ttl=241 time=126.9 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=12 ttl=241 time=88.3 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=13 ttl=241 time=87.9 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=14 ttl=241 time=87.7 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=15 ttl=241 time=85.0 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=16 ttl=241 time=84.5 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=17 ttl=241 time=90.7 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=18 ttl=241 time=87.3 ms
|
||
64 bytes from 198.186.203.20: icmp_seq=19 ttl=241 time=87.6 ms
|
||
|
||
--- www.debian.org ping statistics ---
|
||
20 packets transmitted, 13 packets received, 35% packet loss
|
||
round-trip min/avg/max = 84.5/376.7/2870.3 ms
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
High packet loss at 35%, and some really slow roundtrip times in there as
|
||
well. A little digging on this showed that it was a backbone router 13 hops
|
||
into the traceroute that was the problem. While making this site really slow
|
||
from here, it would only effect those routes that happen to hit that same
|
||
router. Now what would really hurt us is if something similar happens with a
|
||
router that we tend to go through consistently. Like our gateway, or maybe
|
||
the second hop router too. Find these with <Command>traceroute</Command>, by
|
||
just picking a random site:
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
$ traceroute www.bellsouth.net
|
||
|
||
traceroute to bellsouth.net (192.223.22.134), 30 hops max, 38 byte packets
|
||
1 adsl-78-196-1.sdf.bellsouth.net (216.78.196.1) 14.86ms 7.96ms 12.59ms
|
||
2 205.152.133.65 (205.152.133.65) 7.90ms 8.12ms 7.73ms
|
||
3 205.152.133.248 (205.152.133.248) 8.99ms 8.52ms 8.17ms
|
||
4 Hssi4-1-0.GW1.IND1.ALTER.NET (157.130.100.153) 11.36ms 11.48ms 11.72ms
|
||
5 125.ATM3-0.XR2.CHI4.ALTER.NET (146.188.208.106) 14.46ms 14.23ms 14.40ms
|
||
6 194.at-1-0-0.TR2.CHI2.ALTER.NET (152.63.65.66) 16.48ms 15.69ms 16.37ms
|
||
7 126.at-5-1-0.TR2.ATL5.ALTER.NET (152.63.0.213) 65.66ms 66.18ms 66.39ms
|
||
8 296.ATM6-0.XR2.ATL1.ALTER.NET (152.63.81.37) 66.86ms 66.42ms 66.40ms
|
||
9 194.ATM8-0.GW1.ATL3.ALTER.NET (146.188.233.53) 67.87ms 68.69ms 69.63ms
|
||
10 IMVI-gw.customer.ALTER.NET (157.130.69.202) 69.88ms 69.25ms 69.35ms
|
||
11 www.bellsouth.net (192.223.22.134) 68.74ms 69.06ms 68.05ms
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
The first hop is the gateway. In fact, for me the first two hops are
|
||
<Emphasis>always</Emphasis> the same, and the first three or four are often
|
||
the same. So a problem with any of these may cause a problem anywhere I go.
|
||
(The specifics of your own situation may be a little different than this
|
||
example.) A <Quote>normal</Quote> gateway ping (normal for me!):
|
||
|
||
</Para>
|
||
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
$ ping -c 12 -n 216.78.196.1
|
||
|
||
PING 216.78.196.1 (216.78.196.1) : 56(84) bytes of data.
|
||
64 bytes from 216.78.196.1: icmp_seq=0 ttl=64 time=14.6 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=1 ttl=64 time=15.4 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=2 ttl=64 time=15.0 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=3 ttl=64 time=15.2 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=4 ttl=64 time=14.9 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=5 ttl=64 time=15.3 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=6 ttl=64 time=15.4 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=7 ttl=64 time=15.0 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=8 ttl=64 time=14.7 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=9 ttl=64 time=14.9 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=10 ttl=64 time=16.2 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=11 ttl=64 time=14.8 ms
|
||
|
||
--- 216.78.196.1 ping statistics ---
|
||
12 packets transmitted, 12 packets received, 0% packet loss
|
||
round-trip min/avg/max = 14.6/15.1/16.2 ms
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
And a problem with the same gateway on a different day:
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
$ ping -c 12 -n 216.78.196.1
|
||
|
||
PING 216.78.196.1 (216.78.196.1) : 56(84) bytes of data.
|
||
64 bytes from 216.78.196.1: icmp_seq=0 ttl=64 time=20.5 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=3 ttl=64 time=22.0 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=4 ttl=64 time=21.8 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=6 ttl=64 time=32.0 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=8 ttl=64 time=21.7 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=9 ttl=64 time=42.0 ms
|
||
64 bytes from 216.78.196.1: icmp_seq=10 ttl=64 time=26.8 ms
|
||
|
||
--- adsl-78-196-1.sdf.bellsouth.net ping statistics ---
|
||
12 packets transmitted, 7 packets received, 41% packet loss
|
||
round-trip min/avg/max = 20.5/25.6/42.0 ms
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
41% packet loss is very high, to the point where many services, like HTTP,
|
||
come to a screeching halt. Those services that were working, were working
|
||
very, very slowly.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
It's a little tempting on this last real-life example to think this gateway
|
||
router is acting up. But, as it turned out, this was the result of a problem
|
||
in the DSLAM/ATM segment of the telco's network. So any first hop problem
|
||
with packet loss or high latency, may actually be the result of something
|
||
occurring before the first hop. We just don't have the tools to isolate
|
||
where it is starting well enough. Packet loss can be a telco problem, just as
|
||
much as an ISP/NSP problem. Or conceivably, even a modem problem. In which
|
||
case try resetting the modem by power cycling <emphasis>and</emphasis> by
|
||
unplugging/replugging the DSL cable (from the wall jack).
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
It is also quite possible for the modem itself to cause packet loss. The fix
|
||
here is to power cycle the modem, and resync by unplugging the DSL connection
|
||
for 30 seconds or so. In fact, any part of the connection can be a source of
|
||
packet loss -- modem, DSLAM, ATM network, etc.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
If you do find a problem within your ISP's network, it's time to report the
|
||
problem to tech support.
|
||
|
||
</Para>
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>Miscellaneous Network Problems</Title>
|
||
|
||
<Para>
|
||
Some odds and ends:
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Some Web pages won't load.</Emphasis> For PPPoX users, the
|
||
MTU value could be too high. This will cause packet fragmentation,
|
||
and likely will cause misbehaving routers to fail to route your
|
||
requests per Path MTU Discovery specs.The correct ppp0 device setting
|
||
should be a maximum of 1492, but actually it needs to be 8 bytes less
|
||
than any router you pass through on the way to the site. If a router
|
||
somewhere is misconfigured, you could have problems. Try experimenting
|
||
with lower MTU values. Any LAN hosts behind the connection, may even need
|
||
to be even lower -- 1452 or maybe even 1412. If ECN is enabled, it might
|
||
also cause this problem. Cured with <quote>echo 0 > cat
|
||
/proc/sys/net/ipv4/tcp_ecn</quote>.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Ping by IP address</Emphasis> works, but not hostname. The
|
||
nameservers are not being setup correctly in
|
||
<Filename>/etc/resolv.conf</FileName>. Check your client's (DHCP, PPPoX)
|
||
documentation or enter these manually with a text editor. Get the
|
||
correct DNS server addresses from your ISP.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>PPPoX disconnects</Emphasis>. Unfortunately, PPPoX
|
||
is more likely to drop connections than routed or bridged networks. PPP
|
||
can be sensitive to any line condition which results in a temporary
|
||
interruption of the connection. This may not be completely solvable,
|
||
depending on what and where the problem is. Check your client's docs for
|
||
<quote>LCP Keepalive</quote> features. There generally is a timeout on
|
||
each end of the connection if the other end does not respond. If worse
|
||
comes to worse, set up a cron job to watch the connection, and
|
||
re-establish if necessary.
|
||
|
||
</Para>
|
||
<para>
|
||
Some providers may also be enforcing idle timeout disconnects. This is
|
||
a different issue altogether, since it is deliberate. The solution here is to
|
||
switch providers if you can.
|
||
|
||
</para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Interface or route goes down for no reason</Emphasis>. If
|
||
<Command>ifconfig</Command> and/or <Command>route</Command> show the
|
||
interface and/or route has automagically disappeared, it may be due to
|
||
a buggy NIC driver.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Sub-par performance, or errors with the interface (e.g. eth0), may
|
||
possibly be caused by a duplex mismatch. This would be most apparent when
|
||
maxing out the connection. Most DSL modems and routers typically are set
|
||
to half duplex, and your NIC that interfaces with the modem should be set
|
||
likewise.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
|
||
</Sect3>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="throughput">
|
||
<Title>Measuring Throughput</Title>
|
||
|
||
<Para>
|
||
One of the first things most of us do is check our speeds to make sure we
|
||
aren't getting short changed, and that our system is up to snuff. Doing this
|
||
accurately is easier said than done however. First, remember you are losing
|
||
10-20% right off the top due to networking protocol overhead. Just how much
|
||
is <Quote>lost</Quote> here depends on your provider's network architecture,
|
||
where and how you are measuring this and other considerations. Most of us may
|
||
wind up being closer to 20% than 10%.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Then, any time you hit the Internet, there is some slight degradation of
|
||
performance with each hop you take. Now this may not amount to much, as long
|
||
as you are not taking too many hops and all the components -- your system,
|
||
your ISP's network, your ISP's upstream provider, and the destination itself
|
||
-- are all working like well oiled machines. But there's the rub -- how do
|
||
you really know with so many variables in the mix? One flaky interface, on
|
||
one router, on one hop along the path, may cause misleading results.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Your absolute max speed is going to be at your point of connection to your
|
||
ISP -- the ISP's gateway. It can only go downhill from there, not up! So the
|
||
ideal test is as close to home as possible. This eliminates as many unknown
|
||
variables as possible. If your ISP has a local ftp server, this is an
|
||
excellent place to run your own tests. (Run a traceroute though just to see
|
||
how local it really is.)
|
||
</Para>
|
||
|
||
<Para>
|
||
If your ISP does not have this, look for an ftp site that is close -- the
|
||
fewer the hops, the better. And look for one that isn't too busy, or you will
|
||
get misleading results. Find a large file -- like 10 Megs -- and time the
|
||
download. Try this over several days, and at different times of day. The
|
||
server, and the backbone, are going to be busier at certain times of day,
|
||
which can skew results and you want to eliminate these variables as much as
|
||
possible. Your provider cannot compensate for heavy backbone traffic,
|
||
backbone bottlenecks, slow or busy servers, etc.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
There are many test sites scattered around the web. Some are better than
|
||
others, but take these with a grain of salt. There are just too many
|
||
variables for these tests to reliably give you an accurate snapshot of your
|
||
connection and throughput. They may give you a general picture of whether you
|
||
are in the ballpark of where you think you should be or not. One good speed
|
||
test is <Ulink
|
||
URL="http://www.dslreports.com/stest/0">http://www.dslreports.com/stest/0</Ulink>.
|
||
Another test is <Ulink
|
||
URL="http://speedtest.mybc.com/">http://speedtest.mybc.com/</Ulink> (both are
|
||
Java). I find these to be better than some of the others out there.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Now keeping in mind that we are limited by the ~10-20% networking overhead rule,
|
||
here is an example. My speed is capped at 1472 Kbps sync rate. Minus the ~15%
|
||
is 1275 Kbps. My sync rate is known to be good and my distance to the CO is
|
||
about 11,000 Ft, which is close enough that I should be able to hit my real
|
||
world maximum throughput of 1275 Kbps or roughly 1.2-1.3 Mbps -- all other
|
||
things being equal. From dslreports.com speed test:
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
Test running..Downloaded 60900bytes in 5918ms
|
||
Downloaded 696000bytes in 4914ms
|
||
First guess is 1133kbps
|
||
fairly fast line - now test 2mb
|
||
Downloaded 1679100bytes in 11090ms
|
||
Upload got ok 1 bytes uploaded
|
||
Uploaded 1bytes in 211ms
|
||
Upload got ok 1 bytes uploaded
|
||
Uploaded 1bytes in 205ms
|
||
Upload got ok 1 bytes uploaded
|
||
Uploaded 1bytes in 207ms
|
||
Upload got ok 50000 bytes uploaded
|
||
Uploaded 50000bytes in 2065ms
|
||
Upload got ok 100000 bytes uploaded
|
||
Uploaded 100000bytes in 3911ms
|
||
|
||
** Speed 1211(down)/215(up) kbps **
|
||
(At least 24 times faster than a 56k modem)
|
||
Finish.
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
1.211 Mbps is probably about as good as I can realistically expect based on
|
||
my service. There is no reason for me to go troubleshooting or looking for
|
||
tweaks.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<Emphasis>Big Caution</Emphasis>: my ISP uses a caching proxy server for
|
||
web pages. This is a big equalizer for these kinds of web based
|
||
tests. Without that, I surely would have been significantly slower on this
|
||
test. The effect of the proxy is that you are actually testing throughput
|
||
from the proxy -- NOT the test site. Just FYI. Another note: at the same time
|
||
I tried another test site and was consistently getting 600-700 Kbps. So YMMV
|
||
with these tests. (Usually I get the same on each, more or less.) Timing a
|
||
large ftp download from two different sites, I calculated about 1.25 Mbps.
|
||
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
</Sect1>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
||
|
||
|
||
<Sect1 id="overview">
|
||
<Title>Appendix: DSL Overview</Title>
|
||
|
||
|
||
<Para>
|
||
DSL is a telephone loop technology that uses existing copper phones lines,
|
||
and provides a dedicated, high speed Internet connection. One of the big
|
||
advantages of some DSLs (notably ADSL), are that they can co-exist on the
|
||
same line with a traditional voice service such as <Quote>POTS</Quote> (Plain
|
||
Old Telephone Service), and even ISDN. This is accomplished by utilizing
|
||
different frequency ranges above the voice range (voice is up to 4KHz).
|
||
Essentially, this gives two lines in one: one for voice, and one for Internet
|
||
connectivity. When all is working normally, there should be no interference
|
||
between the two <Quote>lines</Quote>. This gives DSL a potentially broad
|
||
consumer base, and helps minimize costs for service providers.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
DSL is positioned for the Home and Small Office (SOHO) market that is
|
||
looking for high speed Internet access at reasonable prices. Since it also
|
||
typically provides dedicated, <Quote>always on</Quote> access, it can be used
|
||
for interconnecting low to mid range bandwidth servers, and provides a great
|
||
access solution for small LANs. It is also great for those Linux power users
|
||
that just want a fat pipe :-).
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Phone companies, and other independent telecommunications providers (CLECs),
|
||
are now deploying DSL to stay ahead of the Cable
|
||
companies -- the main consumer and SOHO competition for DSL providers. This
|
||
mad rush to get <Quote>a piece of the pie</Quote>, is bringing much
|
||
competition (a good thing!), much diversity, and some confusion, into the
|
||
consumer market. The DSL provider (often, but not always, the phone company)
|
||
will provide the DSL infrastructure. This would include your line, the DSLAM,
|
||
and physical connection to the outside world. From there it is typically
|
||
picked up by an ISP, who provides the traditional Internet services.
|
||
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
Consumer DSL plans are typically <Quote>best effort</Quote> services. While
|
||
boasting speeds approaching T1, and even surpassing that in some cases, it is
|
||
not necessarily as reliable as T1 however. Business class DSL offers more
|
||
reliability at a higher cost than consumer plans, and is a good compromise
|
||
where both reliability and bandwidth are at a premium. All in all, the cost
|
||
of DSL compared to traditional telco services, such as T1, is attractive and
|
||
substantially more affordable for home and small business users.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
DSL providers often do not have service contracts for home users,
|
||
while business class DSL services typically do include similar SLAs (Service
|
||
Level Agreements) to that offered for a T1 line.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The downside is that DSL is not available everywhere. Availability, and
|
||
available bit rate (speed), are purely a function of where you live, where
|
||
the telco has installed the prerequisite hardware, how far you are from the
|
||
DSLAM/CO, and the quality of your phone line (loop). Not all loops are
|
||
created equal, unfortunately. The primary limitation is distance.
|
||
|
||
</Para>
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="family">
|
||
<Title>The DSL Family</Title>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<BridgeHead renderas=sect3>ADSL</BridgeHead>
|
||
<Para>
|
||
Asymmetric Digital Subscriber Loop currently supports downstream rates up
|
||
to 8 Mbps, and upstream of 1024 Kbps, hence the <Quote>asymmetric</Quote>.
|
||
ADSL is far and away the most widely deployed consumer DSL, and was
|
||
specifically developed for the home and SOHO markets. The higher downstream
|
||
rates lends itself to those not running serious servers -- at least
|
||
anything more than a small, personal web site. ADSL is capable of sharing
|
||
data with a POTS (or ISDN) voice line, so an additional line is not
|
||
required. A big selling point. ADSL, like other DSLs, is limited by
|
||
distance. 18,000 ft (5.5 km) is a typical cut-off point for telcos. ADSL
|
||
does typically require either a splitter or filters to isolate the DSL
|
||
signal from POTS. Sometimes referred to as <Quote>full rate</Quote> ADSL in
|
||
order to differentiate it from G.Lite DSL. There are two line encodings for
|
||
ADSL: DMT and CAP. DMT (a.k.a. Alcatel compatible) has won the standards
|
||
battle and is now the standard and the most common. Also, note that modems
|
||
must be compatible with the encoding. In other words, a CAP modem will not
|
||
work with a DMT service, and vice versa. Also, ISDN requires
|
||
<quote>modems</quote> (NTs), and related hardware such as filters, that are
|
||
specific to that type of line since the signal on the line is very
|
||
different for POTS and ISDN.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<BridgeHead renderas=sect3>G.Lite</BridgeHead>
|
||
|
||
<Para>
|
||
G.Lite is sometimes referred to as <Quote>DSL Lite</Quote>,
|
||
<Quote>Universal DSL</Quote> or <Quote>splitterless ADSL</Quote>, is a
|
||
slower version of ADSL that requires no splitters <Emphasis>or</Emphasis>
|
||
filters. G.lite uses a <Quote>fast retrain</Quote> technique to negate the
|
||
various signal disturbances caused by normal POTS usage. Currently G.Lite
|
||
supports speeds up to 1.5 Mbps/512 Kbps, and at one time was expected to
|
||
become the dominant consumer DSL service. As of this writing, it is not
|
||
nearly as wide spread as <Quote>full rate</Quote> ADSL however.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<BridgeHead renderas=sect3>SDSL</BridgeHead>
|
||
|
||
<Para>
|
||
Single-pair Digital Subscriber Loop, or also sometimes referred to
|
||
as <Quote>Symmetric Digital Subscriber Loop</Quote> since it is indeed
|
||
symmetric with a current maximum rate of 1.5 Mbps/1.5 Mbps. SDSL requires a
|
||
dedicated line, and thus true SDSL is not as readily adaptable to the
|
||
consumer market as ADSL. SDSL also uses a 2B1Q encoding (same as ISDN and
|
||
some T1) which is considered more robust than the DMT or CAP encoding of
|
||
ADSL. True SDSL is generally considered more of a server quality DSL, and
|
||
is typically marketed as a business class service. It is worth noting that
|
||
some providers may be promoting a <Quote>SDSL</Quote> service that is
|
||
really ADSL pinched so that upstream/downstream are the same. Or vice
|
||
versa, SDSL with asymmetrically allocated bandwidth. Wasn't all this
|
||
confusing enough already?
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<BridgeHead renderas=sect3>IDSL</BridgeHead>
|
||
|
||
<Para>
|
||
ISDN Digital Subscriber Loop, 144 Kbps/144 Kbps is really a new and
|
||
improved ISDN from Lucent Technologies and uses the same 2B1Q line encoding
|
||
as ISDN, SDSL and others. IDSL does require a dedicated line however. The
|
||
benefits are that it is an <Quote>always on</Quote> technology, like other
|
||
DSLs, and provides an additional 16 Kbps over traditional ISDN. It is being
|
||
marketed by some DSL providers as a low end bit rate option, where line
|
||
quality is not sufficient for higher speeds such as that of ADSL.
|
||
Ironically, IDSL is generally priced significantly higher than ADSL.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<BridgeHead renderas=sect3>RADSL</BridgeHead>
|
||
|
||
<Para>
|
||
Rate Adaptive Digital Subscriber Loop was developed by Westell and has a
|
||
potential of 2.2 Mbps downstream and 1.0 Mbps upstream. What makes RADSL
|
||
more flexible is that the sync rate can be dynamically adjusted up or down
|
||
as line conditions change. This makes it more of a viable alternative where
|
||
line conditions are marginal due to distance or other factors. In many
|
||
respects, RADSL is an enhanced ADSL to meet a more diverse set of line
|
||
conditions. Like ADSL, RADSL can piggyback on the POTS line. RADSL does not
|
||
require any splitters or filters.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<BridgeHead renderas=sect3>HDSL</BridgeHead>
|
||
|
||
<Para>
|
||
High bit-rate DSL was one of earliest versions of DSL. HDSL
|
||
requires multiple, dedicated wire pairs, and is symmetric at 1.5
|
||
Mbps/1.5 Mbps (the speed actually depends on number of wire pairs
|
||
used). Not a viable alternative for the consumer or SOHO markets.
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<BridgeHead renderas=sect3>VDSL</BridgeHead>
|
||
|
||
<Para>
|
||
Very high rate Digital Subscriber Loop is a DSL still in development
|
||
with a current downstream capacity of 52.8 Mbps, and upstream of
|
||
2.3 Mbps. At this time, VDSL is limited to very short loop lengths,
|
||
and is not yet a viable alternative. It may find application where
|
||
there is fiber to the neighborhood, and thus the copper loop
|
||
segment is relatively short.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<BridgeHead renderas=sect3>UDSL</BridgeHead>
|
||
|
||
<Para>
|
||
Unidirectional Digital Subscriber Loop is a proposal from Europe that is
|
||
not yet in use.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<BridgeHead renderas=sect3>G.SHDSL</BridgeHead>
|
||
|
||
<Para>
|
||
The standards for G.SHDSL have just recently been finalized. SHDSL
|
||
includes many enhancements, including better reach, better rate adaptation,
|
||
and better upstream bandwidth. G.SHDSL is symmetric with speeds up to 2.3
|
||
Mbps, and will more than likely be marketed as an SDSL alternative.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>The DSLAM</Title>
|
||
|
||
<Para>
|
||
This technology is made possible by the placement of DSLAMs, or Digital
|
||
Subscriber Loop Access Multiplexers, from such suppliers as <Ulink
|
||
url="http://www.alcatel.com">Alcatel</Ulink> and
|
||
<Ulink
|
||
URL="http://www.cisco.com/warp/public/cc/pd/si/6000/prodlit/c6160_ds.htm">Cisco</Ulink>,
|
||
in the telco's Central Office, or sometimes a suitable remote location.
|
||
DSLAMs come in various shapes and sizes, and are the one, single complex and
|
||
costly component of a DSL connection. When a qualified phone line is
|
||
connected to a modem at the user's end of the loop, a high speed digital
|
||
connection is established, typically over ATM, or sometimes frame relay. The
|
||
DSLAM splits the signal back into separate voice and data channels. The voice
|
||
channel stays within the telco network, whereas the data is picked up by an
|
||
ISP (typically).
|
||
|
||
</Para>
|
||
|
||
<BridgeHead renderas=sect3>
|
||
Figure 4: A Typical DSL Connection Path
|
||
</Bridgehead>
|
||
|
||
<Para>
|
||
<Literal>
|
||
<MSGText>
|
||
<LiteralLayout>
|
||
|
||
Voice -+ +---> Voice
|
||
|<-- copper loop --> DSLAM/CO <--{ATM cloud}--->|
|
||
modem -+ | +---> Inet
|
||
| | |
|
||
ether..|..... DSL/ATM here ....|.... raw ATM here .....|.. TCP/IP ..
|
||
| |
|
||
SOHO...|............ telco (ILEC or CLEC) .............|.. ISP ..| NSP
|
||
|
||
</LiteralLayout>
|
||
</MSGText>
|
||
</Literal>
|
||
</Para>
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>Sync</Title>
|
||
|
||
<Para>
|
||
A good, working connection to the DSLAM is referred to as
|
||
<Quote>syncing</Quote>. This is typically indicated by LEDs on the modem.
|
||
Without sync, nothing happens. The modem will establish a sync rate which is
|
||
often throttled by the provider at a predefined limit. This limit, or
|
||
<Quote>cap</Quote>, is at the provider's discretion and is part of the
|
||
service that is being provided. Your modem may well sync at a higher rate
|
||
than the <Quote>cap</Quote>, but your speed will be limited to whatever
|
||
<Quote>cap</Quote> the provider is enforcing. So while ADSL has an upward
|
||
theoretical limit of 8 Mbps, you will not see that speed -- unless of course
|
||
your provider is selling an 8 Mbps plan. Most plans are well below this.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Below is the status information from a SpeedStream 5660 modem/router via the
|
||
built-in telnet interface. In this example, the customer is on a 1.5 Mbps/384
|
||
Kbps service:
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
Command-> show dslstatus
|
||
|
||
--- Channel Info ATU-R ATU-C
|
||
Current TX Rate - 384000 1500000
|
||
Previous TX Rate - 0 0
|
||
CRC Block Length - - -
|
||
Interleave Delay - - -
|
||
|
||
--- Physical Layer Info ATU-R ATU-C
|
||
Current Attainable Rate - 448433 3890243
|
||
Current SNR Margin - 10.5 17.0
|
||
Current Attenuation - 54.5 31.5
|
||
Current Output Power - 3.0 16.0
|
||
Current Status:
|
||
Defects detected - No No
|
||
Loss of Framing - No Loss No Loss
|
||
Loss of Signal - No Loss No Loss
|
||
Loss of Power - No Loss No Loss
|
||
Loss of Signal Quality - No Loss No Loss
|
||
|
||
--- ATU-R Line Status
|
||
Line Coding - DMT
|
||
Line Type - Fast or Interleaved
|
||
|
||
Command->
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
First notice the <Quote>Current Attainable Rate</Quote> in the
|
||
<Quote>ATU-C</Quote> column. This is the downstream sync rate negotiated by
|
||
the modem and DSLAM, which is over 3.5 Mbps. The actual speed is limited,
|
||
however, to 1.5 Mbps/384 Kbps from the first row <Quote>TX Rate</Quote>. This
|
||
is the theoretical limit of this connection. This limit, or
|
||
<Quote>cap</Quote>, can be enforced at the DSLAM, as is the case the here, or
|
||
further upstream. Had the first row <Quote>TX Rate</Quote> been lower than
|
||
the provider's imposed limit, then this would indicate some kind of problem
|
||
with the connection, perhaps due to distance or some kind of line impairment.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The attainable sync rate is the result of a number of factors, including wire
|
||
distance to the DSLAM, quality of both inside and outside wiring, the loop
|
||
wire gauge and various other factors within the loop. Actual measurable,
|
||
real world throughput, on the other hand, is first of all dependent on sync
|
||
rate. Low sync rate means low throughput. In the above example, had the sync
|
||
rate been lower, say 500 Kbps, then that would be the maximum for that
|
||
connection, even though the customer is paying for a 1.5 Mbps service.
|
||
</Para>
|
||
|
||
<Para>
|
||
Secondarily, throughput will depend also on the ISP's network, and then the
|
||
ISP's upstream provider. You will lose approximately 10-20% of potential
|
||
throughput to networking overhead. In the above example where the connection
|
||
is throttled at 1.5 Mbps, the actual, real-world maximum throughput would be
|
||
somewhere around 1.2-1.3 Mbps when overhead is taken into account. Moreover,
|
||
once you hit the Internet proper, all bets are off as there are any number of
|
||
factors that may impact throughput. A overloaded or busy server is likely to
|
||
be slow no matter how fast your DSL connection is.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="dslmodems">
|
||
<Title>DSL Modems</Title>
|
||
|
||
<Para>
|
||
The <quote>modem</quote> is the last piece of the connection. The modem is
|
||
connected directly to the DSLAM via the copper loop on the telco end, and
|
||
plugs into a wall jack on your end. When all is well, the modem
|
||
<Quote>syncs</Quote> with the DSLAM, and then makes an IP connection to the
|
||
ISP, and off we go!
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
For Linux users, <Emphasis>the modem is a very important
|
||
consideration</Emphasis>! There are many modems supplied by ISPs that are not
|
||
Linux compatible. Your best bet is an external, ethernet interfaced modem (or
|
||
modem/router combo) that connects via a standard ethernet NIC, since many
|
||
other modem options (PCI, USB, onboard) will not work due to a lack of
|
||
drivers at this time! All ethernet based modems will work fine. (See the
|
||
<Link LinkEnd="modems">Modems Section</Link> for an up-to-date list of
|
||
compatible modems.) ISDN users will need a modem (NT) designed specifically
|
||
for DSL over ISDN.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
With ethernet modems, the only potential compatibility issue is the Network
|
||
Card (NIC). (And really any compatible ethernet NIC should do just fine --
|
||
100 Mbps is not even necessary.) You are probably better off anyway, since PCI and
|
||
USB modems can be more problem prone. If your chosen provider does not
|
||
offer a compatible modem as an option, then you either need to look
|
||
elsewhere, or you will have to buy one outright from a third party.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
As always, there are exceptions. <Ulink URL="http://www.xpeed.com">Xpeed</Ulink>
|
||
now has drivers for two PCI modems included with the kernel drivers (as of
|
||
2.2.18, not in 2.4 yet though AFAIK). These are the first open source Linux DSL modem
|
||
drivers, and is welcomed news. <Ulink
|
||
URL="http://www.alcateldsl.com">Alcatel's</Ulink> ADSL SpeedTouch USB modem
|
||
now has Linux drivers. And more recently, the Eci Hi Focus ADSL USB Modem
|
||
has drivers (and some related chipsets are supported as well, see
|
||
<ulink url="http://eciadsl.sourceforge.net/">http://eciadsl.sourceforge.net/</ulink>).
|
||
IteX PCI ADSL modems, based on the Apollo chipset, have Linux drivers.
|
||
(Modems using this chipset are sold under a number of various brand names.)
|
||
Diamond also makes [made?] an internal PCI modem which has binary-only
|
||
drivers, but it is not in widespread use, and seems to be discontinued at
|
||
this point. It is also possible to make a direct ATM connection using a modem
|
||
plus an ATM network card, though this delivery system is not used in the U.S.
|
||
as far as I know, and should not be considered as a viable option. This would
|
||
also require a 2.4 kernel.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The most common type of modem in use today is actually a combination
|
||
<Quote>bridge</Quote> and modem device. The bridge is a simple device,
|
||
typically with little configuration. Network traffic passes blindly across
|
||
the ATM to ethernet bridge in either direction. Your point of exposure is the
|
||
interface (typically a NIC) that is connected to the modem/bridge.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Some ISPs are also offering <Quote>routers</Quote>. These are basically
|
||
combination modem/routers that can handle NAT, and may have other feature
|
||
enhancements such as port forwarding, a built in hub, etc. These are all
|
||
external, so should work too. But probably not a big deal for Linux users,
|
||
since Linux can do anything these do, and more. A locked down Linux box makes
|
||
a most excellent firewall/gateway/proxy!
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
To confuse things even more, there are also all-in-one devices: combo
|
||
bridge+router+modem, sometimes called <Quote>brouters</Quote>. In this case,
|
||
the modem can be configured for either bridged or routed modes -- but it
|
||
can't be both at the same time.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
All providers should make available a modem of some sort. Many ISPs will have
|
||
more than one modem option. Some may give away the modem at no additional
|
||
charge. Some may offer a free base model, and charge the difference for the
|
||
better models with more features. Many of the modems that ISPs supply are not
|
||
available through normal retail channels. Should you want to buy one
|
||
yourself, this leaves used equipment outlets (e.g. ebay), or possibly buying
|
||
a modem that your ISP may not support (i.e. a possibility of no tech support
|
||
if you have a problem).
|
||
</Para>
|
||
|
||
<Para>
|
||
While some ISPs provide modems that are not readily available through normal
|
||
retail channels, there are a number of manufacturers that are getting on the
|
||
DSL modem bandwagon, and offering a good selection. Most have a
|
||
number of enhancements. At this time Alcatel (now owned by Thomson), Intel,
|
||
Zyxel, Cisco, 3Com, and Cayman have products available. Depending on model
|
||
and feature set, prices range from a little over $100 US to $800 and up. Many
|
||
of these handle their own authentication and encapsulation (DHCP, PPPoE,
|
||
etc).
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Are some modems better than others? Short, easy answer: no. Modems are not
|
||
much of a factor in speed in most cases. But some do have enhanced features,
|
||
such as diagnostics or the combo modem/routers. Ethernet modems are
|
||
generally considered the most reliable. Fewer IRQ hassles, no buggy drivers,
|
||
etc. So the fact that Linux users are mostly relegated to ethernet modems is
|
||
a blessing in disguise really. Are any of these better than others? Hard to
|
||
say since most of this is so new there is not enough of a track record to
|
||
compare brands and models with any degree of assurance. In other words, any
|
||
old external, ethernet modem should do -- provided it matches your
|
||
provider's DSL, and is configured for that service. Remember, there can be
|
||
differences here.
|
||
|
||
</Para>
|
||
|
||
<Warning>
|
||
<Para>
|
||
Make sure any third party modem or router you may purchase is compatible with
|
||
your DSL provider. There are two major line encodings for ADSL (CAP and DMT
|
||
a.k.a. Alcatel compatible), and several options for IP encapsulation. And
|
||
different DSLs (SDSL, IDSL, etc) will require their own modems too, as will
|
||
ISDN lines. Your provider should have a list of compatible options. It may
|
||
well have to be configured for your ISP's service too. Don't expect it to
|
||
work right out of the box either (unless it does indeed come from your
|
||
provider). Many are accessible via telnet, or a web browser, where the
|
||
configuration options are available. See the owner's manual for this.
|
||
|
||
</Para>
|
||
</Warning>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="ispconn">
|
||
<Title>The ISP Connection</Title>
|
||
|
||
<Para>
|
||
The modem connects to the DSLAM, and then the DSLAM is connected to the
|
||
telco's ATM network (or frame relay), where it is picked up by the ISP. The
|
||
ISP typically will take over at what we <Quote>see</Quote> as the first hop on a
|
||
<Command>traceroute</Command>. Everything up to that point is in the hands
|
||
of the telco/DSL provider. The ISP will connect to the telco's ATM network
|
||
via a high-speed data connection, usually ATM over a DS3 (45 Mbps) or
|
||
possibly an OC-3 (155 Mbps). The important thing here is that an ISP must
|
||
<Quote>subscribe</Quote> with your telco to provide this connection. The ISP
|
||
will provide traditional ISP type services: email, DNS, news, etc. It is
|
||
really a two step connection -- DSL from one provider, Internet from a second
|
||
-- even though these may be combined into one billing.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
The Baby Bells (RBOCs) in the U.S. all own ISPs. These, of course, are
|
||
connected to their DSLAMs, and are providing Internet services via the
|
||
telco's ISP subsidiary. Many independent ISPs are availing
|
||
themselves of the ILEC's DSL services, and in essence
|
||
<Quote>reselling</Quote> the DSL services of the ILEC. While the underlying
|
||
infrastructure is the same in this case, having more than one ISP working out
|
||
of a CO may mean a better selection of features and prices for the consumer.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
CLECs (independent telcos) are now installing their own DSLAMs in many U.S.
|
||
markets. This makes them a direct competitor to the ILEC. In this scenario,
|
||
there would be two (or more) DSL providers in the same CO, each with their
|
||
own DSLAM(s), and each competing against each other. This complicates the ISP
|
||
situation even further, as each DSL provider will be <Quote>partnered</Quote>
|
||
with one or more ISPs. If you are lucky here, you will have many choices of
|
||
plans and pricing structures.
|
||
</Para>
|
||
|
||
<Para>
|
||
At this time, there is a shake out going on in the U.S. market. The
|
||
independents are all struggling to match the deep pockets of the regional
|
||
phone companies. The independents that have survived are now focusing more
|
||
on small business and higher-end consumer customers. This means, it will
|
||
cost more, but you should also expect to get more. Especially, in the
|
||
quality department.
|
||
</Para>
|
||
|
||
<Para>
|
||
Typically, your service agreement is with the ISP, and not the DSL
|
||
provider. This makes the actual DSL provider a <Quote>behind the
|
||
scenes</Quote> player. This may vary, and in some cases, you may wind up
|
||
with a separate service agreement for both the DSL provider and the ISP.
|
||
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Availability</Title>
|
||
|
||
<Para>
|
||
Who can get DSL? The first requirement is that a telco has installed the
|
||
necessary hardware somewhere on their end. Typically this is in the CO. You
|
||
have no choice on which CO is yours -- it is wherever your loop terminates.
|
||
If your CO has a DSLAM, and the necessary other components, then DSL may be
|
||
available to you. This is often known as <Quote>pre-qualifying</Quote>, and
|
||
is Step One in getting service.
|
||
</Para>
|
||
|
||
<Para>
|
||
More and more <Quote>remote terminals (aka DSLAMs)</Quote> are being
|
||
deployed. This is certainly good news for those that are a long way from
|
||
the CO. CO distance is not the limiting factor it once was.
|
||
</Para>
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>Ordering</Title>
|
||
|
||
<Para>
|
||
Before ordering service, check to see what providers there are in your area.
|
||
Look for options on both the telco/DSL side and the ISP side. You may have
|
||
several options, including the large phone companies, as well as smaller,
|
||
local ISPs. Once an order is placed, you must wait for the qualification
|
||
process before a provider will agree to provide service.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3 id="qualify">
|
||
<Title>Qualifying</Title>
|
||
|
||
<Para>
|
||
Once local availability is established, the next step is
|
||
<Quote>qualifying</Quote> your loop. The provider will run various tests to
|
||
make sure that your loop can handle the DSL signal. This is to determine how
|
||
suitable your line is for DSL, and maybe what level of service will be
|
||
available to you. You probably will have to order service just to find out
|
||
this much. It can be a fairly involved process, with a variety of different
|
||
tests being run. There are a number of things that may
|
||
<Quote>disqualify</Quote> a line. The most common limitation is distance.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
All DSLs have distance limitations. ADSL is limited
|
||
to a loop length of roughly 18,000 ft (5.5 km), but the actual cut off point
|
||
will vary from provider to provider. The further away you are, the weaker the
|
||
signal, and the potential for poor connections is greater. With ADSL, if you
|
||
are within approximately 12,000 ft (3.7 km), you should be able to get at
|
||
least 1.5 Mbps -- all other things being equal. IDSL has even greater reach,
|
||
mainly because the maximum speed for IDSL is considerably lower at 144
|
||
Kbps/144 Kbps.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Still even if you're close enough, there are a number of potential
|
||
impediments that may disqualify a line. Two such common impediments
|
||
are load coils and bridge taps. These are aspects of the old telco
|
||
infrastructure that once were deemed beneficial, but now are getting
|
||
in the way of the newer, digital technologies. <comment>This next
|
||
sentence could stand rephrasing. HB - ??? sounds good to me?</comment>
|
||
Whether you hit a snag like this or not, is pretty much hit or miss. Fiber
|
||
anywhere in the loop is also a disqualifier. The provider may take steps to
|
||
<Quote>clean</Quote> the line. Just how far they are willing to go will vary
|
||
from provider to provider, and this will likely add additional time to the
|
||
installation process.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Once the line is <Quote>qualified</Quote>, the next step is deciding on which
|
||
plan is suitable for your situation. The provider may have differing plans
|
||
available depending on how strong a signal they think your line can handle.
|
||
If you are marginal, you will not be qualified for the higher speed plans.
|
||
And if price is a factor, having a tiered pricing structure is good also
|
||
since the lower end plans are obviously less expensive. How this is
|
||
structured also varies wildly from provider to provider. Since, DSL is a new
|
||
service, and providers are trying to find the right price/feature
|
||
combinations that will attract the most users and thus gain a competitive
|
||
edge.
|
||
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Some common data rates:
|
||
</Para>
|
||
|
||
<Para>
|
||
<BlockQuote>
|
||
<LiteralLayout>
|
||
|
||
Downstream/Upstream
|
||
|
||
128 Kbps/128 Kbps
|
||
|
||
256 Kbps/256 Kbps
|
||
|
||
384 Kbps/128 Kbps
|
||
|
||
640 Kbps/90 Kbps
|
||
|
||
1.5 Mbps/384 Kbps
|
||
|
||
2.0 Mbps/512 Kbps
|
||
|
||
7.1 Mbps/1024 Kbps
|
||
|
||
</LiteralLayout>
|
||
</BlockQuote>
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
and a near infinite number of other possibilities. The cost of different
|
||
plans generally goes up with their speed.
|
||
</Para>
|
||
|
||
<Para>
|
||
Should you be disqualified, and have other options, get a second opinion.
|
||
Calculating the effective loop length is by no means an exact science. There
|
||
is plenty of room for errors. Also, some providers may go to greater lengths
|
||
to <Quote>clean</Quote> the loop than others. And, if you have more than one
|
||
phone line, and are disqualified, then try the other line. Just because they
|
||
both terminate at your location, does not necessarily mean they are the same
|
||
length! The telco network is full of surprises.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="cproviders">
|
||
<Title>Choosing Providers</Title>
|
||
|
||
<Para>
|
||
Should you have more than one choice, here are some things to keep in mind
|
||
when comparing services from different providers. If you are in a populous
|
||
area, chances are you do have a number of choices. There is a dizzying array
|
||
of possibilities at this time. Remember too, that it is a two step
|
||
connection: DSL provider and ISP. You may have choices for each.
|
||
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>A compatible modem</Emphasis>. For now with Linux (or any
|
||
alternative OS) this essentially means an ethernet interface. (There are
|
||
rare exceptions.) <Quote>Routers</Quote> (i.e. combo modem/routers) should
|
||
be OK too since these seem to be all ethernet devices.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Installation</Emphasis>. A self-install option, of course, let's
|
||
anyone get up and running, and is less expensive. But if there is no
|
||
self-install available, will the provider install onto a Linux only
|
||
site? Many will not! Having a Windows (or Mac) box temporarily available
|
||
is a work around here. Even a laptop may be enough.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Static vs Dynamic IP Address</Emphasis>. If wanting to run
|
||
servers, or hosting your own domain, static is the way to go. A dynamic
|
||
IP, on the other hand, makes you a little harder to find should you wish
|
||
to remain <Quote>invisible</Quote>, or a least harder to keep track of.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Encapsulation</Emphasis>. Is the connection
|
||
<Quote>Bridged</Quote> or <Quote>PPP</Quote>. PPPoX has the reputation of
|
||
being not as stable a connection, and not <Quote>always on</Quote>. PPPoE
|
||
requires client software to manage the connection, so one more layer of
|
||
code.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Server Policy</Emphasis>. Some ISPs are fairly open about this,
|
||
while others forbid any servers -- even personal web sites. Others may even
|
||
go so far as to block certain ports.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Contract</Emphasis>. Is there a contract, and what are the out
|
||
clauses? Cancellation fees?
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Connection Limits</Emphasis>. Is it <Quote>always on</Quote> (at
|
||
least theoretically :-)? Are there session limits, or idle timeouts? Is
|
||
bandwidth metered and limited to so much per month? Do they forbid a LAN
|
||
behind the connection (dumb!)?
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Linux Support</Emphasis>. A few ISPs may offer some degree of
|
||
tech support for Linux, but most will not. This isn't so bad, as long as
|
||
they don't go overboard and refuse to help with anything just because you
|
||
run a non-supported OS. (<Quote>Supported</Quote> means like <Quote>tech
|
||
support</Quote>.) If they say <Quote>we don't care</Quote>, you should be
|
||
good to go.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Free Dialup Account</Emphasis>. A nice thing to have if the
|
||
connection is down, or you just need to check mail from another location.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Setup program</Emphasis>. A few ISPs may have a setup program you
|
||
are required to run the first time you connect in order to setup your
|
||
account. This will likely not have a Linux version. (BellAtlantic.net was
|
||
doing this at last report.) Other than this, there is nothing proprietary
|
||
about DSL, and related protocols.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Emphasis>Reliability and Quality of Service</Emphasis>. Ask around in your
|
||
local area from those that have the same DSL provider and ISP. A local LUG
|
||
is a good place to get this kind of info. How much down time (hopefully not
|
||
much)? Are mail and news services good? Backbone routing? Tech support?
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
<Para>
|
||
There are a number of other options and features that might be worth looking
|
||
at too: multiple IPs, domain hosting (DNS), free web space, number of
|
||
email accounts, web mail, etc. All things considered, the better plans
|
||
are probably going to cost more for a reason.
|
||
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
</Sect1>
|
||
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
||
|
||
<Sect1 id="faq">
|
||
<Title>Appendix: FAQ</Title>
|
||
|
||
<Para>
|
||
Some Frequently Asked Questions about DSL and Linux.
|
||
</Para>
|
||
|
||
<Para>
|
||
<OrderedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. Does DSL work with Linux?
|
||
</Para>
|
||
|
||
<Para>
|
||
DSL is a technology, or more correctly, a group of related technologies.
|
||
This is akin to asking if Linux works with telephones. The technology
|
||
itself does not care. So, the short answer is <Quote>Yes, of
|
||
course!</Quote>. The long answer is that if there are any impediments, they
|
||
are being imposed by the provider. There are things they may do, that can
|
||
make getting Linux up and running, more of a challenge than it needs to be.
|
||
Not having a compatible modem option available is one common gotcha. Also,
|
||
if the telco or ISP is doing the installation, they may require a Windows
|
||
or Mac system to be available. This saves them the costs of training their
|
||
techs on various alternative OSes. Buyer beware!
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Basically all DSL does, is facilitate a high speed Internet connection. At
|
||
some point, it is all TCP/IP, and Linux, of course, handles TCP/IP quite
|
||
well.
|
||
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. Where can I find drivers for my PCI (or USB) modem?
|
||
</Para>
|
||
|
||
<Para>
|
||
With a few exceptions, you probably can't, because they are just not
|
||
available. Your best bet is an external, ethernet interfaced modem for all
|
||
intents and purposes. If your provider does not offer one, you will have
|
||
to find another provider, or buy your own modem outright. Just make sure
|
||
it is compatible with your provider's flavor of DSL.
|
||
</Para>
|
||
|
||
<Para>
|
||
The are exceptions to every rule. See the <Link LinkEnd="modems">Modems
|
||
Section</Link> for a list of compatible modems as of this writing.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
If an incompatible modem puts you in a bind, hopefully you will take the
|
||
time to politely harass the manufacturer ;-).
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
This situation is changing for the better. <Ulink
|
||
URL="http://www.xpeed.com">Xpeed</Ulink> now has drivers included in the
|
||
kernel for source for their PCI IDSL and SDSL modems. This is good news!
|
||
<Ulink URL="http://www.alcateldsl.com">Alcatel</Ulink> has
|
||
released drivers for the Alcatel SpeedTouch USB ADSL modem. IteX has
|
||
also released drivers for their PCI ADSL modem. Hopefully
|
||
more will follow suit. (Make sure you are reading the latest version of
|
||
this document, as I have intentions of keeping this situation updated as
|
||
needed.)
|
||
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. How fast or good of a network card do I need?
|
||
</Para>
|
||
|
||
<Para>
|
||
Any card that is compatible with Linux should work fine. Remember even
|
||
low-end cards are 10 Mbps, and no consumer class DSL is near that at this
|
||
time. I would suggest a reasonably good quality card, just to help
|
||
eliminate the possibility of errors and premature failure.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. How can I find out when DSL will be available in my area?
|
||
</Para>
|
||
|
||
<Para>
|
||
Just where and when DSL gets deployed is totally in the hands of
|
||
your friendly local telco. They obviously can't do everyone at
|
||
once, so they probably are selecting areas based on competitive
|
||
factors. Getting a straight answer from a telco on this question
|
||
can also be a challenge. Probably so as not to tip their hand to
|
||
competitors. Unfortunately, it is a question only they can answer.
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. I was disqualified because I am too far away. What can I do?
|
||
</Para>
|
||
|
||
<Para>
|
||
Move? Seriously, there isn't much you can do. If there are other providers,
|
||
get another opinion. You never know. Determining the loop length is an
|
||
inexact science, and there is room for errors. Many use databases for
|
||
this, and these databases routinely have some inaccuracies. Some providers
|
||
too, may be more aggressive in taking steps to help you out and clean up
|
||
the line. Also, some providers offer low-end speed services that have
|
||
greater reach. Maybe this will become available in your area. Or, the telco
|
||
may install, at some point, remote devices for customers who are now too
|
||
far away.
|
||
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. I am told I am 20,000 ft from the CO. Isn't that too far? Will my
|
||
speeds be really bad?
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Not necessarily. This distance limitation is not where the CO is, but
|
||
where the DSLAM is. These are often installed in CO's, but more and more
|
||
are being installed in remote locations in order to expand the reach
|
||
of DSL service.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. What are the speed tweaks for Linux?
|
||
</Para>
|
||
|
||
<Para>
|
||
This may not be necessary. Linux is pre-tweaked for the most part,
|
||
unlike some versions of Windows that really need some registry hacks to get
|
||
optimum performance. If you have a high latency connection, you may
|
||
benefit from increasing the TCP Receive Window. See the <Link
|
||
LinkEnd="tuning">Tuning</Link> section.
|
||
</Para>
|
||
|
||
<Para>
|
||
Now if you are convinced you are not getting the performance you should
|
||
based on your distance and line conditions, then there might be a problem
|
||
somewhere. See the <Link LinkEnd="tuning">Troubleshooting</Link> section for
|
||
more. What you may need is a fix, more than a tweak.
|
||
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
|
||
<Para>
|
||
Q. My service is limited to 640K (for example). Can I get better speed by
|
||
getting a faster modem? Any way around this?
|
||
</Para>
|
||
|
||
<Para>
|
||
No, and no. The modem has little bearing on how fast your connection is for
|
||
all intents and purposes. The provider has a mechanism in place for
|
||
limiting your speed somewhere in the pipe before you hit the Internet.
|
||
There is no way to defeat this.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. Can I download and upload at the same time? Is one effected by the
|
||
other?
|
||
</Para>
|
||
|
||
<Para>
|
||
The upstream and downstream channels use separate frequency ranges within
|
||
the DSL signal, so simultaneous upload/download is not a problem and
|
||
available bandwidth is not normally impacted.
|
||
</Para>
|
||
|
||
<Para>
|
||
Where there may be somewhat of an adverse impact, is with asymmetric DSLs
|
||
like ADSL, <Emphasis>and</Emphasis> both the upstream and downstream are
|
||
simultaneously saturated. This is a TCP 'feature' and not DSL related
|
||
though. This can adversely effect the faster stream (i.e. the downstream).
|
||
How much of an impact depends on a slew of factors and is beyond the scope
|
||
of this document, but is more pronounced with higher ratios of downstream
|
||
to upstream (e.g. 640/90). See the <link linkend="bottlenecks">Tuning</link>
|
||
on how to mitigate this effect.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. I am paying for 768 Kbps service, and the best I ever get is 640 Kbps or
|
||
so. Why? Is the service oversold? I am not getting what I pay for.
|
||
</Para>
|
||
|
||
<Para>
|
||
You will lose 10-20% of the rated capacity due to the overhead inherent
|
||
in the various protocols utilized. Most of us will probably fall closer to
|
||
20%. This is just a fact of life for everybody. Just how much is lost here
|
||
depends on various factors. You seem to be close to your maximum when this
|
||
is taken into consideration. Also, if you read the fine print, many ISPs
|
||
are advertising speeds <Quote>up to</Quote> such and such. Check your
|
||
service agreement and see if there are any guarantees. If there are, they
|
||
may be well below the advertised maximum speed, and may be based on sync
|
||
rate instead of actual throughput. Though this may vary from provider to
|
||
provider as well.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Also, be careful how you test this. Some of the so-called test sites can be
|
||
pretty unreliable. There can be many factors between you and that site that
|
||
can impact your throughput and skew results -- not the least of which is
|
||
how many people might be trying that same test at the same time. The best
|
||
test is via FTP download from a known good, close, not too busy site.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<listitem>
|
||
<para>
|
||
Q. Can DSL work with ISDN, and how is this different?
|
||
</para>
|
||
<para>
|
||
Yes, there have been DSL capable modems and service providers for some
|
||
time. In fact, this is common in parts of Europe. So this is not an issue.
|
||
</para>
|
||
<para>
|
||
What makes ISDN different is the underlying signal on the line is
|
||
fundamentally different than a POTS line. This means that any physical
|
||
layer hardware has to be compatible with ISDN (and conversely it is
|
||
incompatible with POTS lines). So this means the NT (modem), filters, etc,
|
||
all have to be designed for ISDN. Other than these low level issues, the
|
||
other aspects of DSL implementation are the same (e.g. network protocols).
|
||
</para>
|
||
</listitem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. Why does PPPoX have such a bad rap?
|
||
</Para>
|
||
|
||
<Para>
|
||
The occasional disconnects is one of the biggest gripes. PPP seems to be
|
||
sensitive to any interruptions in the connection. Generally a disconnect
|
||
means a new IP. And there are those that say PPP, by its very nature, was
|
||
never meant to be an <Quote>always on</Quote> protocol. PPP is a session
|
||
management protocol at heart, that requires a user to initiate a
|
||
connection and authenticate him or herself. PPPoE/A are not yet
|
||
particularly mature protocols either. They do not have much of a history
|
||
or track record. Some would say the telcos and hardware manufacturers have
|
||
rushed this out the door. PPPoE also requires an additional layer of
|
||
software just to maintain the connection. This is one more layer of code
|
||
and one more potential point of failure. Also, more system overhead is
|
||
utilized to manage the connection.
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
The impact of the disconnect problem can potentially be eased by adjusting
|
||
the PPP LCP-echo settings to extend the period before the local end of
|
||
the connection decides to terminate the session. Each end of the
|
||
connection uses LCP echoes to make sure the other end is still
|
||
<quote>there</quote>. Nothing much can be done if the remote end decides
|
||
to tear down a session (other than to do what you can to make sure you are
|
||
responding to it's LCP echoes).
|
||
|
||
</para>
|
||
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. Why PPPoX? This seems like a bad idea!
|
||
</Para>
|
||
|
||
<Para>
|
||
PPP gives several advantages to the provider: they can use their existing
|
||
infrastructure and hardware that they now use for their (larger) dialup
|
||
customer base. It is easier to control user authentication and potential
|
||
abuse situations, and easier to manage their network and related issues. In
|
||
fact, it most boils down to its just easier for them. Easier, means saves
|
||
man hours, and therefore saves costs (at least from their perspective).
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
It is not a conspiracy to conserve IP addresses, or thwart heavy users. IP
|
||
address costs are insignificant in the overall scheme of things.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. The only provider in my area does not support Linux. What can I do?
|
||
Will I have to use Windows?
|
||
</Para>
|
||
|
||
<Para>
|
||
NO! <Quote>Support</Quote> here is support as in <Quote>tech
|
||
support</Quote>. They are just saying that they will not give you tech
|
||
support when and if you have problems. This does not mean you cannot use
|
||
Linux on their network. Just that you may have to fend for yourself when
|
||
and if a problem does arise. Anything that is forbidden will be in their
|
||
Acceptable Use Policy (AUP), or Terms of Service (TOS) agreement.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
I have heard stories where a new tech or installer has misinterpreted their
|
||
own company's policy on this and told someone <Quote>you can't use Linux
|
||
here</Quote>. Same with NT server. But this is almost always a misinformed
|
||
individual.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
But -- if a provider does not support Linux, they may balk at installing
|
||
onto a Linux box. Hopefully, they will have a self-install option to get
|
||
around this annoyance. YMMV.
|
||
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. My fax software does not work with my DSL modem. Why is that?
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Faxes are normally transmitted over typical analog phone lines by dialing
|
||
the fax machine on the other end. Analog modems can handle this, but
|
||
DSL <Quote>modems</Quote> have no dialing capability. Don't throw out that
|
||
56K yet!
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. What does <Quote>FastPath</Quote> mean? Is it better? Faster? What is
|
||
interleaving? How can I get better ping times?
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Interleaving is a feature of DMT line encoding. Essentially it is a form
|
||
of error correction that is configurable at the DSLAM. The side effects are
|
||
a slower connection, especially higher latency. With FastPath (or sometimes
|
||
called non-interleaved) DMT, gateway pings can be in the 10-25 ms range. With
|
||
interleaving, this is more likely to be in the 40-75 ms range depending on
|
||
the degree of interleaving that has been enabled.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
On the positive side, a marginal line is more stable and less prone to
|
||
errors with interleaving. Many telcos have interleaving on by default since
|
||
increased stability would seem to be a good thing. But this is only
|
||
beneficial for marginal lines, and everyone else is paying a latency tax
|
||
for this. Some telcos may be amenable to turning this feature on/off. YMMV.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. How fast and powerful of a computer do I need for DSL? My ISP says I
|
||
need at least a Pentium 200. Why?
|
||
</Para>
|
||
|
||
<Para>
|
||
At the most basic level, a 386 will work fine. In most situations, you are
|
||
connected to what is essentially an ethernet based network. So
|
||
theoretically anything that can handle a very slow ethernet connection
|
||
would work. No comment on how well Netscape will run on a 386 though ;-)
|
||
But as far as just managing a raw connection, a 386 is indeed workable.
|
||
What else you can do with it, is another matter.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Where this gets a little more complicated is the modem, and the client
|
||
that the ISP may require. Any PCI or USB modem is going to require
|
||
drivers, which means more CPU and system resources. Also, PPPoE does even
|
||
more processing, so again the potential CPU load is increased. Windows
|
||
tends to be not so efficient with all this going on, hence the requirement
|
||
for mid range Pentiums by some ISPs.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
With Linux it will depend on what you are going to do. A low end Pentium
|
||
should be fine for most uses. A 386/486 should do nicely for just a
|
||
firewall/gateway box in most situations. Just remember if you are running
|
||
PPPoE, you may take a performance hit on low end hardware.
|
||
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. I just got my DSL installed, and my speed sucks, and/or my connection
|
||
constantly drops. What is the problem?
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Not enough information to say, really. There are many, many things that
|
||
can cause a poor connection. The list is too long to mention them all.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
One of DSL's weaknesses is that the signal can be fairly fragile. Many
|
||
things can degrade the signal, making for poor connections, and thus
|
||
speed. This can be caused by poor or substandard inside wiring, a wiring
|
||
problem outside (like bad splice), RFI from any number of sources, AM
|
||
radio signal interference from a nearby station, bridge taps on your
|
||
line, excessive distance from the DSLAM and so on. Not to mention possible
|
||
hardware problems with your modem, NIC, or the telco's DSLAM, etc. Not
|
||
always easy to sort out.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Your provider should be able to assist you. First, make sure the problem
|
||
isn't with your setup as they likely won't help solve a Linux problem. Then
|
||
be persistent, and don't hesitate to go over someone's head if the help is
|
||
not forthcoming. Most problems are solvable. The trick is isolating it. A
|
||
good telco tech, trained for DSL, can find all kinds of obscure wiring
|
||
problems.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. My provider's tech support staff is clueless. What can I do?
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Common complaint. Seems to be the nature of the beast. First line tech
|
||
support is an entry level position, and mostly filled by young people
|
||
with little technical or networking knowledge. Grin and bear it, or try
|
||
calling back.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. Now that I have a dedicated line, do I really need an ISP?
|
||
Can't I be my own ISP?
|
||
</Para>
|
||
|
||
<Para>
|
||
Yes, and no. Linux has everything needed to run a small ISP. But even
|
||
though the <quote>line</quote> is a dedicated connection, it is only
|
||
dedicated to the telco end-point equipment. You still need someone to sell
|
||
you bandwidth, and gateway access to the Internet. So, traditional ISPs
|
||
still have their role. You might see if there is a local provider of some
|
||
kind that will just sell you the bandwidth without all the frills (e.g.
|
||
email and news). But this probably will not save any costs.
|
||
</Para>
|
||
|
||
<para>
|
||
It is also technically possible to connect two DSL modems via
|
||
a <quote>dry</quote> copper line. In some areas, a dry line (with
|
||
no dial tone), is fairly inexpensive (but in others areas it's not).
|
||
And then you need someone on the other end who is willing to provide
|
||
the bandwidth and whatever services may be needed. Not all DSL modems
|
||
support this (some common SDSL modems apparently do). This is also going to
|
||
require dealing with the local phone company for something that is not a
|
||
consumer type service (read: might be a real PITA). There is also a
|
||
significant start up investment, that may not come with any telco
|
||
guarantees for the intended use.
|
||
|
||
</para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q: Are there ADSL Standards?
|
||
</Para>
|
||
|
||
<Para>
|
||
Sort of. The U.S. Bell Operating Companies have standardized on Discrete
|
||
Multi-Tone (DMT) (ANSI T1.413) in their current roll-out. Most others
|
||
should follow their lead in the states. There are other types of modems, most
|
||
notably Carrier-less Amplitude Phase Modulation (CAP), which of course, is
|
||
incompatible with DMT.
|
||
</Para>
|
||
|
||
<Para>
|
||
A biased comparison from an DMT-based vendor on this subject can be found at
|
||
the <ULink URL="http://www.aware.com">http://www.aware.com</ULink>. Still,
|
||
it provides the best detail on this issue I have seen so far.
|
||
</Para>
|
||
|
||
<Para>
|
||
A rather expensive copy of the ANSI standard can be ordered at: American
|
||
National Standards Institute <ULink URL="http://www.ansi.org">ANSI Home
|
||
Page</ULink>
|
||
</Para>
|
||
|
||
<Para>
|
||
Asymmetric Digital Subscriber Loop (ADSL) Metallic Interface
|
||
</Para>
|
||
|
||
<Para>
|
||
ANSI TI.413-1995
|
||
</Para>
|
||
|
||
<Para>
|
||
Note: ANSI TI.413 Issue 2 was released September 26, 1997
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q: Can I use ATM to connect to DSL?
|
||
</Para>
|
||
|
||
<Para>
|
||
Technically speaking, you can. Some DSL modems (at least the Alcatel
|
||
version) has a ATM Forum 25Mbps interface, which connects to a PCI ATM
|
||
card. But this is rarely done in practice since many Operating Systems
|
||
can't speak ATM natively, and the cost of ATM cards is more than ethernet.
|
||
See <Ulink
|
||
URL="http://linux-atm.sourceforge.net/">http://linux-atm.sourceforge.net/</Ulink>
|
||
for more details.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q: Why does DSL have all these bit rates (384/1.5/7.1M/20M/etc) options?
|
||
</Para>
|
||
|
||
<Para>
|
||
The basic problem is the 100 year old design of the copper loop. It works
|
||
great for analog phone, but it presents a real challenge for higher
|
||
performance signals like DSL. Remember that the distance of a loop is
|
||
inversely proportional to the data rate that it can carry. Rate adaptive
|
||
technologies are great for making a digital signal work in many situations,
|
||
but it can't provide a consistent bandwidth for all applications,
|
||
especially for very long (over ~15,000 ft) loops. The different bandwidths
|
||
that you see advertised reflect various marketing battles of vendors
|
||
equipment, and the telco struggle to finalize on a standard set of data
|
||
rates. The bottom line is for the telco to be able to reach as broad a
|
||
customer base as possible.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Check out the next question on the loop impairments that cause this to
|
||
happen.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q: What are all these loop impairments (bridge taps, load coils, DLCs) that
|
||
could disqualify my line from DSL? (thanks to Bruce Ediger)
|
||
</Para>
|
||
|
||
<Para>
|
||
Load coils: in-line inductances that improve voice-frequency transmission
|
||
characteristics of a telephone circuit. Essentially, a "load" steals energy
|
||
from high frequencies and gives it to lower frequencies. Typically only used
|
||
in very long (> 9,000 ft) phone lines.
|
||
</Para>
|
||
|
||
<Para>
|
||
By "bridges" I assume you mean "bridged taps". In older neighborhoods, the
|
||
phone wiring will have been used by more than one customer. Perhaps these
|
||
customers lived at different (though near-by) addresses. The unconnected
|
||
"spur" of wiring is a "bridged tab" on the currently connected circuit.
|
||
</Para>
|
||
|
||
<Para>
|
||
DLCs, Digital Loop Carriers: there's a bunch of systems for carrying more
|
||
than one voice transmission on a single pair of wires. You can shift the
|
||
frequencies up or down, or you can digitize the voice transmissions and
|
||
divide the telephone circuit by time or code or something. The more
|
||
general term is "pair gain".
|
||
</Para>
|
||
|
||
<Para>
|
||
These things cause different problems for high-frequency communications.
|
||
</Para>
|
||
|
||
<Para>
|
||
Load coils will completely mess up things by filtering high frequencies and
|
||
passing low frequencies. They probably also change the "delay envelope",
|
||
allowing some frequencies to arrive before others. One byte's tones will
|
||
interfere with the next byte's.
|
||
</Para>
|
||
|
||
<Para>
|
||
Bridged taps act as shunt capacitances if they're long in relation to the
|
||
signals wavelength, and they'll actually act as band pass filters if they're
|
||
about 1/4 wavelength of the signal. That is, they'll pass particular
|
||
frequencies freely. Particular tones of a DMT modem might get shunted back,
|
||
rather than passed along to the receiving modem, reducing bandwidth for that
|
||
telephone line.
|
||
</Para>
|
||
|
||
<Para>
|
||
Pair gain, digital or analog, limit the bandwidth available to one
|
||
transmission in order to multiplex several on one wire. High and low tones
|
||
of a DMT transmission get filtered out by the apparatus.
|
||
</Para>
|
||
|
||
<Para>
|
||
The book "Subscriber Loop Signaling and Transmission Handbook", by Whitham D.
|
||
Reeve, , IEEE Press 1992, ISBN 0-87942-274-2 covers the math of how to
|
||
calculate the effect of line length, bridged tap, etc on the transmission
|
||
characteristics of a telephone line. It's pretty expensive, however.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q. Can I run a web server with my DSL connection?
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
Sure. You are connected to a TCP/IP network, so theoretically you can run
|
||
any service that the protocols allow -- mail, ftp, ssh, irc, etc. Where
|
||
there may be problems, is with the ISP's TOS (Terms of Service). Some ISPs
|
||
are pretty open on this, while others forbid any type of server, and may
|
||
even block certain ports. You should research this, or ask the ISP before
|
||
making any plans. ISPs that are selling a consumer service are not
|
||
going to allow any high volume servers -- just personal, or low traffic
|
||
services at best. If this does not fit the bill, then you can check with
|
||
any local Business class DSL providers. This will cost more, but the
|
||
Terms of Service, and guarantees, are generally much more suited to
|
||
higher bandwidth usages.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
If you do not have a static IP, you can get around this with one of the
|
||
many Dynamic DNS services that are out there for just this purpose. See the
|
||
<Link LinkEnd="links">links</Link> section.
|
||
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Q: Do you have examples of DSL Modems?
|
||
</Para>
|
||
|
||
<Para>
|
||
Short Answer: Yes. Real Answer: The evolution of this technology is
|
||
moving too rapidly for anyone to keep up to date in a HOWTO.
|
||
Check <Ulink
|
||
URL="http://dslreports.com/information/equiprated/all">http://dslreports.com/information/equiprated/all</Ulink> for up to date information.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
However, below is a list of some of the current modem offerings as of
|
||
January 2002. All are ADSL modems with DMT encoding (a.k.a. Alcatel
|
||
compatible), unless specified otherwise. [Note: Some items retained from
|
||
original list dated June 1998.]
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Router/Modems with 10/100baseT Ethernet Interface:
|
||
</Para>
|
||
|
||
<Para>
|
||
Examples: Flowpoint 2000 DSL(CAP), 3COM Viper-DSL (CAP), Westell
|
||
ATU-R-Flexcap (CAP), Aware x200, Zyxel P641, Efficient Networks
|
||
SpeedStream 5660 and 5861, Cayman 3220H, Cisco 673 (SDSL), Cisco 675
|
||
(ADSL/CAP), Cisco 677 (ADSL/DMT), Alcatel SpeedTouch Pro
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Bridge/Modems with 10/100baseT Ethernet Interface:
|
||
</Para>
|
||
|
||
<Para>
|
||
Examples: Alcatel 1000, Alcatel SpeedTouch Home [note: Home == ethernet,
|
||
there are also USB and PCI SpeedTouch versions!], Westell ATU-R-Flexcap2
|
||
(CAP), Efficient Networks SpeedStream 5260, Efficient Networks SpeedStream
|
||
5251 (SDSL), Westell WireSpeed.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Modems with ATMF Interface:
|
||
</Para>
|
||
|
||
<Para>
|
||
Examples: Alcatel 1000, Alcatel SpeedTouch Home, Cisco 677 (DMT), Ariel
|
||
Horizon II
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Bridge/Modems with V.35 Serial Interface (T1, Serial Router)
|
||
</Para>
|
||
|
||
<Para>
|
||
Examples: Westell ATU-R
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Modems with USB Interface:
|
||
</Para>
|
||
|
||
<Para>
|
||
Efficient Networks SpeedStream 4060, Intel 3100, Alcatel SpeedTouch USB
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
PCI Modems:
|
||
</Para>
|
||
|
||
<Para>
|
||
Examples: Cisco 605, Efficient Networks SpeedStream 3060/3061, Intel 2100,
|
||
Xpeed X200 (IDSL), Xpeed X300 (SDSL), Alcatel SpeedTouch PCI
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Wireless Modems (IEEE 802.11b):
|
||
</Para>
|
||
|
||
<Para>
|
||
Examples: Alcatel SpeedTouch Wireless
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Dedicated Router (no built in modem) with 10/100baseT Ethernet Interface:
|
||
</Para>
|
||
|
||
<Para>
|
||
Examples: Netgear RT311, SMC 7004BR, Linksys BEFSR11
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
</OrderedList>
|
||
</Para>
|
||
|
||
<Para>
|
||
This is but a very small sampling and should not be construed as
|
||
endorsements of the products listed. It is just a simple illustration
|
||
of a few of the available products.
|
||
|
||
</Para>
|
||
|
||
<Warning>
|
||
<Para>
|
||
Modem manufacturers often ship modems to meet an ISP's specifications.
|
||
Features are sometimes enabled or disabled as requested by the ISP. There are
|
||
conceivably numerous, possible variations on each model. Something to
|
||
consider if buying one second-hand.
|
||
|
||
</Para>
|
||
</Warning>
|
||
|
||
</Sect1>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
||
|
||
<Sect1 id="appendix">
|
||
<Title>Appendix: Miscellaneous</Title>
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="links">
|
||
<Title>Links</Title>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Other related documentation from the Linux Documentation Project:
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/Firewall-HOWTO.html">Firewall HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/Security-HOWTO.html">Security HOWTO</Ulink>
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html">IPCHAINS HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO.html">IP Masquerade HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/mini/Home-Network-mini-HOWTO.html">Home Network mini HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/Ethernet-HOWTO.html">Ethernet HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/Networking-Overview-HOWTO.html">Networking Overview HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/Net-HOWTO/">Net HOWTO</Ulink>,
|
||
previously named the NET3-4-HOWTO, the definitive, in-depth guide to
|
||
various Linux networking topics.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/Adv-Routing-HOWTO.html">Linux
|
||
2.4 Advanced Routing HOWTO</Ulink>. All the great features of Linux's
|
||
sophisticated traffic management capabilities are explained here,
|
||
including performance enhancing ideas relevant to DSL.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/mini/DHCP/">DHCP HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/VPN-HOWTO.html">VPN HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.tldp.org/HOWTO/VPN-Masquerade-HOWTO.html">VPN Masquerading HOWTO</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
More on the 2.4 kernel packet filtering from The Netfilter Project at <Ulink
|
||
URL="http://netfilter.samba.org/">http://netfilter.samba.org/</Ulink>.
|
||
Several good HOWTOs for the new features available with 2.4 kernels
|
||
and <application>iptables</application>.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Check your security and see what ports are open at
|
||
<Ulink
|
||
URL="http://hackerwhacker.com/">http://hackerwhacker.com/</Ulink>. This
|
||
is one of the better sites for this. Some only test a relatively few
|
||
ports.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
SuSE's Linux PPPoE page is at <Ulink
|
||
Url="http://www.suse.de/~bk/PPPoE-project.html">http://www.suse.de/~bk/PPPoE-project.html</Ulink>.
|
||
Good information on most of the available Linux PPPoE implementations.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Bob Carrick's definitive PPPoE site is at <Ulink
|
||
Url="http://www.carricksolutions.com/">http://www.carricksolutions.com/</Ulink>.
|
||
His Linux PPPoE page is at <Ulink
|
||
URL="http://www.carricksolutions.com/linuxpppoe.htm">http://www.carricksolutions.com/linuxpppoe.htm</Ulink>.
|
||
It has some other DSL related information as well. All OSes are covered.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The NTS EnterNet for Linux documentation can be found at <Ulink
|
||
URL="http://support.efficient.com/KB/NTS/Docs/ENLinux13rel.html">
|
||
http://support.efficient.com/KB/NTS/Docs/ENLinux13rel.html</Ulink>. This is a
|
||
non-GPL'd PPPoE client that is distributed by some ISPs.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
<!--
|
||
Funky URL 06/21/01
|
||
|
||
<ListItem>
|
||
<Para>
|
||
A white paper from Redback on the technology and rationale behind PPPoE can
|
||
be found at
|
||
<Ulink URL="http://www.redback.com/en-US/frameset.jsp?flash=true&javascript=true&page=home/home.html">http://www.redback.com/</Ulink>.
|
||
This is how the ISPs see it. (Redback is the leading manufacturer of PPPoX
|
||
termination routers.)
|
||
|
||
</Para>
|
||
</ListItem>
|
||
-->
|
||
<ListItem>
|
||
<Para>
|
||
ATM on Linux: <Ulink URL="http://linux-atm.sourceforge.net/">
|
||
http://linux-atm.sourceforge.net/</Ulink>. Where to find the latest info on
|
||
PPPoA and raw ATM connections.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<!--
|
||
<ListItem>
|
||
<Para>
|
||
A step by step report on getting Linux going with raw ATM is here: <Ulink
|
||
URL="http://linux.com.sg/news/atm/">http://linux.com.sg/news/atm/</Ulink>.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
-->
|
||
<ListItem>
|
||
<Para>
|
||
FreeSwan, <Ulink
|
||
URL="http://www.freeswan.org">http://www.freeswan.org</Ulink>, is an
|
||
IPSec and IKE VPN implementation for Linux.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
VPN and Masquerading on Linux: <Ulink URL="http://www.tldp.org/HOWTO/VPN-Masquerade-HOWTO.html">http://www.tldp.org/HOWTO/VPN-Masquerade-HOWTO.html</Ulink>
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
PPTP-linux allows you to connect to a PPTP server with Linux. The home page is
|
||
<Ulink URL="http://cag.lcs.mit.edu/~cananian/Projects/PPTP/">http://cag.lcs.mit.edu/~cananian/Projects/PPTP/</Ulink>.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Justin Beech's
|
||
<Ulink Url="http://dslreports.com">http://dslreports.com</Ulink>, a great
|
||
site for anything and everything related to DSL. If it's not there, then
|
||
there is a link to it. (Site runs on Linux.)
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
John Navas's Cable and DSL site, <Ulink
|
||
Url="http://cable-dsl.home.att.net">http://cable-dsl.home.att.net</Ulink>,
|
||
has good general info, tweaks, troubleshooting, hardware info, etc. for
|
||
all OSes.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
TCP Performance Tuning tips: <Ulink
|
||
URL="http://www.psc.edu/networking/perf_tune.html">
|
||
http://www.psc.edu/networking/perf_tune.html</Ulink>. Tips on Linux, and
|
||
other OSes.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
A great Linux security site is <ulink
|
||
url="http://linuxsecurity.com">http://linuxsecurity.com</ulink>. Good
|
||
docs, and references for Linux. Another is <Ulink
|
||
URL="http://linux-firewall-tools.com/linux/">
|
||
http://linux-firewall-tools.com/linux/</Ulink>. Lots of info from Robert
|
||
L. Ziegler, author of <CiteTitle>Linux Firewalls</CiteTitle>. Many links
|
||
to other security related sites as well.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.seifried.org/lasg/">
|
||
http://www.seifried.org/lasg/</Ulink>, The Linux Administrator's
|
||
Security Guide by Kurt Seifried. Good tutorials on a variety of
|
||
topics -- not just firewalls, but the big picture.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The Seattle firewall is a packet filtering firewall that can be used on a
|
||
dedicated masquerading firewall machine (including LRP), a multi-function
|
||
masquerade gateway/server or on a stand-alone Linux system. The
|
||
<application>ipchains</application> project is
|
||
located at <Ulink
|
||
URL="http://seawall.sourceforge.net/">http://seawall.sourceforge.net/</Ulink>.
|
||
And for <application>iptables</application>:
|
||
<ulink url="http://shorewall.sourceforge.net/">http://shorewall.sourceforge.net/</ulink>.
|
||
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Here a few pages dedicated to using Linux with specific providers. (I
|
||
could use some submissions for more please.)
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<!--
|
||
|
||
no findo 06/21/01
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Bell Canada's Sympatico:
|
||
<Ulink URL="http://www.sympaticousers.org/faq/opsys_software.htm#unix">
|
||
http://www.sympaticousers.org/faq/opsys_software.htm#unix</Ulink>
|
||
</Para>
|
||
</ListItem>
|
||
-->
|
||
<ListItem>
|
||
<Para>
|
||
Verizon:
|
||
<Ulink URL="http://www.panix.com/~dfoster/prog/linux/pppoe.html">
|
||
http://www.panix.com/~dfoster/prog/linux/pppoe.html</Ulink>
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Southwestern Bell:
|
||
<Ulink URL="http://home.swbell.net/sdboyd56/DSL/connect1.html">
|
||
http://home.swbell.net/sdboyd56/DSL/connect1.html</Ulink>
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
BellSouth:
|
||
<Ulink
|
||
URL="http://personal.bellsouth.net/sdf/h/b/hburgiss/dsl/survival/linux.htm">
|
||
http://personal.bellsouth.net/sdf/h/b/hburgiss/dsl/survival/linux.htm</Ulink>
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
HomeChoice (UK):
|
||
<Ulink URL="http://www.maxuk.net/hc/faq.html">http://www.maxuk.net/hc/faq.html</Ulink>. (This gets my vote for the strangest ADSL service anywhere.)
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
BT-Internet (UK):
|
||
<Ulink URL="http://www.tldp.org/HOWTO/mini/BTI-PPP/index.html">http://www.tldp.org/HOWTO/mini/BTI-PPP/index.html</Ulink>
|
||
This covers both dial-up and ADSL connections.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<listitem>
|
||
<para>
|
||
German T-DSL:
|
||
<ulink url="http://www.datenhighway.com/adsl/">http://www.datenhighway.com/adsl/</Ulink>
|
||
</para>
|
||
</listitem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
France T<>l<EFBFBD>com's Netissimo:
|
||
<Ulink
|
||
URL="http://www.rhapsodyk.net/adsl/HOWTO/">http://www.rhapsodyk.net/adsl/HOWTO/</Ulink>. Good information on setting up PPTP with Linux for Alcatel modems.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Austrian Highspeed Internetconnection & Linux HOWTO:
|
||
<Ulink
|
||
URL="http://www.members.aon.at/heimo.schoen/at-highspeed-howto.html">http://www.members.aon.at/heimo.schoen/at-highspeed-howto.html</Ulink>.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<listitem>
|
||
<para>
|
||
Israel (various ISPs covered):
|
||
<ulink url="http://vipe.technion.ac.il/~mulix/adsl-howto.txt">http://vipe.technion.ac.il/~mulix/adsl-howto.txt</ulink>
|
||
</para>
|
||
</listitem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Now that you have a full-time connection, want a routable hostname for
|
||
your computer? Dynamic DNS services can do this, even if your IP changes from
|
||
time to time. Just a few of the many available services:
|
||
</Para>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://dyndns.org">http://dyndns.org</Ulink>
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://tzo.com">http://tzo.com</Ulink>
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.easydns.com">http://easydns.com</Ulink>
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://no-ip.com">http://no-ip.com</Ulink>
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink URL="http://www.microtech.co.gg/dns">http://www.microtech.co.gg/dns</Ulink>
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</ListItem>
|
||
|
||
<!--
|
||
kaput????
|
||
|
||
<ListItem>
|
||
<Para>
|
||
ADSL Forum Home Page: <ULink
|
||
URL="http://www.adsl.com">http://www.adsl.com</ULink> A comprehensive web
|
||
site created by the ADSL vendors. Fairly complete for reference information
|
||
on ADSL.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
-->
|
||
<ListItem>
|
||
<Para>
|
||
<ULink URL="http://conk.com/world/dsl/">ADSL
|
||
Deployment 'round the World</ULink> Claims to have a complete list -
|
||
looked accurate for my area - gives providers, prices, speeds, etc.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<ULink
|
||
URL="http://homepage.interaccess.com/~jkristof/xdsl-faq.txt">comp.dcom.xdsl
|
||
FAQ</ULink>. Actively maintained, and a great technical reference for DSL
|
||
technologies.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
|
||
<ListItem>
|
||
<Para>
|
||
<Ulink Url="news://comp.dcom.xdsl">comp.dcom.xdsl</Ulink>, DSL discussions,
|
||
vents, and flames on Usenet. Good place to get technical questions answered
|
||
that your ISP can't.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id="glossary">
|
||
<Title>Glossary</Title>
|
||
|
||
<Para>
|
||
A dictionary of some of the jargon used in this Document, and in the
|
||
telco and DSL industries.
|
||
</Para>
|
||
|
||
<Para>
|
||
<VariableList>
|
||
|
||
<VarListEntry>
|
||
<Term>ADSL</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Asymmetric Digital Subscriber Loop. <Quote>Asymmetric</Quote> in that the
|
||
downstream potential is greater than the upstream. ADSL is capable of
|
||
sharing on a single telco wire pair. Maximum speed is 8 Mbps, though
|
||
typically is limited by the provider to lesser speeds. The most popular
|
||
DSL at this time.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>ANT</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
ADSL Network Termination (a.k.a. the ADSL modem).
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>ARP</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Address Resolution Protocol. Converts MAC addresses to IP addresses.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>ASAM</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Alcatel's terminology for a DSLAM.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>ATM</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Asynchronous Transfer Mode - provides high-speed packet switching from 155
|
||
Mbps to (currently) 2Gbps. Used to provide backbone switching for the
|
||
Internet, and by many telcos since it can carry both voice and data. This
|
||
is a common transport protocol for many telco DSL networks.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>ATMF-25Mbps</Term>
|
||
|
||
<ListItem>
|
||
|
||
<Para>
|
||
ATM Forum Interface - 25Mbps speed, provided by a PCI NIC card. One of the
|
||
interfaces used between the modem and PC.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>brouter</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
A combination DSL modem that can be configured to act as either a bridge
|
||
or a router.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>CAP</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Carrierless Amplitude Phase. A proprietary ADSL line encoding technique,
|
||
that is (or was) in competition with <Quote>DMT</Quote>. DMT has won the
|
||
standards battle. CAP and DMT modems are not compatible with each other.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>Central Office, or CO</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Usually refers to one of two meanings: 1) The local Telco building that
|
||
houses telephone equipment, and where local loops terminate. 2) The Telco
|
||
voice switch that provides dial tone. Often referred to as just
|
||
<Quote>CO</Quote>. Typically, the CO houses one or more DSLAMs that
|
||
make DSL possible. But, increasingly, DSLAMs are being deployed remotely.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>CLEC</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Competitive Local Exchange Carrier. <Quote>Competitors</Quote> to the
|
||
ILECs. They do not own any lines, and must lease their lines from ILEC in
|
||
order to provide any service.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>CPE</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Customer Premises Equipment - The Telco term for customer owned equipment
|
||
(i.e. the stuff you are responsible for fixing). Examples are analog
|
||
modems, fax machines, and your telephone.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>DHCP</Term>
|
||
|
||
<ListItem>
|
||
|
||
<Para>
|
||
Dynamic Host Configuration Protocol - A protocol used to distribute
|
||
dynamically assigned IP addresses and other important networking
|
||
parameters. The DHCP server <Quote>leases</Quote> an IP from its pool to
|
||
clients on request. The lease is renewed at regular intervals. This is a
|
||
common protocol on bridged DSL networks, and cable modem networks.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>DMT</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Discrete Multitone Technology. This is a line encoding common among ADSL
|
||
deployments, and now is the standard. Sometimes referred to as
|
||
<Quote>Alcatel compatible</Quote>. Most telcos in the U.S. are now
|
||
standardizing on DMT. The other, less common, ADSL encoding is
|
||
<Quote>CAP</Quote>. CAP and DMT modems are incompatible with each other.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>DS0</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The basic digital circuit for Telcos - offered at 56 Kbps or 64 Kbps. Can
|
||
support one analog voice channel.
|
||
</Para>
|
||
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>DSLAM</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Digital Subscriber Loop Access Multiplexer - The Telco equipment installed
|
||
at the CO that concentrates and multiplexes the DSL lines. One end of the
|
||
copper loop connects to the DSLAM, the other to your modem. The DSLAM
|
||
is essentially what makes DSL work. Increasingly, smaller devices that
|
||
perform similar functions, are being deployed in remote locations in order
|
||
to extend the reach of DSL.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>DSL</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Digital Subscriber Loop - A term describing a family of
|
||
DSL services, including ADSL, SDSL, IDSL, RADSL, HDSL, VDSL, SHDSL, etc.
|
||
that enable high speed Internet connections over standard copper
|
||
telephone lines. The main limitation is distance.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>G.DMT</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Synonymous with <Quote>full rate</Quote> ADSL. Used to distinguish between
|
||
full rate ADSL, CAP based ADSL and G.Lite. See <Link LinkEnd="family">DSL
|
||
Family</Link> for more.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>G.Lite</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
A lesser version of ADSL that has lower maximum speeds, and requires no
|
||
splitter or filters. Not DMT compatible. See <Link LinkEnd="family">DSL
|
||
Family</Link> in this HOWTO for more. </Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>HDSL</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
High bit rate DSL. See <Link LinkEnd="family">DSL Family</Link> in
|
||
this HOWTO for more.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>ILEC</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Incumbent Local Exchange Carrier. The Regional phone company that
|
||
physically owns the lines. Examples: Bell Atlantic and Pacific Bell. FCC
|
||
regulations are forcing the ILECs to open up their networks to independent
|
||
providers. This is allowing an independents like Covad to
|
||
offer competitive services. This is a good thing for consumers IMHO.
|
||
</Para>
|
||
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>Interleaving</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Interleaving is a tunable aspect of DMT/ADSL line encoding. It essential
|
||
controls the 'interleaving' of bits in the transmission, and is used
|
||
as a form of error correction. As interleaving increases, so does
|
||
stability of marginal lines. It also increases latency.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>IP</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Internet Protocol. Also, often used to simply refer to an IP address.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>ISP</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Internet Service Provider. Even full-time connections require an ISP to
|
||
provide basic Internet services and connectivity.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>LAN</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Local Area Network. A network of computers that are segregated from the
|
||
WAN (Wide Area Network, i.e. the Internet). Often using private,
|
||
non-routable IP addressing, e.g. 192.168.1.1 or 10.0.0.1.
|
||
</Para>
|
||
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>LCP</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Link Control Protocol, one of the sub-protocols used by PPP, and
|
||
derivative protocols like PPPoE. As the name sounds, it used by
|
||
both the client and server to determine if the connection is
|
||
viable. Either end may terminate the session if LCP indicates
|
||
the connection is not responsive.
|
||
</Para>
|
||
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>Loop</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The two wire twisted pair from the telco Central Office that terminates at
|
||
a customer location. For DSL, a <Quote>clean</Quote> copper loop within
|
||
the distance limitations is required.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>MAC Address</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Media Access Control Address. Sometimes also called
|
||
<Quote>hardware</Quote> address, it is a unique identifier of network
|
||
devices and is an important aspect of some network environments.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>mini-RAM</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Remote Access Multiplexer, a mini DSLAM. Typically with very few
|
||
connections -- eight is common. Used for remote areas too far from a CO.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>MTU</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Maximum Transmission Unit, the largest packet size, measured in bytes,
|
||
that a network can transmit. Any packets larger than the MTU are divided
|
||
into smaller packets, or <quote>fragmented</quote>, before being transmitted.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>NAT</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Network Address Translation is a means of allowing computers on a LAN to
|
||
access the WAN while <Quote>masquerading</Quote> with the IP address of a
|
||
host with a suitable address and configuration. With Linux this is called
|
||
<Quote>ip-masquerading</Quote>. Often used to share one public, routable
|
||
IP address among hosts located on a LAN behind a masquerading proxy where
|
||
the local addresses are private and non-routable.
|
||
|
||
</Para>
|
||
|
||
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>NID</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Network Interface Device - The telco housing on the side of your house.
|
||
Typically where the telco's responsibility ends, and the owner's begins.
|
||
Also, sometimes called the <Quote>SNI</Quote>, <Quote>TNI</Quote> or
|
||
<Quote>ONI</Quote> or other descriptive acronyms.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>NIC</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Network Interface Card - An internal PC card that supports the
|
||
required network interface. Often an ethernet 10/100baseT or an
|
||
ATMF-25Mbps card in this context.
|
||
</Para>
|
||
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>NSP</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Network Service Provider. An ISP's upstream provider or backbone
|
||
provider.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>OC-3</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
A fiber optic line capable of 155 Mbps.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>POTS</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Plain Old Telephone Service - The service that provides a single analog
|
||
voice line (i.e. a traditional phone line).
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>PPPoA (PPPoATM)</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Point-to-Point Protocol over ATM (RFC 2364) is one of the PPP
|
||
protocols being used by some DSL providers. This is really a device
|
||
specific driver, and in many respects quite different from PPPoE. A
|
||
hardware device, i.e. a combination modem/router, is one alternative if
|
||
this is the only option available to you.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>PPPoE</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Point-to-Point Protocol over Ethernet (RFC 2516). Another PPP protocol in
|
||
use by providers. This one is more common, and there are several Linux
|
||
clients available. See the <link LinkEnd="links">Links section</link> for
|
||
more. Not to be confused with PPPoA (PPPoATM) since there are fundamental
|
||
differences.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>PPPoX</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Used to refer to PPPoE and PPPoA collectively.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>RADSL</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Rate Adaptive DSL. See <Link LinkEnd="family">DSL Family</Link> in
|
||
this HOWTO for more.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>RBOC</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Regional Bell Operating Company. The <Quote>Baby Bells</Quote>. The U.S.
|
||
phone companies that have had a state sponsored monopoly since the break
|
||
up of AT&T.
|
||
</Para>
|
||
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>RFI</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Radio Frequency Interference. DSL is susceptible to RFI if in the right
|
||
frequency range, and if close enough to the DSL signal. This can
|
||
disrupt and consequently degrade the DSL signal. Unfortunately, DSL
|
||
seems to operate in the frequency range of quite a few potential
|
||
disrupting influences.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>RWIN</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Shorthand for 'Receive Window', aka the TCP Receive Window, a tunable
|
||
aspect of TCP network stacks.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>SDSL</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Single Line DSL. Or, sometimes also <Quote>Symmetric DSL</Quote>.
|
||
See <Link LinkEnd="family">DSL Family</Link> for more.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>SNI</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Subscriber Network Interface - The Telco term for the phone wiring housing
|
||
on the side of your house. It designates the point between the Telco side
|
||
and the Inside Wire. This is also called the Demarcation Point. Sometimes
|
||
called a <Quote>NID</Quote> also.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>Splitter</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The passive device (low-pass filter) at or near the NID that
|
||
splits the DSL signal into separate voice and data channels. Filtering is
|
||
required for most DSLs that share a regular voice phone line (whether POTS
|
||
or ISDN).
|
||
</Para>
|
||
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>Splitterless</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
A DSL installation that does not require a splitter. For higher
|
||
speeds, a RJ11 filter (sometimes called microfilters) is placed on every
|
||
extension phone jack where an analog phone or other non-DSL device is
|
||
used, thus filtering the DSL signal at the jack, rather than at the
|
||
NID. For lower speeds, no filter is necessary. Without a filter or
|
||
splitter, the DSL signal tends to cause audible interference on voice
|
||
phones. G.Lite needs no splitter, nor filter, but this is the exception to
|
||
the rule.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>SOHO</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Small Office HOme
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>Sync Rate</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
The speed as negotiated by the DSL modem and the telco's DSLAM. This
|
||
represents the theoretical maximum speed of the connection before any
|
||
networking protocol overhead is taken into account. Real world throughput
|
||
is always something less than the modem's sync rate.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>T-DSL</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
German Telekom's ADSL implementation. See <Link LinkEnd="family">DSL
|
||
Family</Link> for more.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>T1</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
a.k.a DS1 - A digital dedicated line at 1.544 Mbps comprised of 24
|
||
channels, used for both voice (24 DS0s) and data.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>T3</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
a.k.a DS3 - T1's big brother, a digital dedicated line at 44.736 Mbps,
|
||
used for both voice (672 DS0s or 28 DS1s) and data.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>VPI/VCI</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
VPI is <Quote>Virtual PATH Identifier</Quote> and is part of an ATM
|
||
cell header. VCI is <Quote>Virtual Circuit Identifier</Quote>, also part of
|
||
an ATM cell header which contains circuit information. Technically
|
||
speaking, these are really remote VPI and VCI (RVPI, RVCI). They are both
|
||
important configuration aspects for modems and routers attached to ATM
|
||
networks. They must match what the provider is
|
||
using. Frequently used VPI/VCI pairs include 0/32, 0/35 and 8/35.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>VDSL</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Very high bit rate DSL. See <Link LinkEnd="family">DSL Family</Link> for
|
||
more.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
|
||
<VarListEntry>
|
||
<Term>VoD</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Video on Demand.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>VoDSL</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Voice over DSL.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>WAN</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Wide Area Network, a large publicly accessible network. For example, the
|
||
Internet.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
<VarListEntry>
|
||
<Term>xDSL</Term>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Used to refer to the entire DSL family of related technologies: ADSL,
|
||
SDSL, IDSL, etc.
|
||
</Para>
|
||
</ListItem>
|
||
</VarListEntry>
|
||
|
||
|
||
</VariableList>
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title>Other Consumer Class High Speed Services</Title>
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3 id="cable">
|
||
<Title>Cable Modem vs DSL</Title>
|
||
|
||
<Para>
|
||
The Telcos see DSL as a competitor to the Cable Company's Cable
|
||
Modem, and as such, are providing competitive pricing and configuration
|
||
offerings. Although Cable Modems are advertised as having 10-30Mbps potential
|
||
bandwidth, they use a shared transmission medium with many other users on the
|
||
same line, and therefore performance may vary, sometimes greatly, with the amount
|
||
of traffic, time of day, and number of other users on the same node. But YMMV.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
It is often heard that DSL has an advantage in that it is a private pipe to
|
||
the Internet, with dedicated bandwidth. This is mostly a myth. You do have a
|
||
private pipe to the DSLAM, but at that point, you enter the telco's ATM (or
|
||
frame relay) network, and start sharing bandwidth. You are at the mercy of
|
||
how well your DSL provider and ISP manage their networks. The consensus seems
|
||
to be that DSL providers and ISPs are mostly doing a better job of managing
|
||
bandwidth than the Cable companies. It is easier for them to add and adjust
|
||
bandwidth as needed to meet demand. You are less likely to have speed
|
||
fluctuations due to other users being on line at the same time. But, again,
|
||
this gets down to how well the specific network and bandwidth are managed.
|
||
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
DSL probably has a small security advantage too. With most Cable modem
|
||
networks, it is like being on a big LAN. You are sharing your connection (and
|
||
bandwidth) right at the point of connection. But if you are not doing
|
||
something to filter incoming connections already, you are asking for trouble
|
||
either way. And, the cable companies are addressing this now, with more
|
||
secure approaches. This should not now be a major deciding factor.
|
||
</Para>
|
||
|
||
<Para>
|
||
There also seems to be a better chance of having ISP alternatives with DSL
|
||
than Cable. At least, in the U.S. this is true. Choice is a good thing, and
|
||
so is competition. It seems most Cable outfits give you just one choice for
|
||
an ISP. If you don't like it, you are out of luck. The number of options with
|
||
DSL probably varies greatly by geographic areas. Populous areas, like
|
||
Northeast U.S., seem to have many options.
|
||
</Para>
|
||
|
||
<Para>
|
||
So which is better? The differences aren't as much with the technology, as they
|
||
are with the implementations. If you look around, you can find plenty of
|
||
horror stories on either. And plenty of happy customers too. The way
|
||
to know what may be the best for you, is to do comparative shopping based on
|
||
experiences of other users in your area. Don't base your choice on one
|
||
person's opinion. This is statistically invalid. Likewise, don't base your
|
||
choice on someone's opinion who has had a particular service for only a short
|
||
time. Again, statistically not worth much. Get as many opinions from those
|
||
that are using the <Emphasis>exact same services</Emphasis> that you are
|
||
looking at.
|
||
|
||
</Para>
|
||
|
||
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect3>
|
||
<Title>Fiber in the Loop (IFITL or FTTC, and FTTH)</Title>
|
||
|
||
<Para>
|
||
In some areas, newer neighborhoods are being built with fiber optic cable
|
||
instead of the traditional telco copper lines. While the fiber is a definite
|
||
problem for DSL services, it has it's own potential advantages. Existing
|
||
fiber is potentially capable of 100 Mbps, and it looks like this could easily
|
||
go up soon.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
So while telco fiber customers are being shut out of the DSL market
|
||
(since DSL is a copper only technology), they may have much to look forward
|
||
to. Technologies are under development, and in some cases just now being
|
||
deployed, to take advantage of fiber telco phone loops. Known as
|
||
<Quote>FTTC</Quote> (Fiber To The Curb), or <Quote>IFITL</Quote> (Integrated
|
||
Fiber In The Loop), this technology is another high speed service that telcos
|
||
can offer. The speeds are sufficient for VoD (Video on Demand) and VoDSL
|
||
(Voice over DSL), and other high bandwidth services. One nice advantage here
|
||
is, that since there is no DSL signal on the wire, the only required CPE is a
|
||
network card. In other words, no modem -- just connect a NIC to the wall jack
|
||
and off you go! This will also allow the telco to provide other digital
|
||
services such digital TV.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
FTTC is Fiber To The Curb. The last leg into the house is still copper. FTTH
|
||
(Fiber To The Home), on the other hand, is an all fiber loop with even higher
|
||
potential.
|
||
|
||
</Para>
|
||
|
||
</Sect3>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
<Sect3>
|
||
<Title>Wireless</Title>
|
||
|
||
<Para>
|
||
There is a lot of buzz about wireless technologies these days. Wireless would
|
||
certainly seem to have a place in the broadband market, especially for areas
|
||
that don't have ready access to cable or telco networks. There are still
|
||
some inherent problems with the current state of this technology that may prevent
|
||
it from becoming a major player in the near term however. Weather can still
|
||
impact the wireless signal -- heavy cloud cover or rain for instance. Also,
|
||
there is some pretty hefty latency if the uplink is via satellite. Surely
|
||
these drawbacks will improve over time. But how soon?
|
||
|
||
</Para>
|
||
|
||
|
||
</Sect3>
|
||
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2 id='modems'>
|
||
<Title>Compatible Modems</Title>
|
||
|
||
<Para>
|
||
This list is limited to those modems and delivery systems that are readily
|
||
available, and should work with any current Linux distribution without having
|
||
to go to extraordinary lengths. Alpha and Beta projects are not included. All
|
||
modems listed are POTS (analog) modems at this time.
|
||
|
||
</Para>
|
||
|
||
<Bridgehead>Ethernet Interface</Bridgehead>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
|
||
<Emphasis>All</Emphasis> external, ethernet based modems, and modem
|
||
combination devices, will work (provided they match the provider's DSL).
|
||
The only requirement is a compatible ethernet network card. This is the
|
||
preferred way to go.
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
|
||
<Bridgehead>PCI (Internal)</Bridgehead>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
|
||
Xpeed X200 IDSL <Ulink
|
||
URL="http://www.xpeed.com/Products/x200/x200_c.html">http://www.xpeed.com/Products/x200/x200_c.html</Ulink> (as of kernel 2.2.18)
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
|
||
Xpeed X300 SDSL <Ulink
|
||
URL="http://www.xpeed.com/Products/x300/x300_c.html">http://www.xpeed.com/Products/x300/x300_c.html</Ulink> (as of kernel 2.2.18)
|
||
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<listitem>
|
||
<para>
|
||
IteX PCI ADSL modem based on the Apollo chipset, also sold under various
|
||
other brand names such as Dlink and ALH110. <ulink
|
||
url="http://www.itexinc.com/">http://www.itexinc.com/</ulink>.
|
||
</para>
|
||
</listitem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
|
||
<Bridgehead>USB</Bridgehead>
|
||
|
||
<Para>
|
||
<ItemizedList>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Alcatel SpeedTouch USB (ADSL):
|
||
<Ulink
|
||
URL="http://www.speedtouchdsl.com/support.htm">http://www.speedtouchdsl.com/support.htm</Ulink>.
|
||
The driver is kernel module and requires a 2.4 kernel. See the <link
|
||
linkend="SpeedtouchUSB">Appendix</link> for driver information.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
<ListItem>
|
||
<Para>
|
||
Eci Hi Focus ADSL Modem:
|
||
<ulink url="http://eciadsl.sourceforge.net/"></ulink>. This project
|
||
seems to support several modems and chipsets, including ez-usb an2131qc,
|
||
gs7070 and gt3180.
|
||
</Para>
|
||
</ListItem>
|
||
|
||
</ItemizedList>
|
||
</Para>
|
||
|
||
|
||
</Sect2>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
<!-- ~~~~~ New Section ~~~~~ -->
|
||
|
||
<Sect2>
|
||
<Title id="linrouter">Setting up Linux as a Router</Title>
|
||
|
||
|
||
<Para>
|
||
Depending on your local setup, you should consider some other issues. These
|
||
include a firewall setup, and any associated configurations. For my setup,
|
||
shown in Figure 5 below, I use an old i486 machine configured as a
|
||
firewall/router between the DSL connection and the rest of my home network.
|
||
I use private IP addresses on my private LAN subnet, and have configured my
|
||
router to provide IP Masquerading and Firewalling between the LAN and
|
||
WAN connections.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
See the <Ulink
|
||
URL="http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO.html">IP
|
||
Masquerade HOWTO</Ulink> , and <Ulink
|
||
URL="http://www.tldp.org/HOWTO/Firewall-HOWTO.html">Firewall
|
||
HOWTO</Ulink> for more information. For 2.4 kernels see the <Ulink
|
||
URL="http://www.tldp.org/HOWTO/Adv-Routing-HOWTO.html"
|
||
>Linux 2.4 Advanced Routing HOWTO</Ulink>. My experience is that Linux is more
|
||
flexible and provides superior routing/firewalling performance. It is
|
||
much less expensive than a commercial router -- if you find an old 486 machine
|
||
that you may be using as a doorstop somewhere. There any number of
|
||
brands of <quote>DSL/Cable</quote> routers on the market as well. These
|
||
might be the way to go for pure ease of use, but lack the sophistication
|
||
of what Linux can do.
|
||
|
||
</Para>
|
||
|
||
<BridgeHead renderas=sect3>
|
||
Figure 5: A typical SOHO Network Setup
|
||
</BridgeHead>
|
||
|
||
<Para>
|
||
<Literal>
|
||
<MSGText>
|
||
<LiteralLayout>
|
||
|
||
|
||
|
||
<--Private Subnet/LAN-> Linux <-----ISP's Public Subnet----><--inet-->
|
||
192.168.1.0
|
||
|
||
|
||
X--+ --------
|
||
| | | -------- (eth0:0)---------
|
||
+--=| Hub/ | | Linux | +------=| DSL |=-DSL-> ISP's
|
||
X-----=|Switch|=-----=| System |=----+ | Modem | Gateway
|
||
+--=| | eth1 |(Router)| eth0 ---------
|
||
| -------- | -------- |
|
||
X--+ | IP_Masq |
|
||
| IP_Firewall |
|
||
| | Gateway |
|
||
| | |
|
||
| V V
|
||
V 192.168.1.1 Dynamic or
|
||
192.168.1.x LAN Gateway Static IP
|
||
LAN Addresses IP Address from ISP pool
|
||
|
||
|
||
|
||
</LiteralLayout>
|
||
</MSGText>
|
||
</Literal>
|
||
</Para>
|
||
|
||
|
||
<Para>
|
||
What I did is setup a Linux router (Redhat Linux 5.0 on a i486) with two
|
||
ethernet interfaces. One interface routes to the ISP subnet/gateway (eth0 in
|
||
above example), and the other interface (eth1 above) goes to a hub (or switch)
|
||
and then connects the LAN with private network addresses (e.g. 192.168.1.x).
|
||
Using the private network addresses behind your router/firewall allows some
|
||
additional security because it is not directly addressable from outside. You
|
||
have to explicitly masquerade your private addresses in order to connect to
|
||
the Internet from the LAN. The LAN hosts will access the Internet via the
|
||
second NIC (eth1) in the Linux router. Just set their gateway to the IP
|
||
address of the second NIC, and assign them addresses on the same network.
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
<Emphasis remap="bf">Caution</Emphasis> Make sure your kernel is complied
|
||
with IP forwarding and the IP forwarding is turned on. You can check this
|
||
with '<Command>cat /proc/sys/net/ipv4/ip_forward</Command>'. The value is
|
||
<Quote>1</Quote> for on, and <Quote>0</Quote> for off. You can change this
|
||
value by echoing the desired value into this file:
|
||
|
||
</Para>
|
||
|
||
<para>
|
||
<Screen>
|
||
|
||
# echo 1 > /proc/sys/net/ipv4/ip_forward
|
||
|
||
</Screen>
|
||
</para>
|
||
|
||
<Para>
|
||
You will also need to set up <Quote>IP Masquerading</Quote> on the Linux
|
||
router. Depending on your kernel version, this is done with
|
||
<Command>ipfwadm</Command> (2.0), <Command>ipchains</Command> (2.2), or
|
||
<Command>iptables</Command> (2.4). See the documentation for specifics on
|
||
each. AND -- do not forget to have that firewall set up too!
|
||
|
||
</Para>
|
||
|
||
<Para>
|
||
There are also several projects that are devoted specifically to using Linux
|
||
as a router, just for this type of situation. These are all-in-one solutions,
|
||
that include security and various other features. Installation and
|
||
configuration, is reportedly very easy. And these will run on very minimal
|
||
hardware -- like a floppy drive only. The best known is <Ulink
|
||
URL="http://www.linuxrouter.org">http://www.linuxrouter.org</Ulink>. You
|
||
might also want to look at <Ulink
|
||
URL="http://www.freesco.org">http://www.freesco.org</Ulink> and <Ulink
|
||
URL="http://www.coyotelinux.com">http://www.coyotelinux.com</Ulink>. There is
|
||
also <Ulink URL="http://www.clarkconnect.org/index.html">http://www.clarkconnect.org/index.html</Ulink>,
|
||
which is a similar concept but more full-featured and is designed to be
|
||
monitored and configured with a set of Windows based utilities.
|
||
|
||
</Para>
|
||
|
||
</Sect2>
|
||
|
||
</Sect1>
|
||
|
||
<!-- ~ End Section ~ -->
|
||
|
||
|
||
|
||
|
||
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
||
|
||
<!--
|
||
Begin adaptation of Chris's Jones' HOWTO for appendix of the DSL-HOWTO
|
||
|
||
General notes on adaptation for the DSL_HOWTO.
|
||
Renumbered section id's so it would fit into one appendix page.
|
||
Added preface section.
|
||
Added note on VPI/VCI in PPP options configuration area.
|
||
Corrected various typos and links (fed back to Chris mostly).
|
||
|
||
Changes are commented and identifiable by 'HB'.
|
||
|
||
we don't need this ...
|
||
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN"[]>
|
||
|
||
<article id="SpeedtouchUSB">
|
||
|
||
-->
|
||
|
||
|
||
<sect1 id="SpeedtouchUSB">
|
||
<title>Appendix: The Alcatel SpeedTouch USB ADSL Modem</title>
|
||
<comment> HB: shortened title, made it 'SpeedTouch' which is I think correct
|
||
spelling.</comment>
|
||
|
||
<!--
|
||
HB: not allowed here, sorry, we will fudge it below...
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Chris</firstname>
|
||
<surname>Jones</surname>
|
||
<affiliation>
|
||
<address>
|
||
<email>chris@black-sun.co.uk</email>
|
||
</address>
|
||
</affiliation>
|
||
</author>
|
||
</authorgroup>
|
||
<copyright>
|
||
<year>2001</year>
|
||
<holder>Chris Jones</holder>
|
||
<email>chris@black-sun.co.uk</email>
|
||
</copyright>
|
||
|
||
http://benoit.papillault.free.fr/speedtouch/user.en.php3
|
||
http://perso.wanadoo.fr/ed.gomez/docs/SpeedTouch-HOWTO-en.html
|
||
http://sourceforge.net/projects/speedtouch
|
||
Chris's SGML: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
|
||
|
||
http://www.linuxdude.co.uk/docs/Alcatel-Speedtouch-USB-mini-HOWTO.sgml
|
||
|
||
-->
|
||
|
||
<para>
|
||
The Alcatel SpeedTouch USB modem is one of a very few non-ethernet modems with
|
||
Linux drivers. This modem is quite popular in Europe (Alcatel's home turf),
|
||
and is widely used elsewhere as well. Hats off to Alcatel!
|
||
|
||
</para>
|
||
|
||
<para>
|
||
For this to work, you will essentially need three things: the Alcatel modem
|
||
firmware and management utility (supplied directly by Alcatel in
|
||
closed source, binary form), a properly configured kernel and PPP daemon,
|
||
and the Linux modem driver and related configuration. The modem driver itself
|
||
is open source. There are currently two distinct, unrelated drivers available.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
When drivers were first released, the installation process required a fair
|
||
amount of patching and rebuilding to make things work. Since then, things
|
||
have progressed, and it can now be done without any patching (see below).
|
||
How well all the pieces go together may depend on how old your Linux
|
||
installation is, the kernel and PPP versions, and possibly what patches your
|
||
vendor may have applied to their own packages. Recent Linux releases
|
||
<emphasis>probably</emphasis> have most, if not all, of this already done,
|
||
and hence you may not need to do any patching. I believe this is true of
|
||
recent SuSE, Mandrake, and Debian (and probably others as well). You still
|
||
need the Alcatel binary firmware, and a driver for the modem (if
|
||
your distro does not include this). I would suggest checking your distro's
|
||
web site, and search their archives for documents relating to this modem, and
|
||
go from there as a first step. YMMV.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
One obvious requirement is a kernel with USB support. USB and ATM support are
|
||
better in recent kernels, and I would suggest if not using a very current
|
||
Linux distribution, then at least get a recent kernel. And a quick note
|
||
on kernels and patching: if using the kernel source supplied with a Linux
|
||
distribution, it is most likely very heavily patched already. Applying
|
||
patches to these can be hit or miss.
|
||
</para>
|
||
|
||
<para>
|
||
As always with Linux, there is more than one way to skin a cat. This is
|
||
true of this modem and is resulting in some confusion since there
|
||
are various documents circulating on this modem with various approaches
|
||
taken. Some are more current than others too. Keep this in mind if you run
|
||
into conflicting recommendations. Again, your distribution is probably the
|
||
best source of documents.
|
||
</para>
|
||
|
||
<para>
|
||
There are two separate driver projects for this modem. The installation
|
||
and configuration are completely different, as is the code base. Both are
|
||
open source and GPL. One is a kernel module solution, originally developed by
|
||
Alcatel, and now maintained by Johan Verrept. His HOWTO is located at <ulink
|
||
url="http://linux-usb.sourceforge.net/SpeedTouch/howto.html">http://linux-usb.sourceforge.net/SpeedTouch/howto.html</ulink>.
|
||
I think most would agree that the installation of this driver is the more
|
||
complex of the two, and more than likely will require some patching (unless
|
||
your distro has already done this). But, it may have some slight performance
|
||
benefits since it runs mostly in kernel space.
|
||
<!--
|
||
404
|
||
There is also the
|
||
Alcatel-Speedtouch-USB-mini-HOWTO from Chris Jones, <Ulink
|
||
URL="http://www.linuxdude.co.uk/docs/Alcatel-Speedtouch-USB-mini-HOWTO/">http://www.linuxdude.co.uk/docs/Alcatel-Speedtouch-USB-mini-HOWTO/</Ulink>.
|
||
-->
|
||
This driver can potentially support both PPPoE and PPPoA connections.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
The other driver is by Benoit Papillault and friends. This one has a less
|
||
complicated installation, and can be done with <emphasis>no
|
||
patching</emphasis>. All the important parts here are done in user space. For
|
||
inexperienced users, or just plain ease of use, this may well be the most painless
|
||
way to go. The home page is <ulink
|
||
url="http://sourceforge.net/projects/speedtouch">http://sourceforge.net/projects/speedtouch</ulink>
|
||
and related docs are <ulink
|
||
url="http://speedtouch.sourceforge.net/docs.php">http://speedtouch.sourceforge.net/docs.php</ulink>.
|
||
This driver can also work with 2.2 kernels (2.2.17 or later). PPPoE is not
|
||
an option with this driver at this time. This driver also does not use
|
||
the management utility that is part of the Alcatel supplied binary package.
|
||
It extracts the modem firmware, and then does its own
|
||
<quote>management</quote>, so less dependent on proprietary code. Mandrake is
|
||
reportedly including an RPM of this driver now.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
Since this modem potentially supports both PPPoE and PPPoATM connections,
|
||
which one is better? Which ever is supported by your ISP, and then
|
||
which ever works best for you! If your ISP supports both (some do and
|
||
some don't), you might try each approach and make your own decision.
|
||
There is no absolute right or wrong on such things. There are just too
|
||
many variables. Theoretically at least, PPPoA should utilize a little
|
||
less overhead and system resources.
|
||
|
||
</para>
|
||
|
||
<para>
|
||
There are other USB modems on the market that use an Alcatel chipset,
|
||
such as the Efficient Networks 4060. Do not expect either of these drivers to
|
||
work with other modems. They won't. You should get a compatible ethernet
|
||
modem in such situations. There are other USB modems with Linux drivers also.
|
||
See <ulink
|
||
url="http://eciadsl.sourceforge.net/">http://eciadsl.sourceforge.net/</ulink>.
|
||
|
||
</para>
|
||
|
||
</sect1>
|
||
|
||
|
||
</Article>
|
||
|
||
<!-- ~~~~~~~~~~~~~~~~~~~~ finis ~~~~~~~~~~~~~~~~~~~~~~~~~ -->
|
||
|