mirror of https://github.com/tLDP/LDP
6633 lines
202 KiB
Plaintext
6633 lines
202 KiB
Plaintext
<!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
|
|
|
|
|
|
<Article id="index">
|
|
|
|
<ArtHeader>
|
|
|
|
<Title>DSL HOWTO for Linux</Title>
|
|
|
|
<PubDate>v0.99, 5 September 2000</PubDate>
|
|
|
|
<AuthorGroup>
|
|
<AUTHOR>
|
|
<FirstName>David</FirstName>
|
|
<SurName>Fannin</SurName>
|
|
<Affiliation>
|
|
<Address>
|
|
<Email>dfannin@sushisoft.com</Email>
|
|
</Address>
|
|
</Affiliation>
|
|
</AUTHOR>
|
|
|
|
<AUTHOR>
|
|
<FirstName>Updated by: Hal</FirstName>
|
|
<SurName>Burgiss</SurName>
|
|
<Affiliation>
|
|
<Address>
|
|
<Email>hal@foobox.net</Email>
|
|
</Address>
|
|
</Affiliation>
|
|
</AUTHOR>
|
|
|
|
<Editor>
|
|
<firstname>Greg</firstname>
|
|
<surname>LeBlanc</surname>
|
|
<Affiliation>
|
|
<Address>
|
|
<Email>GLeblanc@cu-portland.edu</Email>
|
|
</Address>
|
|
</Affiliation>
|
|
</Editor>
|
|
|
|
</AuthorGroup>
|
|
|
|
<!--
|
|
|
|
Broken...
|
|
|
|
<othercredit>
|
|
<firstname>Greg</firstname>
|
|
<surname>LeBlanc</surname>
|
|
<contrib>Help with layout, organization and various content suggestions.
|
|
</contrib>
|
|
</othercredit>
|
|
|
|
-->
|
|
|
|
<RevHistory>
|
|
<Revision>
|
|
<RevNumber>v0.99</RevNumber>
|
|
<Date>5 September 2000</Date>
|
|
<Authorinitials>hb</Authorinitials>
|
|
<RevRemark>
|
|
Various updates, additions and new sections.
|
|
</RevRemark>
|
|
</Revision>
|
|
|
|
<Revision>
|
|
<RevNumber>v0.92</RevNumber>
|
|
<Date>10 April 1999</Date>
|
|
<Authorinitials>df</Authorinitials>
|
|
<RevRemark>
|
|
First release.
|
|
</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>VDSL</Keyword>
|
|
<Keyword>Broadband</Keyword>
|
|
<Keyword>Internet</Keyword>
|
|
</KeywordSet>
|
|
|
|
<Abstract>
|
|
|
|
<Para>
|
|
<Comment>
|
|
|
|
Converted to DocBook 3.1 HB 08/08/00.
|
|
This started as just some additions, but turned into major rewrite.
|
|
|
|
Todo:
|
|
|
|
Nada!
|
|
|
|
</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. 'loop' 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 telephones available in
|
|
the United States. By using line-adaptive modulation, DSL is capable of
|
|
providing data speeds up to 8 Mbps.
|
|
|
|
</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 'always on' 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 and various
|
|
other factors. Also, there is no such thing as standard 'xDSL'. 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 'mainstream' 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.linuxdoc.org/HOWTO/DSL-HOWTO.html">http://www.linuxdoc.org/HOWTO/DSL-HOWTO.html</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.
|
|
|
|
</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, with the possible exception of the 'Tuning and Troubleshooting'
|
|
section. 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, and the <Link LinkEnd="isps">Linux Friendly
|
|
ISPs</Link> sections. 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 confused by 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 'sync' 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>
|
|
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>Copyright</Title>
|
|
|
|
<Para>
|
|
DSL HOWTO for Linux
|
|
</Para>
|
|
|
|
<Para>
|
|
Copyright (C)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 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>
|
|
|
|
<!--
|
|
|
|
Dropped for this version.
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Emphasis remap="bf">J Kass</Emphasis> ( Xjeremie@umich.edu) Unofficial
|
|
Ameritech ADSL FAQ
|
|
</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>
|
|
|
|
</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 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>
|
|
The naming of any particular product, brand, or company should not be construed
|
|
as an endorsement or recommendation.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect2>
|
|
<Title>New Versions</Title>
|
|
|
|
<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
|
|
'ADSL mini HOWTO' to the 'DSL HOWTO'. 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>
|
|
|
|
<Para>
|
|
The contents have additionally been re-organized, with new sections added on
|
|
security, and troubleshooting, and as well as many additions to the <link
|
|
Linkend="links">Links section</link>. Various and sundry other updates and
|
|
additions as well that are too numerous to mention.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Pre-release versions of this document can be found at <Ulink
|
|
URL="http://feenix.eyep.net/ldp/adsl/">http://feenix.eyep.net/ldp/adsl/</Ulink>.
|
|
|
|
<comment>
|
|
You should decide on 1, one, location to list as the home of this HOWTO.
|
|
|
|
Would prefer the dynamic dns address. But, worry about the longevity of these
|
|
services. Is there such a thing as 'pre-release version' as an alternate?
|
|
|
|
HB.
|
|
|
|
</comment>
|
|
|
|
</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>
|
|
|
|
<Para>
|
|
Future versions of this document may include a section devoted to FAQs and
|
|
HOWTOs for specific providers. Please send in any links you may have. Also,
|
|
I need more Linux Friendly ISPs! See the <Link LinkEnd="isps">Linux Friendly
|
|
ISPs</Link> section for what qualifies.
|
|
|
|
</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 'ifs, ands, and buts' 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>
|
|
'DSL' 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 more and more. Where
|
|
it is important to differentiate one type of DSL from another, the full
|
|
proper name will be used: e.g. RADSL. xDSL also is also commonly used to
|
|
refer to the various DSL technologies as a group, but we will be using just
|
|
'DSL' here.
|
|
|
|
<comment>You should clearly state which you will use in this document, either
|
|
xDSL or DSL. The last sentence can easily be extended... , but we will be
|
|
using DSL in this document or something similar.
|
|
|
|
10-4. HB.
|
|
|
|
</comment>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
The term 'telco' here refers to any potential DSL provider. This includes
|
|
the ILECs (Incumbent Local Exchange Carriers), a.k.a. the old guard phone
|
|
companies. And CLECs (Competitive Local Exchange Carriers), or independent
|
|
providers such as Covad and Rhythms. Both are providing DSL services over
|
|
existing copper lines.
|
|
|
|
<comment> The last two sentences there need a bit of work, but I wasn't sure
|
|
what to do with them. I'll take a look again later.
|
|
|
|
Chopped out one sentence, and minor re-wording (is that a word?). HB.
|
|
|
|
</comment>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
'CO' is the telco acronym for 'Central Office'. 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>
|
|
'Loop' is telco speak for 'phone line'. 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 'loop' as they say.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
'POTS' is the acronym for Plain Old Telephone Service. In other words,
|
|
traditional, non-digital devices like phones and answering machines.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
'DSLAM' 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 'mini-RAM' in remote
|
|
locations. We'll use 'DSLAM' here as a catchall for any device that enables
|
|
DSL service from a telco.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
'Modem' will be used to refer to the end user device that enables a DSL
|
|
connection. Your modem is connected to the telco's DSLAM in
|
|
the CO via your loop. When they are 'talking' DSL to each other, they are
|
|
in 'sync'. Without 'sync', no connection to the ISP is possible.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
'Modem' is indeed the correct terminology since there is MOdulation and
|
|
DEModulation of the signal. These modems typically have other features too.
|
|
Some ISPs and manufacturers may be marketing simply 'routers', 'bridges',
|
|
or even 'brouters' for this purpose. These are essentially DSL modems with
|
|
enhancements. A compatible 'modem' 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>
|
|
Unless stated otherwise, we will also be assuming the 'modem' has an
|
|
ethernet interface, and will connect to a standard Network Card (NIC). For
|
|
right now, arguably the only workable configuration is an ethernet
|
|
interface. And perhaps is also the only viable option based on what
|
|
delivery systems and hardware are now being offered by the overwhelming
|
|
number of providers. This could be changing soon however.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
It is worth noting that 'routers' as supplied by DSL providers are
|
|
typically modem/router combination devices. In our context, 'router' will
|
|
refer to these devices as such. There are also SOHO 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 'ANT' (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 'modem' will be just called a modem, regardless of whatever other
|
|
features it may have (i.e. router, bridge, etc.).
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
PPPoX will be used to refer to PPPoE (PPP over Ethernet) and PPPoA
|
|
(PPP over ATM) collectively. These protocols are being used by many DSL
|
|
providers now.
|
|
|
|
<comment>Is a scream of agony warranted here?
|
|
|
|
AAAAEEEEEEEYYYYYYYYYYEEEEEEEEEEEEEEEEE!!!!!!!!!!!!!!
|
|
|
|
</comment>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
The information provided in this document is based on the current state of
|
|
DSL in the U.S. I would 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 '#' will be used to denote a command that typically is run by the root
|
|
user. Otherwise, a '$' 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>
|
|
|
|
<Comment>
|
|
This does not flow well, now with DSL Overview moved. I think we need more of
|
|
an intro either here or above on 1st page. Maybe a 'Getting Ready' section.
|
|
Short section ;) HB
|
|
|
|
Wed 08/30/00 3:39:16 PM
|
|
Added a brief new section here. HB.
|
|
|
|
</Comment>
|
|
|
|
<Para>
|
|
Before actually ordering service, there are several things you may want to
|
|
explore.
|
|
|
|
</Para>
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
<Sect2>
|
|
<Title>Pre-Installation</Title>
|
|
|
|
<Para>
|
|
Beyond the obvious consideration of price, there are many reasons to
|
|
investigate which 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 is
|
|
creating diversity in the DSL marketplace. A good thing of course, but
|
|
possibly creating a little confusion too.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Not all DSL services are alike. Just because two local companies are offering
|
|
'ADSL', 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. Should be 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 'always on' service, at least theorectically? Are there supplemental
|
|
usage fees, or idle timeouts?
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Linux friendly, Linux hostile, or Linux agnostic?
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Quality of service. How is news, mail, etc.?
|
|
|
|
</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 'qualify' 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 two to three week wait for the installation.
|
|
|
|
</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>
|
|
|
|
<Comment> End newly added section Wed 08/30/00 12:58:19 PM </Comment>
|
|
|
|
</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. Many providers
|
|
offer a 'self install' 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) 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.
|
|
|
|
<comment>From what I understand (this may be completely rumor and
|
|
superstition) most of the time when a "splitter" needs to be installed
|
|
at, or near the telco's demarc, a "self install" is not an option. A
|
|
certified telco technician may need to come install the splitter.</comment>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The other possibility is for the provider to do the
|
|
installation. 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>splitter</quote>ed 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 some
|
|
kinds of problems quickly.
|
|
|
|
<comment>Most of the technicians here in Qwest land are "pole
|
|
jockeys", who don't know anything about DSL, or about computers. They
|
|
come out and install the line, but may not know more than "put this CD
|
|
in, click on install".</comment>
|
|
|
|
</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.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<ItemizedList>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Emphasis>Dedicated Line</Emphasis>. Some DSLs require a dedicated, or
|
|
'dry', wire pair, e.g. IDSL. This means a separate line for DSL and
|
|
Internet connectivity. Also, DSL services from CLECs (independent telcos
|
|
like Covad or Rhythms), will use a dedicated line since the ILEC will not
|
|
share one line with another company. (Instead the CLEC will actually lease
|
|
a loop from the ILEC.) One 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 (POTS), 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 POTS service to all other jacks. This is
|
|
considered by many to be a better type of installation than 'splitterless'.
|
|
|
|
</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.
|
|
|
|
<comment>Is demarcation point explained elsewhere?</comment>
|
|
|
|
</Para>
|
|
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Emphasis>Shared Line with Filters</Emphasis>. Again, for DSLs that
|
|
piggyback on the POTS line, the signal must be filtered or split at some
|
|
point. The other way of doing this is by placing RJ11 'microfilters' 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 'splitterless' installation.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Emphasis>Shared Line, Splitterless and Filterless</Emphasis>. 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.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<BridgeHead renderas=sect3>
|
|
Figure 1: DSL Block Diagram, POTS 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 the self-install option, then you may skip this section
|
|
and move to <Link LinkEnd="configure">Configuring Linux</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 'dry', 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>
|
|
|
|
<comment>Try blockquote or quote, coupled with attribution for
|
|
better output. See these URLs
|
|
http://www.docbook.org/tdg/html/attribution.html
|
|
http://www.docbook.org/tdg/html/blockquote.html
|
|
http://www.docbook.org/tdg/html/quote.html</comment>
|
|
|
|
<Para>
|
|
<Emphasis>
|
|
"I would not use microfilters if I lived across the street
|
|
from my CO. A splitter is the only way to go."
|
|
</Emphasis>
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
- A retired Bellsouth ADSL installer.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Perhaps a somewhat better method of wiring for the DSL modem is sometimes
|
|
called a 'homerun'. 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 POTS jack. Inside wiring defects
|
|
can be a source of headaches, especially in older homes.
|
|
</Para>
|
|
|
|
<Para> It 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. You can also use a better grade of cable such as CAT
|
|
5 or shielded twisted pair wire.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
If you are splitterless (i.e. using microfilters) now, this will entail
|
|
purchasing a splitter, and, of course, some rewiring. Microfilters also add
|
|
distance to the effective loop length -- as much as 700 ft per filter in some
|
|
cases! So if you have several of these, and your sync rate or distance is
|
|
marginal, eliminating the filters may result in a significant
|
|
improvement.
|
|
|
|
<comment>This paragraph could be clearer, I think. I've got a pretty
|
|
good idea what it means, after a few times reading it.</comment>
|
|
|
|
</Para>
|
|
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect2>
|
|
<Title>Wire the Splitter</Title>
|
|
|
|
<Para>
|
|
If you have the splitterless design 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 Subscriber Network Interface (SNI) point (also sometimes
|
|
called the NID or ONI), usually the side of your house where the phone line
|
|
is located. Put it on your side of the SNI or 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.
|
|
|
|
<comment>Which term are you going to use? SNI, NID, demarc,
|
|
ONI?</comment>
|
|
|
|
</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 POTS 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 SNI/NID box (most should have this). Plug in the modem's power cord, and
|
|
if the line is provisioned correctly, you should 'sync' in less than a
|
|
minute. This test only requires the modem. (Internal and USB modems
|
|
probably will require a driver to be loaded before syncing. This means 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>
|
|
<Title>Install and Test the Modem</Title>
|
|
|
|
<Para>
|
|
To install, connect the modem's (or modem/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 the
|
|
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 SNI/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>
|
|
|
|
</Sect2>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect2>
|
|
<Title>Install and Connect the Network Interface Card (NIC)</Title>
|
|
|
|
<Para>
|
|
If you haven't already done so, install your NIC card 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.linuxdoc.org/HOWTO/Ethernet-HOWTO.html">Ethernet HOWTO</Ulink> for
|
|
more information. Also, the <Link LinkEnd="tuning">Troubleshooting
|
|
section</Link>. This is certainly something you could conceivably do ahead of
|
|
time if you already have the NIC.
|
|
|
|
<comment>Which troubleshooting section? This is obvious from the
|
|
markup, but not from non-linked formats, like plain text.</comment>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Be sure the RJ45 cable between the NIC and the modem is now connected. You
|
|
can hot plug this cable.
|
|
|
|
<comment>You should define hot plug</comment>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
We can do a few quick tests now to see if the NIC is functioning properly:
|
|
|
|
</Para>
|
|
|
|
<comment>this section could use a little work, since you don't
|
|
explain how you expect their network to be configured. The
|
|
commands are nice, but without some explanation of what each
|
|
command does, nearly worthless.</comment>
|
|
|
|
<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>
|
|
If 'eth0' comes up without errors, and you can <Command>ping</Command>
|
|
it without errors, and <Command>ifconfig</Command> shows no errors, we should
|
|
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>
|
|
|
|
|
|
</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, and the NIC is
|
|
functioning, then you're ready to configure Linux and verify your connection
|
|
to your ISP. Although I will refer to a Linux System, you can 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 PC aspect here.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<comment>perhaps another place to use the warning tag?</comment>
|
|
|
|
<Emphasis remap="bf"> Caution!</Emphasis> <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>
|
|
|
|
|
|
<!-- ~~~~~ 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 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 other users.
|
|
|
|
</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: 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. Our job will
|
|
be finding the right client, and doing what we have to, to get it up and
|
|
running.
|
|
|
|
</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. So you will need either one or the other, 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. PPPoA is yet another alternative. 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>
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
<Sect3>
|
|
<Title>Bridged/DHCP</Title>
|
|
|
|
<Para>
|
|
In the good old days of a year or two ago, 'Bridged' connections were the
|
|
norm. 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). 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 providers.
|
|
</Para>
|
|
|
|
<Para>
|
|
There are several PPPoE clients for Linux (<Link LinkEnd="pppoe">see
|
|
below</Link>). At this moment, PPPoA support is in beta, but should be
|
|
available very soon. 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>
|
|
From the ISPs perspective, PPP is much easier to maintain and troubleshoot.
|
|
From the end user's perspective, it is more work to set up, 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, especially the RBOCs (Baby Bells),
|
|
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 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. There is an ATM project for Linux, that is being incorporated
|
|
into the 2.4 kernel. (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 'there' yet.
|
|
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect2>
|
|
<Title>Configuring the WAN Interface</Title>
|
|
|
|
<Para>
|
|
The most common configuration is a DSL modem in 'bridging' 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
|
|
'eth0' since it is an ethernet interface.
|
|
</Para>
|
|
|
|
<Para>
|
|
With PPPoX, once the connection comes up, there will be a 'ppp0', 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 'eth0' 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 'static' 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. 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.
|
|
|
|
<comment>Again, a note about static IP's being less secure should be
|
|
mentioned.</comment>
|
|
|
|
</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.linuxdoc.org/HOWTO/Net-HOWTO">Net HOWTO</Ulink> for more
|
|
information and specifics. A quick command line example with bogus IPs:
|
|
|
|
</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>
|
|
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 'lease' from the ISP's server as well as
|
|
other related information: gateway address, DNS servers, and network mask.
|
|
The lease will be 'renewed' 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 'eth0'. 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 '-h'
|
|
command line option for this purpose. See the client's man page, or your
|
|
distribution's documentation, for specifics.
|
|
|
|
</Para>
|
|
|
|
<comment>Warning/note perhaps?</comment>
|
|
|
|
<Para>
|
|
<Emphasis>Caution!</Emphasis> 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>
|
|
|
|
</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. Some distros 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, <Ulink
|
|
URL="http://www.roaringpenguin.com/pppoe/">http://www.roaringpenguin.com/pppoe/</Ulink>,
|
|
by David F. Skoll. This client is under very active development.
|
|
It is reportedly very easy to set up, and get started with. As of
|
|
right now, this is probably by far and away the most popular Linux
|
|
PPPoE client.
|
|
|
|
</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. This
|
|
package requires some kernel patching and other configuration related
|
|
issues.
|
|
|
|
</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>
|
|
<comment>a purely WHAT solution?</comment>
|
|
|
|
<Para>
|
|
A purely solution can be found at <Ulink
|
|
URL="http://www.math.uwaterloo.ca/~mostrows/">http://www.math.uwaterloo.ca/~mostrows/</Ulink>
|
|
solution by Michal Ostrowski. This requires a 2.3/2.4 kernel. As of this
|
|
writing, it is still 'experimental. Once the 2.4 kernel goes mainstream,
|
|
this will be a more viable option.
|
|
|
|
</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. (NTS
|
|
was just recently purchased by Efficient Networks.)
|
|
|
|
</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 'eth0' is connected to the modem:
|
|
|
|
</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>
|
|
<Emphasis>Warning</Emphasis>! For PPPoX, the correct setting for the ppp0
|
|
interface MTU is 1492. If the MTU is set too high, it may cause 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.
|
|
|
|
<!--
|
|
|
|
8. Configure LAN Hosts
|
|
|
|
If you have a LAN behind the firewall, you have to lower the TCP
|
|
maximum segment size from the normal 1460 to 1452 (or better, 1412.)
|
|
You have two options: Either set the MTU of all the interfaces on
|
|
other hosts on the LAN to 1452, or use the "-m 1412" option to pppoe.
|
|
The "-m" option for pppoe is far simpler and makes it easier to add
|
|
hosts to the LAN, but consumes some extra CPU time.
|
|
|
|
If you want to manually configure the LAN hosts, here's how:
|
|
|
|
In Linux, use: "ifconfig eth0 mtu 1452". For best results, put this
|
|
in an /etc/rc.d/rc.local script.
|
|
|
|
For Windows, machines, see http://lan.cns.ksu.edu/OS/WIN95/slip95.htm.
|
|
Set the MaxMTU to 1452.
|
|
|
|
==
|
|
E) pppoe dies with the log message "Message too long"
|
|
|
|
You set the MTU of the Ethernet interface connected to the ADSL modem
|
|
to less than 1500. Don't do that.
|
|
-->
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Actually, for PPPoE the real setting should be at least 8 bytes less 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 misconfigured at a lower setting, and this can
|
|
cause problems, especially with web pages loading. 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 (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 client
|
|
necessary to manage the connection as with PPPoE. Authentication is still the
|
|
same: user id and password to connect, but the mechanics are different since
|
|
no ethernet encapsulation takes place.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
As of this moment, there is not really a viable, working implementation of
|
|
PPPoA for Linux. 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
|
|
[possibly out of production], as well as other ATM cards. The ATM on Linux
|
|
homepage is here: <Ulink URL="http://lrcwww.epfl.ch/linux-atm/">
|
|
http://lrcwww.epfl.ch/linux-atm/</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. At
|
|
the very least, some rather serious hoop jumping is in order.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
If PPPoA is your ISP's only option, you should probably consider one of the
|
|
router/modems that can handle PPPoA, and let the hardware handle everything.
|
|
|
|
</Para>
|
|
|
|
<comment>clearly a good place to use the "note" tag</comment>
|
|
|
|
<Para>
|
|
<Emphasis>Note:</Emphasis> There is apparently a PPPoA beta program underway
|
|
based on the Efficient Networks SpeedStream 3060/3061 (PCI, DMT). Efficient is
|
|
working with kernel developers, and reportedly this program is in late beta
|
|
at this time. The initial release will be binary only drivers, but open
|
|
source may follow. This is a big improvement!
|
|
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect3 id="router">
|
|
<Title>Modem/Router Configuration</Title>
|
|
|
|
<Para>
|
|
Some ISPs are providing 'routers' 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 NIC
|
|
should be all that is required to make this work.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
A 'router' 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 'hop' 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.
|
|
|
|
<comment>which provider?</comment>
|
|
|
|
</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 'MAC cloning'
|
|
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>
|
|
|
|
|
|
<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>
|
|
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>
|
|
|
|
<Para>
|
|
<Emphasis>Warning!</Emphasis> Some manufacturers may be marketing these as
|
|
having 'firewall' capabilities. In some cases, this amounts to nothing more
|
|
than basic NAT (Network Address Translation or masquerading). Not a full,
|
|
true firewall by any means. Be sure to read the fine print before buying and
|
|
make sure you know how much real firewalling is included.
|
|
|
|
</Para>
|
|
|
|
|
|
</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-40 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>
|
|
|
|
<comment>I think the range of ping times given above is too small,
|
|
as I get about a 75ms ping to my ISPs gateway.</comment>
|
|
|
|
</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 quick push 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 Quickstart</Title>
|
|
|
|
<comment>I think in other places you've used full time instead of
|
|
full-time. Those should probably be consistent.</comment>
|
|
|
|
<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 'default' 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>
|
|
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 these HOWTOs for details:
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ItemizedList>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink
|
|
URL="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html">Firewall
|
|
HOWTO</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
|
|
<Ulink
|
|
URL="http://www.linuxdoc.org/HOWTO/Security-HOWTO.html">Security
|
|
HOWTO</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
|
|
<Ulink
|
|
URL="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html">IPCHAINS
|
|
HOWTO</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.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>
|
|
|
|
|
|
|
|
<ListItem>
|
|
|
|
<comment>This needs some more links and/or explanation of how to
|
|
go about these things.</comment>
|
|
|
|
<Para>
|
|
Take passwords seriously. Use shadow passwords. Do not allow remote root
|
|
logins.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
|
|
<comment>I would say that ssh and OpenSSH are applications
|
|
rather than commands, but that's just me.</comment>
|
|
|
|
<Para>
|
|
Use <Command>ssh</Command>, or <Command>OpenSSH</Command>, instead of
|
|
<Command>telnet</Command>.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect2>
|
|
<Title>Which Ports?</Title>
|
|
|
|
<Para>
|
|
There are plenty of references around on how to setup firewalls with
|
|
<Command>ipfwadm</Command> or <Command>ipchains</Command>, but a little
|
|
harder to find just which ports <Emphasis>really need</Emphasis> to be open.
|
|
If you are not sure of the answer to this question, then the answer is 'as
|
|
few as possible'! Basic rule #1, your computer cannot be broken into through
|
|
a port that is not open. A port can't be open if nothing is listening on
|
|
that port. In other words, if no service or daemon is running that uses that
|
|
port, the port is closed and inaccessible.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
There are 65,536 ports available for use on Linux and these fall into
|
|
several categories. The ones we are most concerned about are the
|
|
'privileged' ports, which are those below port 1024. This is where
|
|
most public services run, like SMTP on port 25, HTTP on port 80,
|
|
named on port 53, etc. These services are where most vulnerabilities
|
|
are on Linux. These are the ports that servers accept outside
|
|
connections on. If you are running the <Command>telnetd</Command>
|
|
daemon, it will 'listen' for connections on port 23. (Actually if
|
|
spawned by <Command>inetd</Command>, it may be
|
|
<Command>inetd</Command> that is listening.)
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
But, if you want to use a telnet <Emphasis>client</Emphasis> to
|
|
connect to someone else's telnet server, you do not need to be running the
|
|
<Command>telnetd</Command> daemon on your own system. You just need to start
|
|
the client program named '<Command>telnet</Command>' (different animal). Same
|
|
is true for ftp and other services. These daemons only need to be run for
|
|
excepting connections to your system from an outside source.
|
|
</Para>
|
|
|
|
<comment>I don't think that the telnet command needs to be set off
|
|
both by quotes, and by the command markup.</comment>
|
|
|
|
<Para>
|
|
Unless you have a good reason for doing so, and know what you are doing, then
|
|
you should not be running these <comment>which?</comment> services. In fact, you could probably survive
|
|
quite nicely with all TCP and UDP ports below 1024 closed down, or at least
|
|
not visible to outside connections (i.e. blocked via a firewall). A couple of
|
|
exceptions:
|
|
</Para>
|
|
|
|
<Para>
|
|
It is relatively safe, and probably reasonably safe, to run
|
|
<Command>identd</Command> (port 113). Many mail and irc servers aren't happy
|
|
without <Command>identd</Command> there. This is the one good exception to
|
|
the 'nothing below 1024' rule of thumb. Newer versions are relatively
|
|
secure, but be sure that you have the newest version available.
|
|
</Para>
|
|
|
|
<comment>both relatively safe and reasonably safe?</comment>
|
|
|
|
<Para>
|
|
Mail is a little more complicated. The only reason to have a publicly
|
|
accessible SMTP (port 25) server is if you are hosting your own mail server
|
|
and receiving direct incoming mail connections. If you are retrieving mail
|
|
via POP3 from your ISP, this port does not need to be open to the world. Such
|
|
mail does not come in via port 25. It comes in through a higher, randomly
|
|
assigned port.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
But -- it may still be convenient to have a mail daemon like sendmail, qmail,
|
|
or postfix running to handle local mail delivery. In fact, this is a common
|
|
default set up. You can get around this by firewalling off SMTP (port 25)
|
|
from the outside world, or using another method to sort and deliver local
|
|
mail. One way is to use procmail in conjunction with fetchmail:
|
|
'<Literal>fetchmail -m /usr/bin/procmail -d hal</Literal>' will do this
|
|
without having to run sendmail or other mail daemons in daemon mode. These
|
|
programs are still capable of sending mail in non-daemon mode.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
It is probably safe to run a web server if you want to. Most vulnerabilities
|
|
there are through CGI. Just keep the web server package updated.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
OK, enough exceptions. Shut down, or firewall off, <Emphasis>everything
|
|
else</Emphasis> below port 1024.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Those ports above 1023 are known as 'non-privileged' ports. These are mostly
|
|
used for return connections that you have initiated to someone else's server.
|
|
For instance, if you telnet to someone else, you connect to their port 23.
|
|
The return data comes back to you on a randomly assigned port above 1023.
|
|
These are mostly safe, and should as a rule be left alone. The only
|
|
exceptions are where there are indeed services running on these ports. X
|
|
Windows runs on ports 6000-6009 for instance. If you are running a font
|
|
server, it may be on port 7100. Any servers running on these non-privileged
|
|
ports, should be firewalled too.
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect2>
|
|
<Title>inetd</Title>
|
|
|
|
<Para>
|
|
Let's take a quick look at <Command>inetd</Command>, since it starts many
|
|
services. <Command>Inetd</Command> is a 'super' daemon. It is called this
|
|
because it controls the starting of other daemons. Telnet, ftp, rsh, identd
|
|
and pop3 are some of the server daemons commonly controlled by
|
|
<Command>inetd</Command>. You may not see <Command>telnetd</Command> running
|
|
when you use <Command>ps</Command> or <Command>netstat</Command> unless
|
|
<Command>inetd</Command> is configured to start <Command>telnetd</Command>,
|
|
<Emphasis>and</Emphasis> someone is actually connected to
|
|
<Command>telnetd</Command> at the time. So it may not be so obvious which of
|
|
these servers can be accessed from outside. These sub-services are controlled
|
|
by the configuration file <Filename>/etc/inetd.conf</FileName>. Open this
|
|
with your favorite text editor, and put a '#' character in front of any
|
|
service you don't want running. A brief excerpt:
|
|
|
|
</Para>
|
|
|
|
|
|
<Para>
|
|
<Literal>
|
|
<MSGText>
|
|
<LiteralLayout>
|
|
|
|
#ftp stream tcp nowait root /usr/sbin/tcpd in.wuftpd -l -a -L -i -o
|
|
#telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
|
|
#
|
|
# Shell, login, exec, comsat and talk are BSD protocols.
|
|
#
|
|
#shell stream tcp nowait root /usr/sbin/tcpd in.rshd
|
|
#login stream tcp nowait root /usr/sbin/tcpd in.rlogind
|
|
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
|
|
#comsat dgram udp wait root /usr/sbin/tcpd in.comsat
|
|
#talk dgram udp wait root /usr/sbin/tcpd in.talkd
|
|
#ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
|
|
|
|
</LiteralLayout>
|
|
</MSGText>
|
|
</Literal>
|
|
</Para>
|
|
|
|
<comment>It might be nice to show what an enabled service looks
|
|
like here.</comment>
|
|
|
|
<Para>
|
|
This will prevent them from running. <Command>identd</Command> may be started
|
|
from this file, and would be safe to leave uncommented. Then re-initialize:
|
|
<Command>inetd</Command>:
|
|
|
|
</Para>
|
|
|
|
<Screen>
|
|
|
|
# kill -HUP `pidof inetd`
|
|
|
|
</Screen
|
|
|
|
<Para>
|
|
Note those are 'backquotes'. For more on fine tuning inetd access via
|
|
'tcpwrappers', see the hosts_access and tcpd man pages.
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
|
|
|
<Sect1 id="tuning">
|
|
<Title>Performance Tuning and Troubleshooting</Title>
|
|
|
|
<comment>Since there are no performance tweaks, why even mention
|
|
it?</comment>
|
|
|
|
<Para>
|
|
There really are no tweaks, or performance tuning tricks that are likely to
|
|
increase your performance to any significant degree -- all other things being
|
|
equal. Windows 9x users often get a big boost by increasing their TCP Receive
|
|
Window. But this is because it is too small to start with. This is not the
|
|
case with Linux.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The only exception is if you have to routinely deal with a high latency
|
|
connection. Such as maybe your provider has a satellite uplink that is
|
|
consistently adding unusual latency (250ms or greater?). Then maybe a larger
|
|
window will help. For the overwhelming majority of us, this is not necessary.
|
|
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>
|
|
If your connection is not performing up to what you think it should be, then
|
|
possibly there is a problem somewhere. This is more worth looking into than
|
|
any magical 'tweak'.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
A very rough guideline on what you might reasonably expect as a maximum, based
|
|
on distance from CO:
|
|
|
|
</Para>
|
|
|
|
<LiteralLayout>
|
|
0-12 Kft - 1500 Kbps or more
|
|
12-16 Kft - 1500 Kbps -> 1000 Kbps
|
|
16-18 Kft - 1200 Kbps -> 512 Kbps
|
|
18-?? Kft - 512 Kbps -> 128 Kbps or less :(
|
|
</LiteralLayout>
|
|
|
|
<Para>
|
|
Remember too that you will loose 10-20% of throughput to networking overhead.
|
|
So a 1500 Kbps connection, is only going to realize about 1200-1300 Kbps or
|
|
so of real world throughput. No tweaking is going to change this. And
|
|
remember that 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. Most of these are out of your control.
|
|
|
|
</Para>
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~ 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>
|
|
|
|
<comment>This reads like a list. Perhaps try using sub-lists,
|
|
or complete sentences. (sorry, I abhor sentence fragments)</comment>
|
|
|
|
<Para>
|
|
If self-installing, the DSL jack may be wired wrong. The splitter may be
|
|
wired wrong. The modem may be wired differently than standard telco POTS
|
|
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.
|
|
</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. A remote possibility that the
|
|
DSLAM is down. They should know this as well.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
|
|
<comment>You must think I'm harping by now... Which term are
|
|
you going to use for demarc?</comment>
|
|
|
|
<Para>
|
|
Disconnect modem power cord and disconnect from wall jack. Plug it
|
|
into the test jack inside the SNI/NID (outside phone box), and run
|
|
extension cord if necessary for power cord. 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. 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 is wired incorrectly inside, or a short in a connection
|
|
somewhere, or there is severe electrical interference on the DSL line.
|
|
Check splitter and wall jack. If a splitterless installation, look for 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>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.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<ItemizedList>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Turn off PnP in BIOS. This may be labeled as 'non-Microsoft'
|
|
OS. Other times, it will be labeled as <quote>PNP-OS
|
|
Installed</quote>. A sometimes symptom here is that the NIC is
|
|
assigned IRQ 0.
|
|
|
|
</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.
|
|
|
|
</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>
|
|
The card is bad, or the drivers just aren't up to snuff. Try another card.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect3>
|
|
<Title>IP Connection Problems</Title>
|
|
|
|
<Para>
|
|
Read this section if the modem is syncing, the NIC is recognized and seems to
|
|
be working properly, client software is installed and running without error,
|
|
but connection to the ISP fails. Verify the modem is indeed syncing by the
|
|
LED(s). This may be evidenced by <Command>ifconfig</Command> not showing an
|
|
active eth0 interface (and ppp0 for PPPoX), or <quote><Command>ping</Command>ing</quote>
|
|
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?
|
|
|
|
</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 certainly be able to see 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>
|
|
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>.
|
|
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
If running a firewall (e.g. with ipchains), temporarily take it down.
|
|
Possibly this is misconfigured, and not allowing packets through.
|
|
|
|
</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.
|
|
|
|
</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 'sync/no surf' 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 'shelves' with 'cards'. 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 lost, or dropped. This can
|
|
drasticly reduce throughput. It is tempting to think of lost packets
|
|
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 wall jack. This will force a resync. Unfortunately, the only
|
|
way to power down a PCI modem, is to reboot. This should fix a 'sync/no
|
|
surf' 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/SNI 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, and/or intermittent sync loss and/or low
|
|
sync rates. 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 'frying
|
|
bacon' 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, 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 'homerun' 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. 'Network' 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 'latency' and 'packet loss'. 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
|
|
'responsiveness' or 'lag time'. 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 'lost', 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 'hops' 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>
|
|
|
|
<Screen>
|
|
|
|
$ ping -c 12 -n www.linuxdoc.org
|
|
PING www.linuxdoc.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.linuxdoc.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>
|
|
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>
|
|
|
|
|
|
<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>
|
|
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>
|
|
|
|
<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>
|
|
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 'normal' gateway ping (for me!):
|
|
|
|
</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>
|
|
And a problem with the same gateway on a different day:
|
|
|
|
</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>
|
|
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.
|
|
|
|
</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>
|
|
|
|
<comment>This might be better as a different kind of list.
|
|
Perhaps a variablelist or possibly even a segmentedlist.</comment>
|
|
|
|
<Para>
|
|
<Emphasis>Some Web pages won't load.</Emphasis> For PPPoX users, the
|
|
MTU value could be too high. The correct ppp0 device setting should be
|
|
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 lower -- 1452 or maybe
|
|
even 1412.
|
|
|
|
</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.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Emphasis>PPPoX disconnects</Emphasis>. Unfortunately, there is a tendency
|
|
for PPPoX to drop connections. PPP is apparently 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. You might try a different client, or check your current
|
|
client's documentation on this issue. If worse comes to worse, set up a cron
|
|
job to watch the connection, and re-establish if necessary.
|
|
|
|
</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. This may also happen with DHCP if the server does not
|
|
respond for long periods of time. (Possibly a bug in the client? I have
|
|
seen this with early versions of <Command>pump</Command> from Redhat. HB.)
|
|
|
|
</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 should be set likewise.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect2 id="throughput">
|
|
<Title>Measuring Throughput</Title>
|
|
|
|
<Para>
|
|
No such thing as too fast, right? 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 overhead. Just how much is 'lost' here depends on your provider's
|
|
network architecture and other considerations.
|
|
</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. Minus the ~15% is 1275
|
|
Kbps. My sync rate is known to be good and my distance to the CO is about
|
|
9000 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>
|
|
|
|
<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>
|
|
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, 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 or 'POTS' (Plain Old Telephone
|
|
Service). 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 POTS, and one for Internet connectivity. When all is working
|
|
normally, there should be no interference between the two 'lines'. This gives
|
|
DSL a potentially broad consumer base, and helps minimize costs for
|
|
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, 'always on' 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 fast pipe :-).
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Phone companies, and other independent telecommunications providers (CLECs),
|
|
are now deploying DSL as fast as they can to stay ahead of the Cable
|
|
companies -- the main consumer and SOHO competition for DSL providers. This
|
|
mad rush to get 'a piece of the pie', 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 'best effort' 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.
|
|
|
|
<comment> DSL generally does not offer service contracts for home users, while
|
|
DSL for business offers similar SLAs (Service Level Agreements) to that offered
|
|
when getting a T1 line.
|
|
|
|
See next para. HB.
|
|
|
|
</comment>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
DSL providers generally do not have service contracts for home users,
|
|
while business class DSL services typically do include similar SLA (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>
|
|
|
|
<comment>I tend to think that these would flow better as complete
|
|
sentences, rather than sentence fragments. The rendering does not lend
|
|
itself to the partial sentences leading into these paragraphs. Check out
|
|
both <markup>segmententedlist</markup> and <markup>variablelist</markup> as
|
|
alternatives to the current markup.</comment>
|
|
|
|
<Para>
|
|
Asymmetric Digital Subscriber Loop. This DSL type currently supports
|
|
downstream rates up to 8 Mbps, and upstream of 1024 Kbps, hence the
|
|
'asymmetric'. The most widely deployed form of DSL at this time, 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 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 'full rate' ADSL in order to differentiate it from
|
|
G.Lite DSL. There are two common line encodings for ADSL: DMT and CAP. DMT
|
|
(a.k.a. Alcatel compatible) has won the standards battle and is now the
|
|
more common of the two. 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.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<BridgeHead renderas=sect3>G.Lite</BridgeHead>
|
|
|
|
<Para>
|
|
Sometimes called 'DSL Lite', 'Universal DSL' or 'splitterless ADSL', is a
|
|
slower version of ADSL that require no splitters <Emphasis>or </Emphasis>
|
|
filters. The isolation of voice and data signals is handled at the CO.
|
|
Currently G.Lite supports speeds up to 1.5 Mbps/512 Kbps, and is expected
|
|
to eventually become the dominant consumer DSL service. As of this writing,
|
|
it is not as wide spread as 'full rate' ADSL however.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<BridgeHead renderas=sect3>SDSL</BridgeHead>
|
|
|
|
<Para>
|
|
Single-pair Digital Subscriber Loop, or also sometimes referred to
|
|
as 'Symmetric Digital Subscriber Loop' 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. It is worth noting that
|
|
some providers may be marketing a 'SDSL' service that is really ADSL pinched
|
|
so that upstream/downstream are the same. Wasn't all this confusing enough
|
|
already?
|
|
|
|
<comment> Why is Symmetric DSL wrong? It IS always symmetric...
|
|
|
|
Actually the term here 'Single Line (or pair)' was coined to explicitly to
|
|
differentiate it from HDSL, which required multiple pairs for significant
|
|
speeds. This was (is) is big drawback to HDSL. It is coincidence that it is
|
|
also symmetric. So a technicality really, and who really cares anyway ;)
|
|
|
|
Also, noted that 'some T1' uses 2B1Q, but cannot find the reference where I
|
|
originally got that from.
|
|
|
|
HB.
|
|
|
|
</comment>
|
|
|
|
</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 'always on' 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.
|
|
|
|
<comment> What in the HECK is 2B1Q? I've got a total of 8 fiber T1s, and 4
|
|
copper t1s coming into our office, and I've NEVER heard of that. Out basic
|
|
DSS trunks for voice are using AMI, while our Internet circuts are using B8ZS.
|
|
Where can I get more information on this 1B2Q thing?
|
|
|
|
See above. HB.
|
|
|
|
</comment>
|
|
</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. 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.
|
|
|
|
</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, 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>
|
|
Standard not finalized yet. Supposedly includes many enhancements.
|
|
</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. 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.
|
|
|
|
</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>
|
|
|
|
<comment>Our tools seem to suck on this "ASCII art". I'm not sure
|
|
if trying a graphic would be worth-while.</comment>
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect3>
|
|
<Title>Sync</Title>
|
|
|
|
<Para>
|
|
A good, working connection to the DSLAM is referred to as 'syncing'. 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 'cap', 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 'cap', but your speed will
|
|
be limited to whatever 'cap' 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>
|
|
|
|
<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>
|
|
First notice the 'Current Attainable Rate' in the 'ATU-C' 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 'TX Rate'. This is the theoretical limit of this connection. This
|
|
limit, or 'cap', can be enforced at the DSLAM, as is the case the here, or
|
|
further upstream. Had the first row 'TX Rate' 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 modem 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 'syncs' 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>! You will need an external, ethernet interfaced
|
|
modem (or modem/router combo) that connects via a standard NIC, since
|
|
virtually all 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The only potential compatibility issue is the Network Card (NIC). (And really
|
|
any compatible ethernet NIC should do just fine -- 100 Mbps is not
|
|
necessary.) You are probably better off anyway, since PCI and USB modems are
|
|
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. Diamond makes an internal PCI modem
|
|
which has binary-only drivers, but it is not in widespread
|
|
use. <Ulink url="http://www.efficient.com">Efficient Networks</Ulink>
|
|
is beta testing Linux drivers for their SpeedStream 3060 and 3061 PCI
|
|
modems, and is expected to release them <quote>any day</quote>. This
|
|
will require a 2.4.x kernel, and a patch for the necessary ATM
|
|
support. Efficient is working with kernel developers to make their
|
|
products Linux compatible. The initial version will have binary
|
|
drivers only, but open sourced drivers are a future possibility. It
|
|
is also possible to make a direct ATM connection using a modem plus
|
|
an ATM 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 'bridge'
|
|
and modem device. The bridge is a simple device, typically with little
|
|
configuration. Network traffic passes blindly across the 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 may also be offering 'routers'. 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 'brouters'. In this case, the modem can
|
|
be configured for either bridging or routing -- 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 Netgear, Linksys, 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? Well, fortunately for us the external,
|
|
ethernet interfaced modems are the most reliable anyway. Fewer IRQ hassles,
|
|
no buggy drivers, etc. So a blessing in disguise really. Are any of these
|
|
better than others? Probably not. None are faster anyway. Certainly some may
|
|
have more features, like the combo modem/routers. But realistically, 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.
|
|
|
|
<comment>I don't see the question "Are some modems better than
|
|
others?" being answered here. The second sentence isn't very readable
|
|
to me, possibly just because of punctuation.</comment>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<comment>How about using the "warning" tag here instead?
|
|
http://www.docbook.org/tdg/html/warning.html</comment>
|
|
|
|
<Emphasis remap="bold">Warning!</Emphasis> 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, DMT a.k.a. Alcatel compatible), and
|
|
several options for IP encapsulation. And different DSLs (SDSL, IDSL, etc)
|
|
will require their own modem too. 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 comes
|
|
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>
|
|
|
|
|
|
</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 will take over at what we 'see' 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 ATM side of the DSLAM
|
|
via a high-speed data connection, usually ATM over a T3 (45 Mbps) or OC-3
|
|
(155 Mbps). The important thing here is that an ISP must 'subscribe' 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) 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 'reselling' 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.
|
|
|
|
<comment>I have a note on my printed copy to "pick and acronym", but
|
|
I'm not sure which term I wanted you to pick an acronym for. It would
|
|
be good to make sure that you're consistent throughout the whole
|
|
document with your use of acronyms, just as good authoring policy.
|
|
</comment>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
CLECs (independent telcos) are now installing their own DSLAMs. 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 'partnered' with one or more ISPs. If
|
|
you are lucky here, you will have many choices of plans and pricing
|
|
structures.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Typically, your service agreement is with the ISP, and not the DSL
|
|
provider. This makes the actual DSL provider a 'behind the scenes'
|
|
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>
|
|
|
|
<Para>
|
|
See the Appendix for a list of <Link LinkEnd="isps">Linux Friendly ISPs</Link>.
|
|
|
|
</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 in your 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
|
|
'pre-qualifying', and is Step One in getting service.
|
|
|
|
</Para>
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect3>
|
|
<Title>Ordering</Title>
|
|
|
|
<Para>
|
|
<comment>Which kind of provider? ISP? Telco/DSL provider? Both?
|
|
Please replace "provider" with something more specific, or give a
|
|
clearer idea of what it means.</comment>
|
|
|
|
Before ordering service, check to see what providers there are in your area.
|
|
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 'qualifying' 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 'disqualify' 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</comment> Whether you hit a snag like
|
|
this, is pretty much hit or miss. Fiber anywhere in the loop is also
|
|
a disqualifier. The provider may take steps to 'clean' 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 'qualified', 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 'clean' 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. 'Routers'
|
|
(i.e. combo modem/routers) should be OK too since these seem to be all
|
|
external, ethernet. Anything else is a no-go! (This situation may be
|
|
changing soon.)
|
|
|
|
</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 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.
|
|
|
|
<comment>It might be worth noting that dynamic IP is slighly more
|
|
secure than a static IP. With a static IP, the crackers will always
|
|
know right where to look to find you.
|
|
</comment>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Emphasis>Encapsulation</Emphasis>. Is the connection 'Bridged' or 'PPP'.
|
|
PPPoX has the reputation of being not as stable a connection, and not
|
|
'always on'. 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 'always on' (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. ('Supported' means like 'tech support'.) If they
|
|
say 'we don't care', 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.
|
|
|
|
</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 'Yes, of course!'. 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 a more of a challenge than it needs to be. Not having a compatible
|
|
modem option available is one common gotcha. 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>
|
|
As of this moment, you probably can't, because they are not available. You
|
|
need 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>
|
|
If an incompatible modem puts you in a bind, hopefully you will take the
|
|
time to politely harass the manufacturer :-).
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
This situation will likely change soon however. <Ulink
|
|
URL="http://www.efficient.com">Efficient Networks</Ulink> is in late Beta
|
|
stages with their SpeedStream 3060/3061 PCI drivers. Others will likely
|
|
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
|
|
will install, at some point, remote devices for customers who are now too
|
|
far away.
|
|
|
|
</Para>
|
|
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Q. What are the speed tweaks for Linux?
|
|
</Para>
|
|
|
|
<Para>
|
|
There aren't any really. Linux is pre-tweaked, unlike some versions of
|
|
Windows that really need some registry hacks to get optimum performance.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Now if you are convinced you are not getting the performance you should
|
|
based on your distance and line conditions, then maybe there is a problem
|
|
somewhere. See the <Link LinkEnd="tuning">Troubleshooting</Link> section for
|
|
more. What you need is a fix, more than a tweak.
|
|
|
|
</Para>
|
|
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
|
|
<comment>Perhaps make it clear that 640K is an example, or just
|
|
use some "variable" instead of 640K.</comment>
|
|
|
|
<Para>
|
|
Q. My service is limited to 640K. 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. 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 networking overhead. This
|
|
is just a fact of life for everybody. Just how much is lost here depends on
|
|
a number of factors, and may vary from provider to provider. 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 'up to' such and
|
|
such. Check your service agreement and see if there are any guarantees. If
|
|
there are, they probably are well below the advertised maximum speed.
|
|
|
|
</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 site.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Q. Why does PPPoX have such a bad rap?
|
|
</Para>
|
|
|
|
<Para>
|
|
The tendency to abruptly disconnect is one of the biggest gripes. PPP is
|
|
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 'always on' 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 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>
|
|
|
|
</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>
|
|
|
|
<comment>In case you're not aware, it's illegal to sell or lease
|
|
IP addresses. Most ISPs get around this via a "service charge"
|
|
associated with having multiple IPs. </comment>
|
|
|
|
</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! 'Support' here is support as in 'tech support'. 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 'you can't use Linux here'.
|
|
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 modems have no dialing capability. Don't throw out that 56K yet!
|
|
|
|
</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.
|
|
</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 well Netscape will run on a 386 though ;-) But as
|
|
far as managing the 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. 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 lousy 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, excessive distance from the DSLAM. 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: Are there ADSL Standards?
|
|
</Para>
|
|
|
|
<Para>
|
|
A: Sort of. The U.S. Bell Operating Companies have standardized on Discrete
|
|
Multi-Tone (DMT) (ANSI T1.413) in their current rollout. 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>
|
|
A: 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. See <Ulink
|
|
URL="http://lrcwww.epfl.ch/linux-atm/">http://lrcwww.epfl.ch/linux-atm/</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>
|
|
A: 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 a digital
|
|
signal. 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 18,000 ft)
|
|
loops. The different bandwidths that you see advertised reflect various
|
|
marketing wars 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>
|
|
|
|
<comment>A consistent definition format is needed here. I'd use
|
|
a variablelist, but it doesn't really matter as long as you use
|
|
the same format for all of the definitions.</comment>
|
|
|
|
<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>
|
|
|
|
<comment>This next paragraph is Greek to me. Well, maybe just
|
|
Russian. :-) In any case, it's certainly geek...</comment>
|
|
|
|
<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: Do you have examples of DSL Modems?
|
|
</Para>
|
|
|
|
<Para>
|
|
A: Short Answer: Yes. Real Answer: The evolution of this technology is
|
|
moving too rapidly for anyone to keep up to date in a HOWTO. A good source
|
|
of ADSL Modems is the ADSL Forum Home Page at <ULink
|
|
URL="http://www.adsl.com">http://www.adsl.com</ULink>. Go to the Vendors
|
|
pages to see what's happening. Also, check <Ulink
|
|
URL="http://dslreports.com/information/equiprated/all">http://dslreports.com/information/equiprated/all</Ulink>.
|
|
|
|
</Para>
|
|
|
|
<comment>Is this really as of June 1998?</comment>
|
|
|
|
<Para>
|
|
However, I will provide a list of some of the current technology as of June
|
|
1998. All are ADSL 'modems' with 'DMT' encoding (a.k.a. Alcatel
|
|
compatible), unless specified otherwise. [Updated Aug 2000.]
|
|
|
|
</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, 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: there are also USB
|
|
and PCI versions of this one!], 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 627 (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
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
PCI Modems:
|
|
</Para>
|
|
|
|
<Para>
|
|
Examples: Cisco 605, Efficient Networks SpeedStream 3060/3061, Intel 2100
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Dedicated Router (no built in modem) with 10/100baseT Ethernet Interface:
|
|
</Para>
|
|
|
|
<Para>
|
|
Examples: Netgear RT311
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
</ListItem>
|
|
|
|
</OrderedList>
|
|
</Para>
|
|
|
|
<Para>
|
|
This is but a very small sampling. It should not be construed as
|
|
endorsements of the products lists. It is just a simple illustration
|
|
of some of the available products.
|
|
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
|
|
|
|
<Sect1 id="appendix">
|
|
<Title>Appendix: Miscellaneous</Title>
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect2 id="links">
|
|
<Title>Links</Title>
|
|
|
|
<comment>At some point, it might be nice to break these links up
|
|
into categories.</comment>
|
|
|
|
<Para>
|
|
<ItemizedList>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Other related documentation from the Linux Documentation Project:
|
|
</Para>
|
|
|
|
<Para>
|
|
<ItemizedList>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html">Firewall HOWTO</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.org/HOWTO/Security-HOWTO.html">Security HOWTO</Ulink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html">IPCHAINS HOWTO</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html">IP Masquerade HOWTO</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.org/HOWTO/mini/Home-Network-mini-HOWTO.html">Home Network mini HOWTO</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO.html">Ethernet HOWTO</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html">Networking Overview HOWTO</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
|
|
<comment>Hmm, I'd like to see either summaries with the
|
|
HOWTOs, or no summaries with the HOWTOs. They should be
|
|
easily enough stolen from the HOWTO-INDEX, if you want to
|
|
include them.</comment>
|
|
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.org/HOWTO/Net-HOWTO/">Net HOWTO</Ulink>,
|
|
previously named the NET3-4-HOWTO, the definitive guide to various Linux
|
|
networking topics.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html">Linux
|
|
2.4 Advanced Routing HOWTO</Ulink>. All the new, improved features are
|
|
explained here.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://www.linuxdoc.org/HOWTO/mini/DHCP/">DHCP HOWTO</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
|
|
<ListItem>
|
|
|
|
<comment>FIXME: Greg: go through this nested list, and re-format
|
|
it for easier reading. Hal, don't worry about this
|
|
comment.</comment>
|
|
|
|
<Para>
|
|
More on the 2.4 kernel packet filtering from The Netfilter Project at <Ulink
|
|
URL="http://netfilter.kernelnotes.org/">http://netfilter.kernelnotes.org/</Ulink>.
|
|
Several good HOWTOs for the new features in 2.4.
|
|
|
|
</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 FAQ can be found at <Ulink
|
|
URL="http://www.nts.com/support/FaqEnterNetLinux.html">
|
|
http://www.nts.com/support/FaqEnterNetLinux.html</Ulink>. This is a
|
|
non-GPL'd PPPoE client that is distributed by some ISPs.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
A white paper from Redback on the technology and rationale behind PPPoE can
|
|
be found at
|
|
<Ulink
|
|
URL="http://www.redback.com/frameset.asp?page=whitepp/wp_pppoe_comparison.html">http://www.redback.com/frameset.asp?page=whitepp/wp_pppoe_comparison.html</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://lrcwww.epfl.ch/linux-atm/">
|
|
http://lrcwww.epfl.ch/linux-atm/</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>
|
|
An open source project based on the Alcatel SpeedTouch Home USB modem can be
|
|
found at <Ulink
|
|
URL="http://kapu.name.daemon.xs4all.be:8080/Projects/">http://kapu.name.daemon.xs4all.be:8080/Projects/</Ulink>. This is a beta project that requires 2.4 kernel
|
|
and patches.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
FreeSwan, <Ulink
|
|
URL="http://www.freeswan.org">http://www.freeswan.org</Ulink>, is an
|
|
IPSec & IKE VPN implementation for Linux.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
VPN and Masquerading on Linux: <Ulink URL="http://www.wolfenet.com/~jhardin/ip_masq_vpn.html">http://www.wolfenet.com/~jhardin/ip_masq_vpn.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://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.securityportal.com/lasg/">
|
|
http://www.securityportal.com/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 an ipchains based firewall that can be used on a
|
|
dedicated masquerading firewall machine (including LRP), a multi-function
|
|
masquerade gateway/server or on a standalone Linux system. The project is
|
|
located at <Ulink
|
|
URL="http://seawall.sourceforge.net/">http://seawall.sourceforge.net/</Ulink>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
My ipchains script is at <Ulink
|
|
URL="http://personal.bellsouth.net/~hburgiss/linux/ipchains.html">
|
|
http://personal.bellsouth.net/~hburgiss/linux/ipchains.html</Ulink>.
|
|
This has IP Masquerading already set up, is reasonably well commented, and
|
|
may make a quick starting point for your own script with only
|
|
minor adjustments to suit your situation.
|
|
|
|
</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. A few of the available services:
|
|
</Para>
|
|
|
|
<Para>
|
|
<ItemizedList>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://dyndns.org">http://dyndns.org</Ulink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://tzo.org">http://tzo.org</Ulink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink URL="http://eyep.net">http://eyep.net</Ulink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
</ListItem>
|
|
|
|
<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>
|
|
<!--
|
|
|
|
Way out of date. 1996.
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="http://www.alumni.caltech.edu/~dank/isdn/adsl.html">Dan Kegels
|
|
ADSL Page</ULink> A good general reference on DSL - includes vendor,
|
|
service provider, and other links. This page was getting a little long in
|
|
the tooth as of 2Q98. Dan also maintains a super page on ISDN.
|
|
</Para>
|
|
</ListItem>
|
|
-->
|
|
|
|
<!--
|
|
|
|
Leaving this out for now, until more can be included. HB Sun 09/03/00 02:19:22
|
|
PM
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink
|
|
URL="http://www.pacbell.com/products/business/fastrak/adsl/index.html">PacBell's
|
|
ADSL Page</ULink> Pacific Bell is the local Telco and my provider of ADSL
|
|
service (DF).
|
|
</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>
|
|
|
|
|
|
<comment>There are a bunch of tags designed for marking up
|
|
glossaries. Take a look at
|
|
http://www.docbook.org/tdg/html/glossary.html and some of the
|
|
pages following it.</comment>
|
|
|
|
<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>
|
|
|
|
<comment>Is ADSL still the most popular? How are you
|
|
determining popularity?</comment>
|
|
|
|
<Para>
|
|
Asymmetric Digital Subscriber Loop. 'Asymmetric' in that the downstream
|
|
potential is greater than the upstream. ADSL is capable of sharing on
|
|
a single POTS 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.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
<VarListEntry>
|
|
<Term>ATMF-25Mbps</Term>
|
|
|
|
<ListItem>
|
|
|
|
<comment>ANT? Pick a term, si vous plait. I realize this one
|
|
is taken from the miniHOWTO :-)</comment>
|
|
|
|
<Para>
|
|
ATM Forum Interface - 25Mbps speed, provided by a PCI NIC card.. One of the
|
|
interfaces used between the ANT 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 'DMT'. 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 'CO'.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
<VarListEntry>
|
|
<Term>CLEC</Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Competitive Local Exchange Carrier. 'Competitors' 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 CSU/DSU,
|
|
modems, fax machines, and your phone.
|
|
</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 'leases' 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.
|
|
</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 'Alcatel
|
|
compatible'. Most telcos in the U.S. are now standardizing on DMT.
|
|
The other, less common, ADSL encoding is 'CAP'. 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 64kbps. Can
|
|
support one analog voice channel.
|
|
</Para>
|
|
|
|
<comment>Don't you love Telco? A digitized voice quality
|
|
signal only needs 8Kbps.</comment>
|
|
|
|
</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.
|
|
</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.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
<VarListEntry>
|
|
<Term>G.DMT</Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Synonymous with 'full rate' ADSL. Used to distinguish between full rate
|
|
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 U.S. West. FCC
|
|
regulations are forcing the ILECs to open up their networks to independent
|
|
providers. This is allowing the independents like Covad and Rhythms to
|
|
offer competitive services. This is a good thing for consumers IMHO.
|
|
</Para>
|
|
|
|
<comment><quote>U.S. West is not Qwest</quote>, just ask
|
|
them.</comment>
|
|
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
|
|
<VarListEntry>
|
|
<Term><acronym>ISDN</acronym></Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Innovations Subscribers Don't Need; I Still Don't kNow; or maybe Integrated
|
|
Services Digital Network, a digital phone service that uses a single
|
|
copper pair to run 2B (64k) + 1D(16k) channels that can be used for
|
|
switched voice or data.
|
|
</Para>
|
|
|
|
<comment>Sometimes ISDN is sold for "consumer" use as dual 56K
|
|
channels, plus a 16K data channel.</comment>
|
|
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
<VarListEntry>
|
|
<Term>IP</Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Internet Protocol. Often used to simply refer to an IP address.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
|
|
<VarListEntry>
|
|
<Term>ISP</Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Internet Service Provider.
|
|
</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). Typically using private,
|
|
non-routable IP addressing, e.g. 192.168.1.1 or 10.0.0.1.
|
|
</Para>
|
|
|
|
<comment>Actually, I have my doubts about "typically" using
|
|
private IPs, although more and more are going that way. It
|
|
should be less of an issue if IPv6 ever gets going.</comment>
|
|
|
|
</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 'clean' copper loop within the distance
|
|
limitations is required.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
<VarListEntry>
|
|
<Term>MAC Address</Term>
|
|
|
|
<ListItem>
|
|
|
|
<comment>Not 100% sure on this one, but I think it's supposed
|
|
to be MAC address.</comment>
|
|
|
|
<Para>
|
|
Media Access Control Address. Sometimes also called 'hardware' 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 before being transmitted.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
|
|
|
|
<VarListEntry>
|
|
<Term>NAT</Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Network Address Translation. A means of allowing computers on a LAN with
|
|
private, non-routable address to access the WAN while 'masquerading' with
|
|
the IP address of a host with a suitable address and configuration. With
|
|
Linux this is called 'ip-masquerading'.
|
|
</Para>
|
|
|
|
<comment>NAT does not require that 1 side is non-routable IP
|
|
addresses. It's quite possible to do NAT with any IPs that you
|
|
like. Also, there is such a thing as "static NAT", which is a
|
|
direct mapping of one IP address to another.</comment>
|
|
|
|
</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, called the 'SNI'.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
<VarListEntry>
|
|
<Term>NIC</Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Network Interface Card - A PC card (PCI/ISA) that supports the required
|
|
network interface. Usually an Ethernet 10baseT or an ATMF-25Mbps Card..
|
|
</Para>
|
|
|
|
<comment>There are many other buses that could be used for a
|
|
network card, including SBUS, EISA, MCA (microchannel), EIO,
|
|
and bazzillions more. I don't think that anybody is still
|
|
making pure 10baseT cards anymore, and if so, I can't imagine
|
|
why. 10/100 cards are so cheap that they should be
|
|
ubiquitous.</comment>
|
|
|
|
</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</Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Point-to-Point Protocol over ATM (RFC 2364). One of the PPP protocols
|
|
being used by some ISPs. Linux support is beta at this particular
|
|
moment. May be changing very soon. 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.
|
|
|
|
</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 'Baby Bells'. The U.S. phone
|
|
companies that have had a state sponsored monopoly since the break up of
|
|
AT&T.
|
|
</Para>
|
|
|
|
<comment>FIXME: ask Greg Ferguson if the numeric entities or
|
|
the named ones work better</comment>
|
|
|
|
</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.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
<VarListEntry>
|
|
<Term>SDSL</Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Single Line DSL. Also, sometimes erroniously 'Symmetric DSL'. 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 'NID' also.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
<VarListEntry>
|
|
<Term>Splitter</Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
The passive device (low-bandpass filter) at or near the SNI/SNI that
|
|
splits the DSL signal into separate voice and data channels. Typically
|
|
installed near the demarcation point.
|
|
</Para>
|
|
|
|
<comment>Which term is being used for the demarcation
|
|
point?</comment>
|
|
|
|
</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
|
|
SNI/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 Office
|
|
</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>VCI/VPI</Term>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
VCI is 'Virtual Circuit Identifier' and is part of an ATM cell header. VPI
|
|
is 'Virtual Path Identifier', also part of an ATM cell header which
|
|
contains circuit information. These are both important configuration
|
|
aspects for modems and routers. They must match what the provider is
|
|
using. Frequently used VPI/VCI pairs are 0/32 or 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. 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 varies, perhaps greatly, with the amount
|
|
of traffic, time of day, and number of other users on the same node.
|
|
|
|
</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 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 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
There also seems to be a better chance of having ISP alternatives with DSL
|
|
than Cable. 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>Integrated Fiber in the Loop (IFITL or FTTC)</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, 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 'FTTC' (Fiber To The Curb), or 'IFITL' (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!
|
|
|
|
</Para>
|
|
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect2 id='modems'>
|
|
<Title>Compatible Modems</Title>
|
|
|
|
<Para>
|
|
This is an easy one right now ;-):
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<ItemizedList>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Emphasis>All</Emphasis> external, ethernet based modems, and modem
|
|
combination devices, should work with no problems. The only requirement is a
|
|
compatible network card. (Technically speaking, there are a few, rare and
|
|
very minor exceptions.)
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
<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.
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<!-- ~ End Section ~ -->
|
|
|
|
|
|
|
|
|
|
<!-- ~~~~~ New Section ~~~~~ -->
|
|
|
|
<Sect2 id="isps">
|
|
<Title>Linux Friendly DSL ISPs</Title>
|
|
|
|
<Para>
|
|
By 'friendly' we mean ISPs that don't put up any unnecessary impediments just
|
|
because you aren't running that other guy's OS. And yes, there is some of
|
|
that going around. If your choices are limited, and you are forced to deal
|
|
with one of these, then having a Windows box available temporarily is one work
|
|
around. Another, may be to sweet talk the installer into letting you finish
|
|
the installation (NIC, etc). Of course, self installation, if available,
|
|
should be completely 'Linux compatible'.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
So to make this list, the ISP/provider must make available some type of
|
|
workable modem (ethernet interface at this point in time), nor should
|
|
penalize you, or make things difficult, just because you are running an
|
|
alternate OS. Installing directly onto Linux should be an available option,
|
|
and should not cause you any undue hardship. Technical support for Linux is a
|
|
nice bonus, but not necessary to make the list. Please do not take these as
|
|
recommendations, do your own homework.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
To add a name to this list, mail <ULink
|
|
URL="mailto:hal@foobox.net?Subject=LinuxFriendlyISP">Linux
|
|
Friendly</ULink>. Please included ISP's official name, URL (if not obvious),
|
|
location and coverage area, modem type, server policy, and any other
|
|
pertinent details.
|
|
|
|
</Para>
|
|
|
|
<BridgeHead renderas=sect3>
|
|
National ISPs (U.S.):
|
|
</BridgeHead>
|
|
|
|
<Para>
|
|
<ItemizedList>
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://www.speakeasy.net">Speakeasy.net</Ulink>: Static IP and
|
|
no PPPoX, servers explicitly allowed. Highly rated. National. Multiple IPs
|
|
available.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://www.phoenixdsl.com">PhoenixDSL</Ulink>: Static IP and
|
|
no PPPoX. National. Linux is supported. Servers apparently OK for
|
|
non-commercial use. Tiered pricing plan.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://www.telocity.com">Telocity</Ulink>: Static IP, no
|
|
PPPoX, liberal server policy. Reports of abysmal tech support. (Unenforced
|
|
monthly bandwidth usage limit ???). National. They have their own
|
|
proprietary modem, but it is ethernet based.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://www.geekcast.com/dsl_request.html">Penguinista
|
|
DSL</Ulink>, DSL with a twist. Not just Linux friendly, but Linux lovers.
|
|
Sponsored by the Benevolent Penguin Society. National. Static IP
|
|
available. "Theoretical" timeouts and session limits though. Encapsulation
|
|
protocol (PPP?) unknown. ???
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
|
|
|
|
<BridgeHead renderas=sect3>
|
|
Regional and Local ISPs (U.S.):
|
|
</BridgeHead>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://qx.net/dsl/index.html">qx.net</Ulink>, Lexington, Ky.,
|
|
and areas of Central and Eastern KY. Officially supports Linux. Static IP.
|
|
Personal servers allowed. Tiered pricing plans. Highly rated.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://www.ctsi.net">Commonwealth Technical Services</Ulink>,
|
|
Richmond, Va. Officially, and happily support Linux. Static IP. Personal
|
|
servers allowed. No bandwidth restrictions. This ISP runs on Linux!
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://www.execdsl.com">ExecDSL</Ulink>, Baltimore, MD,
|
|
Washington, DC and surrounding areas. Static IP. Servers are OK. Various
|
|
plans and DSL providers. Secondary MX and DNS available (nice touch!).
|
|
(Apparently no official Linux support.)
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://netexpress.net">Netexpress.net</Ulink>, Moline, Ill.
|
|
Tiered pricing. Static IP available. Apparently, no official support. Runs
|
|
on Linux!
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://www.iglou.com">iglou.com</Ulink>, Lexington, Ky., and
|
|
soon in Louisville, Ky, Cincinnati, OH, and maybe Nashville, TN. Static IP
|
|
available. Personal servers allowed. Tiered pricing plans with various
|
|
options.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink
|
|
Url="http://bluegrass.net/internetaccess.html">Bluegrass.net</Ulink>,
|
|
Lexington, Ky., and surrounding areas. Static IP. Personal servers allowed.
|
|
Tiered pricing plans.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://www.drizzle.com/dsl">Drizzle.com</Ulink>, greater
|
|
Seattle, WA area. Static IP, servers OK.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink
|
|
Url="http://www.netsync.net/services/dedicated.html">Netsync.net</Ulink>,
|
|
Chautauqua County, NY (Fredonia, Jamestown, and surrounding areas). Static
|
|
IP available, PPPoA, servers are OK. Linux is supported!
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<Ulink Url="http://www.aracnet.com/adsl/">Aracnet</Ulink>, greater Seattle,
|
|
WA., and Portland and Salem, OR. areas. Static IP. Linux friendly! Tiered
|
|
pricing. Shell access account is included (RH)!
|
|
|
|
</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 connection.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
See the <Ulink
|
|
URL="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html">IP
|
|
Masquerade HOWTO</Ulink> , and <Ulink
|
|
URL="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html">Firewall
|
|
HOWTO</Ulink> for more information. For 2.4 kernels see the <Ulink
|
|
URL="http://www.linuxdoc.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.
|
|
|
|
</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
|
|
192.168.1.1 Dynamic or
|
|
LAN Gateway Static IP
|
|
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 address 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 '1'
|
|
for on, and '0' for off. You can change this value by echoing the desired
|
|
value into this file:
|
|
</Para>
|
|
|
|
<Screen>
|
|
|
|
# echo 1 > /proc/sys/net/ipv4/ip_forward
|
|
|
|
</Screen>
|
|
|
|
<Para>
|
|
You will also need to set up 'IP Masquerading' 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>.
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
|
|
</Article>
|
|
|
|
<!-- ~~~~~~~~~~~~~~~~~~~~ finis ~~~~~~~~~~~~~~~~~~~~~~~~~ -->
|
|
|