LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/docbook/DSL-HOWTO.sgml

5524 lines
167 KiB
Plaintext
Raw Normal View History

This is the first version I got from Hal. I'll be putting updates in based on this version. This is a pretty complete re-write of the ADSL mini HOWTO that the LDP has had for quite a while now.
2000-08-23 20:32:49 +00:00
<!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<Article id="index">
<ArtHeader>
<Title>DSL HOWTO for Linux</Title>
<PubDate>v0.99, 16 August 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>
</AuthorGroup>
<RevHistory>
<Revision>
<RevNumber>v0.99</RevNumber>
<Date>16 August 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>
<Literal>
<MSGText>
<LiteralLayout>
<Comment>
Converted to DocBook 3.1 HB 08/08/00.
This started as just some additions, but turned into major rewrite.
Notes to me:
Tue 08/15/00 07:20:53 PM
USB link added.
Compatible modem entry added.
</Comment>
** Draft Comments *************************************************
Sun 08/13/00 22:38:26 PM
Mostly done now. Spellchecked and linkchecked. Maybe a few lose
ends to tie up. Maybe minor additions to link and FAQ sections. Security
section is now 'done'.
Tue 08/08/00 08:12:40 PM
Started on troubleshooting section.
Mon 08/07/00 08:55:40 PM
More odds and ends. Security is roughed out. Layout changes. Verified all
links. Will probably remove the ipfwadm stuff at some point.
Sun 08/06/00 02:09:38 PM
More PPPoX stuff. Started on security section.
Sun 08/06/00 01:55:47 AM
More stuff here and there. Some layout changes. More system config.
Fri 08/04/00 06:26:36 PM
Add some FAQs, and started on PPP, and system config stuff.
*** Thu 08/03/00 06:59:50 PM EDT *********************
Note to interested readers:
This is a work in progress. It is a fairly major rewrite of the original ADSL
mini HOWTO. Likely will be re-christened the DSL HOWTO (maybe mini, maybe not).
The first 3 or so sections are near ready IMO. I hope to have rough draft ready
by this Sunday or Monday. Would love feedback on any or all aspects of this
doc. I expect to submit to LDP by Aug 12 or so. Not spell checked yet. Check
back daily :)
<ULink URL="mailto:hal@foobox.net">Hal Burgiss</ULink>
****************************************************************
</LiteralLayout>
</MSGText>
</Literal>
</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 Line, is a high-speed Internet access technology
that uses a common copper telephone line (a.k.a. 'loop' in telco parlance).
DSL provides a direct, dedicated connection to an ISP via the existing telco
network. Designed to run on up to 80% of the telephones available in the
United States, and utilizing line-adaptive modulation, DSL provides 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/availability issues of T1. Since DSL is a dedicated, often
'always on' service, it avoids the delays and use charges inherent with ISDN
service.
</Para>
<Para>
This HOWTO starts with an overview of the technology surrounding DSL.
And includes discussions on qualifying, installing, configuring,
troubleshooting and securing a DSL connection. Also included is an Appendix
with a <Link LinkEnd="faq">FAQ</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/mini/DSL.htm">http://www.linuxdoc.org/HOWTO/mini/DSL.html</Ulink>
</Para>
<!-- ~~~~~ New Section ~~~~~ -->
<Sect2>
<Title>Copyright</Title>
<Para>
DSL HOWTO for Linux Systems
</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>
<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.
(hb)
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<!-- ~ End Section ~ -->
<!-- ~~~~~ New Section ~~~~~ -->
<sect2 id="disclaimer">
<title>Disclaimer</title>
<para>
No liability for the contents of this documents will be accepted. Use the
concepts, examples and other content at your own risk. As this is a new
edition of this document, there may be errors and inaccuracies. Although this
is unlikely, the author(s) do not take any responsibility for incorrect or
misleading information.
</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>
Naming of any particular product, brand, or company should not be seen
as endorsements.
</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, and RADSL. Thus the renaming from 'ADSL
mini HOWTO' to the 'DSL mini HOWTO'. Many other changes as well like PPPoE/A
encapsulation becoming more and more common as many ISPs are jumping on
this bandwagon too.
</Para>
<Para>
Other sections have been added on security, and troubleshooting, and many
additions to the <link Linkend="links">Links section</link>. Various
and sundry other updates and additions as well.
</Para>
<Para>
The latest version of this document can be found at <Ulink
URL="http://feenix.eyep.net/ldp/adsl/">http://feenix.eyep.net/ldp/adsl/</Ulink>.
</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
<Ulink url="mailto:hal@foobox.net">hal@foobox.net</Ulink>
</Para>
</Sect2>
<!-- ~ End Section ~ -->
<!-- ~~~~~ New Section ~~~~~ -->
<Sect2>
<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. What is true today,
may not be quite so true tomorrow. And there are exceptions to almost every
rule. And sometimes exceptions to the exceptions. So 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 seems to be the most
common 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.
</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. The latter group is playing a growing
role. Both are providing DSL services over existing copper lines.
</Para>
</ListItem>
<ListItem>
<Para>
'CO' is the telco acronym for 'Central Office'. Traditionally a building
where one end of your phone line physically terminates. The other end
terminating at your home, office, or wherever. It will be used here to
refer to the termination point regardless of whether it is a traditional
Central Office building or other, 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 your physical line -- or 'loop' as they
say.
</Para>
</ListItem>
<ListItem>
<Para>
'DSLAM' is the sophisticated hardware device in the telco's CO to which the
phone line physically connects, and thus makes DSL happen. Increasingly,
telcos are making use of smaller devices like the 'mini-RAM' in remote
locations. We'll use 'DSLAM' as a catchall for any device that enables a
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 to the DSLAM. 'Modem' is indeed the correct terminology since
there is MOdulation and DEModulation of the signal. These modems typically
have other features too. But 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 from the customer's end of the
connection.
</Para>
<Para>
Unless stated otherwise, we will also be assuming the 'modem' has an
ethernet interface, and will connect to a standard 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 a 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 for that matter,
to any extent. So the 'modem' will be just called a modem, regardless of
whatever other features it may have (i.e. router or bridge).
</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.
</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. <ULink URL="mailto:hal@foobox.net">Correct
me</ULink> if I am wrong!
</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 for non-privileged users.
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
</Sect1>
<!-- ~ End Section ~ -->
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
<Sect1 id="overview">
<Title>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 &nbsp; :-).
</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.
</Para>
<Para>
The downside is that DSL is not available everywhere. Availability, and
available bit rate (speed), are purely a function of where you live, where
the telco has installed the prerequisite hardware, how far you are from the
DSLAM/CO, and the quality of your phone line (loop). Not all loops are
created equal, unfortunately. The primary limitation is distance.
</Para>
<!-- ~~~~~ New Section ~~~~~ -->
<Sect2 id="family">
<Title>The DSL Family</Title>
<Para>
<ItemizedList>
<ListItem>
<BridgeHead renderas=sect3>ADSL</BridgeHead>
<Para>
or Asymmetric Digital Subscriber Line. Currently supports downstream rates
up to 8 Mbps, and upstream of 1024 Kbps, hence the 'asymmetric'. The most
widely deployed form of xDSL 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-line Digital Subscriber Line, or sometimes erroneously referred to
as 'Symmetric Digital Subscriber Line' 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 T1 and ISDN) which is
considered more robust than the DMT and 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?
</Para>
</ListItem>
<ListItem>
<BridgeHead renderas=sect3>IDSL</BridgeHead>
<Para>
ISDN Digital Subscriber Line, 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.
</Para>
</ListItem>
<ListItem>
<BridgeHead renderas=sect3>RADSL</BridgeHead>
<Para>
Rate Adaptive Digital Subscriber Line 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
(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 Line, 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 a viable
alternative (yet). 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 Line is a proposal from Europe that is
not yet in use.
</Para>
</ListItem>
<ListItem>
<BridgeHead renderas=sect3>G.SHDSL</BridgeHead>
<Para>
Standards 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 Line 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 1: A Typical DSL Connection Path
</Bridgehead>
<Para>
<Literal>
<MSGText>
<LiteralLayout>
Voice -+ +---> Voice
|<-- copper loop --> DSLAM/CO <--{ATM cloud}--->|
modem -+ | +---> Inet
| | |
ether..|..... DSL/ATM here ....|.... raw ATM here .....|.. TCP/IP ..
SOHO...|............ telco (ILEC or CLEC) .............|.. ISP ..| NSP
</LiteralLayout>
</MSGText>
</Literal>
</Para>
<!-- ~~~~~ New Section ~~~~~ -->
<Sect3>
<Title>Sync</Title>
<Para>
A good, working connection to the DSLAM is referred to as '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.
Secondarily, throughput will depend also on the ISP's network, and then the
ISP's upstream provider. You will lose approximately 15-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
around 1.2 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>
<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. The
only potential compatibility issue is the 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, and 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 be released 'any day'. At this time, this will require a 2.4.x kernel, and
a patch as well 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 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 also
requires a 2.4 kernel.
</Para>
<Para>
The most common type of modem in use today is actually a combination 'bridge'
and modem device. The other less common option is a 'router'. 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 features 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>
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.
</Para>
<Para>
<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>
<Title>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 their own ISPs. These, of course, are
connected to their DSLAMs, and are providing Internet services via the
telco's ISP subsidiary. But, also 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.
</Para>
<Para>
Also, 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. Though
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>
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>
<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 this much out. 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. 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 close enough, there are a number of potential impediments that
may disqualify a line: load coils and bridge taps are two such common
impediments. 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. 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
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 will also vary
wildly from provider to provider. Also, 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 as well. Cost of different
plans, of course, generally goes up with 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>
<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 box (or Mac) 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.
</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 &nbsp; :-)? 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 (reverse DNS), free web space, number of
email accounts, web mail, etc.
</Para>
</Sect2>
</Sect1>
<!-- ~ End Section ~ -->
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
<Sect1 id="installation">
<Title>Installation</Title>
<Para>
After the telco has qualified the loop, 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>
<!-- ~~~~~ 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 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.
</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 splittered
installation with this option. 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.
</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 wire
pair, e.g. IDSL. This means a separate line for DSL and Internet
connectivity. Also, DSL services from CLECs (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 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 POTS 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, while
others have a housing as large as the NID itself. Typically this is
mounted near the NID, on the customer's side of the demarcation point.
</Para>
</ListItem>
<ListItem>
<Para>
<Emphasis>Shared Line with Filters</Emphasis>. Again, for 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 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 2: 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 3: 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>
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 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>
<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>
<!-- ~~~~~ New Section ~~~~~ -->
<Sect3 id="homerun">
<Title>The Homerun</Title>
<Para>
<Emphasis>
"I would not use microfilters if I lived across the street
from my CO. A splitter is the way to go."
</Emphasis>
</Para>
<Para>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- 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. 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. So routing the
cable away from items that may have electric motors, transformers, power
supplies, high intensity lighting fixtures, dimmer switches and such is a
good way to go. And you are 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.
</Para>
</Sect3>
</Sect2>
<!-- ~ End Section ~ -->
<!-- ~~~~~ New Section ~~~~~ -->
<Sect2>
<Title>Wire the Splitter</Title>
<Para>
If you have the splitterless design or dedicated line, you may skip this part.
</Para>
<Para>
The splitter will 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 (sometimtes
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.
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 POTS, 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 either you've wired it wrong, or the DSL service is not yet connected
on the telco side. You could 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 is 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 4: 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>Installing and Testing 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. 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 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 dialtone and no DSL, or
DSL and no dialtone.
</Para>
</Sect2>
<!-- ~ End Section ~ -->
<!-- ~~~~~ New Section ~~~~~ -->
<Sect2>
<Title>Install and Connect the Network 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. See 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.
</Para>
<Para>
Be sure the RJ45 cable between the NIC and the modem is now connected. You
can hot plug this cable.
</Para>
<Para>
We can do a few quick tests now to see if the NIC is functioning properly:
</Para>
<Screen>
# ifconfig eth0 10.0.0.1 up
$ ping -c 50 10.0.0.1
PING 10.0.0.1 (10.0.0.1) from 10.0.0.1: 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.2 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.2 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=0.1 ms
&lt;snip&gt;
- 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 with out 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. This is notably true of some Alcatel models.
</Para>
</Sect2>
</Sect1>
<!-- ~ End Section ~ -->
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
<Sect1 id="configure">
<Title>Configuring Linux</Title>
<Para>
After you have connected the modem and you're 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>
<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>
<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
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
not sure, ask the ISP's tech support staff, or other users. 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).
</Para>
<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. DHCP is a standard, established networking protocol for obtaining an IP
address and other important network parameters (e.g. nameservers). This is a
very 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>
<Para>
The main alternative 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 form of
Point-to-Point Protocol adapted specifically for DSL networks. 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, 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.
</Para>
<Para>
There are several PPPoE clients for Linux. At this moment, PPPoA support is in
beta, but should be available very soon.
</Para>
<Para>
Both DHCP and PPPoX have mechanisms for obtaining an IP address and other
related networking configuration details so we don'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>
A raw ATM connection is yet another possibility, but this is rare, if
implemented at all, in the U.S. This 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.)
</Para>
</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 PPPoE
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>
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>
<!--
<Para>
Once your system has been configured, see if you can ping your default
gateway or nameserver addresses as provided by the ISP. If the ping is
successful, then you should see 10-40 ms roundtrip time for this connection.
Congratulations, you're connected to the Net!
</Para>
-->
<!-- ~~~~~ New Section ~~~~~ -->
<Sect3>
<Title>Static IP</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.
</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 instance. 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>
</Sect3>
<!-- ~ End Section ~ -->
<!-- ~~~~~ New Section ~~~~~ -->
<Sect3>
<Title>Bridged/DHCP</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 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. The other 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. See the client's man page, or your
distribution's documentation, for specifics.
</Para>
<Para>
<Emphasis>Caution!</Emphasis> If your ISP uses MAC address authentication,
and you change your network device (i.e. 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="ppoe">
<Title>PPPoE</Title>
<Para>
PPP over Ethernet (PPPoE) is becoming increasingly popular with ISPs. Setting
this up is 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">freshmeat.net</Ulink>, etc.
</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. It is under very active development. 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 does require 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>
<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.
This 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 docs for that package.
</Para>
<Para>
<Emphasis>Warning</Emphasis>! For PPPoX, the correct setting for MTU is 1492.
If the MTU is set too high, it will cause failure of web pages to load, and
possibly other annoying problems. The MTU must also be set for any interfaces
on LAN connections that may be masquerading. All interfaces that access the
WAN connection, should have this set.
</Para>
<Para>
Actually, the real setting should be 8 bytes less than any interface between
you and the ultimate destination. All Internet routers should be 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. 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>
As of this moment, there is not really a viable, working implementation of PPP
over ATM (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 seem to be
hardware/driver based, and Linux PPPoA modem drivers are scarce as hen's teeth
at this time. I do not believe the above modem is available through retail
channels. This may well 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>
<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>
<Para>
If PPPoA is your only option, you might consider one of the router/modems
that can handle PPPoA, and let the hardware handle everything.
</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. 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 downside is that most of these do not have the flexibility of a
Linux router, or other software solution. 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. The
router will also have a pre-configured, private IP address that you will
connect to from the LAN side. This will be your gateway. The public IP
address will be assigned to the WAN side interface. Typically these devices
also act as DHCP servers for the LAN side as well. So possibly all you have
to do is to start a DHCP client such as <Command>dhcpcd </Command>or
<Command>pump </Command> (Redhat based distros) to get up and running. Just
make sure the modem/router is syncing first. The appropriate steps and
configuration should be in the owner's manual, or available from your
provider.
</Para>
<Para>
If you are a PPPoX customer, and the router is handling this part of the
connection, then you will have to configure at least your user id and
password before connecting. If a Bridged/DHCP customer, you should just have
to activate DHCP on the router, and 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 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>Connection</Title>
<Para>
Everything should be in place now. You probably have already tested your
connection. You should be seeing ping roundtrip times of 10-40ms to the ISP's
gateway. If something has gone wrong, and you cannot connect, either
retrace the above steps, or see the <Link LinkEnd="trouble">Troubleshooting
Section</Link> below.
</Para>
</Sect2>
</Sect1>
<!-- ~ End Section ~ -->
<!-- ~~~~~~~~ New Section Header ~~~~~~~~~ -->
<Sect1 id="secure">
<Title>Securing Your Connection</Title>
<Para>
This section is intended for those who have not previously dealt with the
security implications of having a full time Internet connection. Or may not
understand some of the basic concepts of security. This is meant to be just a
quick overview, not a comprehensive examination of all the issues! Just
enough to give you a 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>Overview</Title>
<Para>
Before going on-line full-time, do not underestimate the need for securing
your connection. You will have two things that mischief makers and crackers
of the world are looking for: bandwidth, and a Unix-like OS. You instantly
become an inviting target. And it is just a matter of time before someone
comes knocking. 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. And 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 in the <Link LinkEnd="links">Links Section</Link>
below.
</Para>
</ListItem>
<ListItem>
<Para>
Take passwords seriously. Use shadow passwords. Do not allow remote root
logins.
</Para>
</ListItem>
<ListItem>
<Para>
Use <Command>ssh</Command>, or <Command>OpenSSH</Command>, instead of
telnet.
</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. And, 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. These fall into several
categories. The ones we are most concerned about are the 'privileged'
ports, i.e. 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 are where most
vulnerabilites are on Linux. These are 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.) 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>
<Para>
Unless you have a good reason for doing so, and know what you are doing, then
you should not be running these 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 a good idea, 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.
</Para>
<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. 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.
</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 in fact, 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 deamons 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>
<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>
<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. 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>
&nbsp;&nbsp;0-12 Kft - 1500 Kbps or more
12-16 Kft - 1500 Kbps -&gt; 1000 Kbps
16-18 Kft - 1200 Kbps -&gt; 512 Kbps
18-?? Kft - &nbsp;&nbsp;&nbsp;512 Kbps -&gt; &nbsp;128 Kbps or less :(
</LiteralLayout>
<Para>
Remember too that you will loose 15-20% of throughput to networking overhead.
So a 1500 Kbps connection, is only going to realize about 1200 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. Many 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 light if not in sync.)
</Para>
<!-- ~~~~~ New Section ~~~~~ -->
<Sect3 id="nosync">
<Title>No sync</Title>
<Para>
The modem sync LED has never been green.
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
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. Also, a remote possibility that the
DSLAM is down. They should know this as well.
</Para>
</ListItem>
<ListItem>
<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. This should effectively bypass
any inside wiring and environmental issues. The ethernet cable to the NIC
does not need to be connected just to run this test. The modem will sync
fine without it. (Easier said than done in some cases, 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, probably
something is wired incorrectly inside, or a short in a connection
somewhere, or there is severe electrical interference of the DSL signal.
Check splitter and wall jack. If a splitterless installation, look for bad
(e.g. corroded) connections on <Emphasis>all</Emphasis> POTS jacks, bad
splices, or defective microfilters!
</Para>
<Para>
If no sync on the above test, either the line was not readied, or maybe
the modem is defective. 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. Possibly one 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. 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 will
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 are 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.
</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, compiled 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. This may be evidenced by
<Command>ifconfig</Command> not showing an active interface, or
<Command>pinging</Command> gateway and other destinations generates
<Literal>network unreachable</Literal> or similar errors.
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
Make sure you know which protocol your ISP is using. Are they using DHCP
or PPPoX? 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 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>
</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, or are intermittently losing sync, or 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 also 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. For instance, a poor inside wire
connection may result in retransmissions of packets that have been lost, or
dropped. This can really reduce throughput and slow a connection down. 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, or impaired signal.
</Para>
<Para>
Some things to try:
</Para>
<Para>
<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. A number of things 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 -- 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 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. Moving 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 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>
</ItemizedList>
</Para>
</Sect2>
<!-- ~ End Section ~ -->
<!-- ~~~~~ New Section ~~~~~ -->
<Sect2>
<Title>Network 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 too 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>
Also, 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. But 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>
If you do find a problem within your ISP's network, it's time to report the
problem to tech support.
</Para>
<!-- ~~~~~ New Section ~~~~~ -->
<Sect3>
<Title>Miscellaneous Network Problems</Title>
<Para>
Some odds and ends:
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
<Emphasis>Some Web pages won't load.</Emphasis> For PPPoX users only, the
MTU value could be too high. The correct 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.
</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 do 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. 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>
</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 15-20% right off the top due to
networking overhead. 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.) 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 ~15-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="appendix">
<Title>Appendix and Miscellaneous</Title>
<Sect2 id="faq">
<Title>FAQs</Title>
<Para>
Some Frequently Asked Questions about DSL and Linux.
</Para>
<Para>
<OrderedList>
<ListItem>
<Para>
Q. Does xDSL work with Linux?
</Para>
<Para>
xDSL 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 bugaboo. Also, if the telco or ISP is
doing the installation, they may require a Windows or Mac system to be
available. This saves them the costs of training their techs on various
'alternative' OSes. Buyer beware!
</Para>
<Para>
Basically all xDSL 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 do not exist. You need
an external, ethernet interfaced modem. 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 &nbsp; :-).
</Para>
<Para>
This 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. Likely others will
follow suit. (Make sure you are reading the latest version of this
document, as I have intentions of keeping this situation updated as
needed.)
</Para>
</ListItem>
<ListItem>
<Para>
Q. How fast or good of a network card do I need?
</Para>
<Para>
Any card that is compatible with Linux should work fine. Remember even
low-end cards are 10 Mbps, and no consumer class DSL is near that at this
time. I would suggest a reasonably good quality card, just to help
eliminate the possibility of errors and premature failure.
</Para>
</ListItem>
<ListItem>
<Para>
Q. How can I find out when DSL will be available in my area?
</Para>
<Para>
Just where and when DSL gets deployed is totally in the hands of your
friendly local telco. They obviously can't do everyone at once, so they
probably are selecting areas based on competitive factors. Getting a
straight answer from a telco on this question, can also be a challenge.
Probably also so as not to tip their hand to competitors. But, 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. 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>
<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 600 Kbps or
so. Why? Is the service oversold? I am not getting what I pay for.
</Para>
<Para>
You will lose 15-20% of the rated capacity due to networking overhead. This
is just a fact of life for everybody. 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.
</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.
</Para>
</ListItem>
<ListItem>
<Para>
Q. Why PPPoX? This seems like a bad idea!
</Para>
<Para>
PPP gives several advantages to the provider: they can use their existing
infrastructure and hardware that they now use for their (larger) dialup
customer base. It is easier to control user authentication and potential
abuse situations, and easier to manage their network and related issues. In
fact, it most boils down to its just easier for them. Easier, means saves
man hours, and therefore saves costs (at least from their perspective).
</Para>
<Para>
It is not a conspiracy to conserve IP addresses, or thwart heavy users. IP
address costs are insignificant in the overall scheme of things.
</Para>
</ListItem>
<ListItem>
<Para>
Q. The only provider in my area does not support Linux. What can I do?
Will I have to use Windows?
</Para>
<Para>
NO! '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: 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, are
incompatible with each other.
</Para>
<Para>
A biased comparison from an DMT-based vendor on this subject can be found at
the <ULink URL="http://www.aware.com">Aware</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>
Asymmetric Digital Subscriber Line (ADSL) Metallic Interface
ANSI TI.413-1995
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 the heck does DSL have all these bit rates (384/1.5/8M/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 bandwidth that you see advertised reflect various
marketing wars of vendors equipment, and the telco struggle to finalize on a
'standard' set of data rates.
</Para>
<Para>
Also, check out the next question on the loop impairments that cause this to
happen.
</Para>
</ListItem>
<ListItem>
<Para>
Q: What are all these loop impairments (bridge taps, load coils, DLCs) that
could disqualify my line from DSL? (thanks to Bruce Ediger)
</Para>
<Para>
Load coils: in-line inductances that improve voice-frequency transmission
characteristics of a telephone circuit. Essentially, a "load" steals energy
from high frequencies and gives it to lower frequencies. Typically only used
in very long (&#62;9,000 ft) phone lines.
</Para>
<Para>
By "bridges" I assume you mean "bridged taps". In older neighborhoods, the
phone wiring will have been used by more than one customer. Perhaps these
customers lived at different (though near-by) addresses. The unconnected
"spur" of wiring is a "bridged tab" on the currently connected circuit.
</Para>
<Para>
DLCs, Digital Loop Carriers: there's a bunch of systems for carrying more
than one voice transmission on a single pair of wires. You can shift the
frequencies up or down, or you can digitize the voice transmissions and
divide the telephone circuit by time or code or something. The more
general term is "pair gain".
</Para>
<Para>
These things cause different problems for high-frequency communications.
</Para>
<Para>
Load coils will completely mess up things by filtering high frequencies and
passing low frequencies. They probably also change the "delay envelope",
allowing some frequencies to arrive before others. One byte's tones will
interfere with the next byte's.
</Para>
<Para>
Bridged taps act as shunt capacitances if they're long in relation to the
signals wavelength, and they'll actually act as band pass filters if they're
about 1/4 wavelength of the signal. That is, they'll pass particular
frequencies freely. Particular tones of a DMT modem might get shunted back,
rather than passed along to the receiving modem, reducing bandwidth for that
telephone line.
</Para>
<Para>
Pair gain, digital or analog, limit the bandwidth available to one
transmission in order to multiplex several on one wire. High and low tones
of a DMT transmission get filtered out by the apparatus.
</Para>
<Para>
The book "Subscriber Loop Signaling and Transmission Handbook", by Whitham D.
Reeve, , IEEE Press 1992, ISBN 0-87942-274-2 covers the math of how to
calculate the effect of line length, bridged tap, etc on the transmission
characteristics of a telephone line. It's pretty expensive, however.
</Para>
</ListItem>
<ListItem>
<Para>
Q: 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>
<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).
</Para>
</ListItem>
<ListItem>
<Para>
Bridge/Modems with 10/100baseT Ethernet Interface:
</Para>
<Para>
Examples: Alcatel 1000/SpeedTouch Home, 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/SpeedTouch Home, Cisco 627 (DMT), Ariel
Horizon II
</Para>
</ListItem>
<ListItem>
<Para>
Bridge/Modem with V.35 Serial Interface (T1, Serial Router)
</Para>
<Para>
Examples: Westell ATU-R
</Para>
</ListItem>
<ListItem>
<Para>
Modem 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. These are NOT endorsements of the products
listed, just provided for illustration. &nbsp; ;-).
</Para>
</Sect2>
<!-- ~ End Section ~ -->
<!-- ~~~~~ New Section ~~~~~ -->
<Sect2 id="links">
<Title>Links</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
Other related documentation from the Linux Documentation Project:
</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>
<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>
<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>
<Para>
SuSE's Linux 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 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>.
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 PPPoE
client that is distributed by some ISPs.
</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 opensource project based on the Alcatel SpeedTouch Home USB modem is 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>
<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>
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>
ADSL Forum Home Page: <ULink
URL="http://www.adsl.com">http://www.adsl.com</ULink> A comprehensive web
site created by the ADSL vendors. Fairly complete for reference information
on ADSL.
</Para>
</ListItem>
<ListItem>
<Para>
<ULink URL="http://www.alumni.caltech.edu/~dank/isdn/adsl.html">Dan Kegels
ADSL Page</ULink> A good general reference on xDSL - 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>
<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.
</Para>
</ListItem>
<ListItem>
<Para>
<ULink URL="http://www.geocities.com/Paris/Metro/5013/adsl.html">ADSL
Deployment 'round the World</ULink> Claims to have a complete list -
looked accurate for my area - gives providers, prices, speeds, etc.
</Para>
</ListItem>
<ListItem>
<Para>
<ULink
URL="http://homepage.interaccess.com/~jkristof/xdsl-faq.txt">comp.dcom.xdsl
FAQ</ULink>. Actively maintained, and a great technical reference for DSL
technologies.
</Para>
</ListItem>
<ListItem>
<Para>
<Ulink Url="news://comp.dcom.xdsl">comp.dcom.xdsl</Ulink>, DSL discussions,
vents, and flames on Usenet. Good place to get technical questions answered
that your ISP can't.
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<!-- ~ End Section ~ -->
<!-- ~~~~~ New Section ~~~~~ -->
<Sect2 id="glossary">
<Title>Glossary</Title>
<Para>
A dictionary of some of the jargon used in this Document, and in the
telco and DSL industries.
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>ADSL</Term>
<ListItem>
<Para>
Asymmetric Digital Subscriber Line. '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 xDSL 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>
<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>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 only 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 - An IP protocol used to set up
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' xDSL 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 in fact now standardizing on DMT.
The other, less common, ADSL encoding is 'CAP'. CAP and DMT modems are not
compatible 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>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>DSLAM</Term>
<ListItem>
<Para>
Digital Subscriber Line 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 Line - 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> for more. </Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>HDSL</Term>
<ListItem>
<Para>
High bit rate DSL. See <Link LinkEnd="family">DSL Family</Link> 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. And is a good thing for consumers IMHO.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>ISDN</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>
</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>
</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 xDSL, a 'clean' copper loop within the distance
limitations is required.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>MAC</Term>
<ListItem>
<Para>
Media Access Control. 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. Not much of a tweakable
factor, but is especially important that for PPPoX it be set correctly,
i.e. at 1492. Otherwise, 1500 is good.
</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>
</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>
</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> 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&#38;T.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>RFI</Term>
<ListItem>
<Para>
Radio Frequency Interference. DSL is susceptible to RFI if in the right
frequency range, and close enough to the DSL signal.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>SDSL</Term>
<ListItem>
<Para>
Single Line DSL. Also, sometimes '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>
</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
</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>
<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 &nbsp;;-):
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
<Emphasis>All</Emphasis> external, ethernet based modems, and modem
combination devices, should work no problem. 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 extraordinairy lengths. Alpha and Beta projects do not count.
</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). And, should not
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=Linux Friendly ISP">Linux
Friendly</ULink>. Please included ISP's official name, URL (if not obvious),
location and coverage area, modem type, 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 6 below, I use an old i486 machine configured as a
firewall/router between the DSL connection and the rest of my machines. 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
Internet connection. 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. Also, for 2.4 kernels see <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. And 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 6: 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 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>
</Sect2>
</Sect1>
</Article>
<!-- ~~~~~~~~~~~~~~~~~~~~ finis ~~~~~~~~~~~~~~~~~~~~~~~~~ -->