1.1. Document Structure and Reading Guidelines

This document attempts to give a comprehensive discussion of DSL. All aspects are hopefully addressed to one degree or another with what can be a complex topic since it deals with networking, hardware, new fangled technologies, and various approaches taken by various vendors. The core components of this document are:

• The Installation section covers installation of DSL hardware and related components, including wiring considerations, splitter or microfilter installation, modem and Network card installation.

• The Configuring Linux section covers mostly client and software aspects of getting the connection up and running. The Network card configuration is actually covered mostly in the above Installation section.

• The Securing Your Connection section covers Security implications that are even more important with a full-time connection. Linux users seem especially targeted by crackers, because quite frankly, some don't understand how important security is, or don't understand the finer points of this. And who wants to "own" a Windows box?

• The Tuning and Troubleshooting section covers post-installation topics like how well is our connection performing, and how to track down any show-stoppers or intermittent problems.

• There is also a lengthy Appendix that covers various topics relating to Linux and DSL. None of these are directly related to simply getting that connection up and running, but may be of interest nonetheless.

To simplify the navigation of this document, below is a suggested reading guideline. Everyone should read the Introduction. Please pay special attention to the Conventions and Terminology section, as some of this terminology may be used somewhat differently in other contexts. Also, there is a Glossary if you get lost in the world of TA (telco acronyms) ;-).

• If you don't know anything about DSL, you should probably read the entire document. You may want to start with the DSL Overview section in the Appendix, and then the FAQ. The DSL Overview explains how the various pieces of the puzzle fit together. DSL network implementations are more complex than traditional dialup networks.

• If you have already done some homework, but have not ordered service from anyone yet, read the Choosing Providers section. Also, you might get a head start by reading the Configuring Linux section so you know what lies ahead.

• If you have ordered service already, and are awaiting delivery, you can skip the sections on choosing a Provider. If you will be doing a self-install, you should read the pertinent parts of the Installation section, the Configuring Linux section, and the Securing Your Connection section.

• If the installation is complete, and you can't get a working connection, skip right to the Troubleshooting Section. If you are not clear on what protocols are required, or what software you need to have installed, also read the Configuring Linux section. If not sure what terms like "sync" mean in this context, then be sure to read the DSL Overview section first so you know how it all fits together.

• If trying to decide between cable and DSL, read the Cable vs DSL section, and possibly the DSL Overview section.

• If you have never had a full-time Internet connection, or are not absolutely sure you fully understand how to secure you connection, be sure to read The Securing Your Connection section. If you don't understand some aspect of this, re-read it, or start looking for other references.

• There is a comprehensive Links section that has references to some topics not touched on in the main body of the Document itself.

1.2. What's New

1.71: Add info on the IteX PCI ADSL modem only.

1.7: Added comments on ISDN line filters being different than POTS, and other additions related to ADSL over ISDN in various places. Add another supported modem: Eci Hi Focus ADSL Modem (and various related chipsets). Removed the 'Linux Friendly ISP' section. The landscape has changed much since this section was started. Back then there were few options for DSL in many places, and all too often a non-compatible modem was the only thing available. Also, the advent of microfilters and self-installation has helped with the "do-it-yourselfer" approach, giving everybody more freedom. Then, maintaining this number of links was a PITA too. I still encourage new subscribers to shop their local markets if there are options. Many large ISPs and telcos have very poor ideas of what an Internet connection is and restrict severely what you can do with Linux. Or at least try to ;-) Updated LDP links to tldp.org (from linuxdoc.org).

1.6: Several new Linux Friendly ISPs. Clarification on problems with alarm systems. Minor touch ups to other sections, and fix some broken links (never ending job :).

1.5: New Tuning sub-section using iproute. Hot stuff! Other additions to the Tuning section. A few new ISPs. Alcatel SpeedTouch USB section updates. Thanks to Alex Bennee for clarifying things. Other minor updates to FAQ, Glossary and Tuning.

1.4: A few new and updated URLs, and catch ups. The Alcatel USB modem section is revamped. A few new ISPs.

Version 1.3: Updates to the SpeedTouch USB HOWTO in the appendix. Minor update to PPPoE section, and two new Linux Friendly ISPs. A feeble attempt to make the document a little less U.S.-centric. Various minor updates.

Version 1.2 adds PPTP configuration section for Alcatel ethernet modems. Also, added are two additional sections in the "Tuning" section for the TCP Receive window, and ADSL/DMT interleaving. And the big news is the release of open source drivers for the Alcatel USB modem as of March 2001. There is an Alcatel SpeedTouch USB mini HOWTO in the appendix by Chris Jones. A number of miscellaneous updates as well.

Version 1.1 included quite a few minor corrections, updates, and additions. Not much that is substantially new. There are finally two Linux compatible DSL PCI modems from Xpeed. The drivers are now in the kernel 2.2.18 source (not ported to 2.4 as of this writing 05/23/02).

Version .99 addresses some of the many changes that have occurred since the original ADSL mini HOWTO was published. Originally, ADSL was the primary DSL technology being deployed, but more and more some of the other DSL flavors are entering the picture -- IDSL, SDSL, G.Lite, and RADSL. Thus the renaming from "ADSL mini HOWTO" to the "DSL HOWTO". There have been many other changes in DSL technology as well. PPPoE/A encapsulation has become more and more common as many ISPs are jumping on this bandwagon.

1.3. Copyright

DSL HOWTO for Linux (formerly the ADSL mini HOWTO)

Copyright © 1998,1999 David Fannin.

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.

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.

You can get a copy of the GNU GPL at GNU GPL.

1.4. Credits

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.

• B Ediger (Xbediger@csn.net) Great Description of loop impairment.

• C Wiesner ( Xcraig@wkmn.com) List of many ADSL URLs.

• J Leeuw ( Xjacco2@dds.nl) Many tips on ADSL, especially in Europe

• N Silberstein ( Xnick@tpdinc.com) Info on Netrunner and his experience with US Worst.

• Many and various posters from comp.dcom.xdsl and bellsouth.net.support.adsl, too numerous to mention individually. (HB)

• Juha Saarinen for suggestions and explanations on the TCP Receive Window, and related tuning topics.

• Chris Jones <chris@black-sun.co.uk> for his Alcatel SpeedTouch USB mini HOWTO which was previously incorporated into the Appendix. Also, Alex Bennee for clarifying the driver situation for this modem.

1.5. Disclaimer

The authors accept no liability for the contents of this document. Use the concepts, examples and other content at your own risk. As this is a new edition, there may be errors and inaccuracies. Hopefully these are few and far between. The author(s) do not accept any responsibility for incorrect or misleading information, and would certainly appreciate any corrections. Also, this type of technology dates itself very quickly. What may be true today, is not guaranteed to be true tomorrow.

All copyrights are held by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.

References to any particular product, brand, service or company should not be construed as an endorsement or recommendation. Excepting Linux itself, of course!

1.6. Feedback

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 <hal@foobox.net>

1.7. Conventions, Usage and Terminology

For the sake of simplicity and sanity, let's clarify some of the terminology that we will be using in this document, so that we are all on the same page. While many of the definitions below are not always 100% technically correct, they are close enough for our purposes here. In fast moving technologies like DSL, there are so many "ifs, ands, and buts" that it is difficult to say anything with any degree of certainty and have it stick. And there are exceptions to almost every rule. And sometimes exceptions to the exceptions. We will be dealing with generalities to a large degree here, please keep that in mind.

• "DSL" will be used to refer to the entire family of DSL technologies now available -- ADSL, SDSL, IDSL, RADSL, etc. ADSL still seems to be the most prevalent at this time, but the others are being deployed as well. Where it is important to differentiate one type of DSL from another, the full proper name will be used: e.g. RADSL. xDSL is also commonly used to refer to the various DSL technologies as a group, but we will be using just "DSL" here.

• 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 or state run phone companies, and where the monopolies now have competition, the CLECs (Competitive Local Exchange Carriers), or independent providers such as Covad in the U.S.

• "CO" is the telco acronym for "Central Office". Traditionally this is a building where one end of your phone line physically terminates. The other end terminates at your home, office, or wherever. It will be used here to refer to the telco end termination point, regardless of whether it is a traditional Central Office building or another, smaller, remote structure or device.

• "Loop" is telco speak for "phone line". Essentially, you should think of your loop as one dedicated pair of copper wires that run uninterrupted from your residence or office directly to the CO. This is perhaps an oversimplification, but will serve our purposes. DSL availability, and signal quality, is tied directly to the characteristics of your physical line -- or "loop" as they say.

• "POTS" is the acronym for Plain Old Telephone Service. In other words, traditional, non-digital devices like analog phones, faxes and answering machines. ISDN is used for DSL in some areas, so POTS is not the only way to piggy-back DSL. But certainly the most common in many places.

• "NID", or Network Interface Device, is the small telco housing that is often typically attached to the outside wall of your house, and is the service entrance for telco services, though may be placed elsewhere depending on the phone company. This may variously also be referred to as "ONI", "SNI", "NIU", "TNI" or other creative telco acronyms. It represents the "demarcation" point that divides the customer's realm of responsibility from the telco's. Commercial structures, and multi-family housing will likely have something more sophisticated, and probably located inside somewhere.

• "DSLAM" is the sophisticated hardware device in the telco's CO where your phone line physically terminates, and thus makes DSL happen. Increasingly, telcos are making use of smaller devices like the "mini-RAM" in remote locations. We'll use "DSLAM" here as a catch-all for any device that enables DSL service from a telco. These are now being manufactured by a number of companies.

• "Modem" will be used to refer to the end user device that enables a DSL connection. Your "modem" is connected to the telco's DSLAM in the CO via your copper loop. When they are "talking" DSL to each other, they are in "sync". Without "sync", no connection to your ISP is possible.

  "Modem" is indeed the correct terminology since there is MOdulation and DEModulation of the signal, even though it doesn't resemble an analog 56K modem like many of us have had before. These modems incorporate other features too -- so they are more than just a "modem". Some ISPs and manufacturers may be marketing simply "routers", "bridges", or even "brouters" for this purpose. These are essentially DSL modems with enhancements. A compatible "modem" of some kind is the minimum hardware requirement at the customer's end of the connection. The most commonly supplied modem is actually a combination bridge and modem.

  One distinction here may be where ADSL is provided over ISDN lines. In this case, the term "modem" is not appropriate and the only physical difference is that the ISDN Network Terminator (NT), is equipped to handle DSL, but is still an NT. In any case, for brevity, we will take license here to refer to all such devices as "modems".

  Unless stated otherwise, we will also be assuming the "modem" has an ethernet interface, and will connect to a standard ethernet Network Card (NIC). This is far and away the most prevalent configuration for Linux users, at least until more Linux drivers are available for PCI and USB modems. USB modem are quite popular otherwise, because they are "plug 'n play", and arguably less expensive.

  It is worth noting that "routers" as supplied by DSL providers are typically modem/router combination devices. In our context, "router" will refer to these devices as such. There are also SOHO broadband routers available that are only dedicated routers and lack the modem functionality.

• Previous versions of this document referred to the modem as an "ANT" (ADSL Network Termination). While this may be technically correct terminology, it is not used by ISPs, manufacturers, telcos, or most users to any extent. The "modem" will be just called a modem, regardless of whatever other features it may incorporate (i.e. router, bridge, etc.).

• PPPoX will be used to refer to PPPoE (PPP over Ethernet) and PPPoA (PPPoATM, or PPP over ATM) collectively. These protocols are being used by many DSL providers now.

• The information provided in this document is based mostly on the current state of DSL in the U.S. I will assume there are enough similarities with DSL services outside of the US that this document would still have some merit for everyone. Correct me if I am wrong by emailing <hal@foobox.net>.

• A "#" will be used to denote a command that typically is run by the root user. Otherwise, a "$" will be used as the prompt for non-root users.

2.1. Pre-Installation

In many parts of the world, there is no choice on who you get DSL from: your friendly local telco, of course! They own the copper wires, and thus they hold all the cards.

However, in the U.S. de-regulation has opened this up somewhat. Beyond the obvious consideration of price, there are reasons to investigate which alternate providers may be offering DSL services in your area. The large Telephone companies are everywhere, and may advertise the most. But increasingly smaller ISPs and independents are getting into the act. This has created some diversity in the DSL marketplace. A good thing of course, but possibly creating a little confusion too. Conversely, in areas where there is only one choice, then we have no choice but to accept whatever service is being offered.

If your telco has a monopoly on phone service and DSL, you may skip the rest of this section. And probably the next few sections. They will probably control the installation and qualification processes, and you just wait for them to get finished.

Not all DSL services are alike. Just because two local companies are offering "ADSL", does not mean that necessarily there is much in common at all. In fact, there are potentially a number of factors that make one ADSL provider's service significantly different from another's. Some things to consider:

• Speed vs Price.

• What hardware is provided, i.e. modem or router. It is best if this is external ethernet in either case.

• The ISP's Network architecture. PPPoX? Static IP? Servers allowed?

• Is it an "always on" service, at least theoretically? Are there supplemental usage fees, or idle timeouts?

• Linux friendly, Linux hostile, or Linux agnostic? This is not as much of a problem as it used to be in most areas. Some providers are still very restrictive on allowing "servers", and possibly even LAN connections. Buyer beware. Talk to other users, and read their TOS (Terms of Service) to get a feel for their attitude.

• Quality of service. How is news, mail, etc.? News particularly seems to be inconsistent with low-end broadband providers. Probably because of the dramatic increase in binary news content, which is compounded by the higher bandwidth and increased usage of such groups.

For a more lengthy discussion on some of these considerations and related issues, see the DSL Overview appendix for more on modems, qualifying for service, and choosing a provider.

Once you have chosen a provider, and ordered service, the next step is for the telco to "qualify" your loop. This essentially means testing your line to make sure it can handle the DSL signal, and possibly what level of service may be available to you. This may take some time, especially if the telco encounters problems with the loop. If no problems are found during this phase, then possibly there will be a one to three week wait for the installation. YMMV.

After the telco has qualified the loop and readied their end of the connection, the next step is installation of the necessary components at the customer's end of the connection: wiring modifications, splitter or filters, and, of course the modem and any necessary software.

2.2. Installation Options -- Self Install or Not

You may or may not have a choice on how the installation is done, or who does it. This is totally at the discretion of the provider. In much of the world, this is done by the telco, and there is little flexibility. Many providers in the U.S. offer a "self install" option where you do all the work. In this scenario, the provider will send a kit in order to save them from sending a tech, and thus reducing cost. Typically, self install kits will include microfilters for the POTS (Plain Old Telephone Service) or ISDN (where ADSL over ISDN is used) phone jacks, the modem (and maybe a NIC), and a CDROM with drivers, etc. on it. In some cases, a splitter may be included instead of microfilters. In any case, some type of filtering is necessary on the non-DSL lines. If not the noise generated by the DSL signal may interfere with regula telco devices such as phones and answering machines.

The other possibility is for the provider to do the installation. Again, this may be your only option. Obviously, the cost is higher here, but it may have the advantage of having a trained tech do any wiring. There is also a better chance of getting a "splittered" installation with this option (a good thing!). Another benefit is that if something is wrong with the line, or the telco has not provisioned the line properly, an on-site tech may be able to help sort out certain kinds of problems quickly.

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.

2.3. Wiring/Installation Options

There are various wiring schemes depending on how your service is being provided, who is providing it, and which DSL service is being provided. If your telco is performing the installation, you may skip this section.

• Dedicated Line. Some DSLs require a dedicated, or "dry", wire pair, e.g. IDSL. This means a separate, physical line without dial-tone for DSL and Internet connectivity. Also, DSL services from CLECs (independent telcos like Covad), may use a dedicated line, depending on their line sharing agreement with the local incumbent carrier. (Instead the CLEC will actually lease a loop from the ILEC.) On your end, this simply means using one of the unused wire pairs in the telco wire bundle, and connecting it to the DSL jack.

• Shared Line with Splitter. For DSLs like ADSL, that are provided over the same line as regular voice service, the signal must be filtered somehow so that voice services are not adversely effected. Installing a splitter splits the line into two pairs, and filters the DSL signal from one of them. This results in a inside wiring scheme where DSL goes to only one jack, and then regular voice type service to all other jacks. This is considered by many to be a better type of installation than "splitterless", i.e. with microfilters instead. See below.

  Splitters are available from various manufacturers and come in various shapes and sizes. Some are small enough to fit in the NID itself (sometimes called SNI, this is the telco phone box on the outside of your house), while others have a housing as large as the NID itself. Typically this is mounted near the NID, on the customer's side of the demarcation point.

• Shared Line with Filters. Again, for some DSLs that piggyback on the POTS (or ISDN) line, the signal must be filtered or split at some point. This is not necessary for g.lite or RADSL however. The other way of doing this is by placing RJ11 "microfilters" in each phone jack -- except where the DSL modem will be. 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. This is a very common approach in the U.S. Note that in areas where ADSL over ISDN is provided, filtering is required also, but the filters themselves are quite different and are not interchangeable with POTS filters!

  Similar microfilters are sometimes used by some telcos to reduce the excessive "whine" on the line that is produced by some modems. This is a little different approach as the filter is put on the same jack as the modem.

• Shared Line, Splitterless and Filterless. Some newer DSLs, like G.Lite, have no adverse effect on regular POTS devices and thus require no filters or splitters. This would seem to be the wave of the future. Just plug and play. Though still not very common.

Figure 1: DSL Block Diagram with Splitter (NID not shown)

       <--------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 |              |     |
                            -----              |     |
                                               -------

    

Figure 2: DSL Splitterless (a.k.a. filtered) Block Diagram

       <--------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  |=-------|                    |     |
           -----------                             -------
 
 
    

2.4. Self Install - Wiring

If you are not doing a self-install, then you may skip this section and move to Configuring Linux. If you are doing a self-install with microfilters, skip to the mircofilter section. 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.

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.)

Be aware that typical telco wire has more than one pair per bundle. Often, two pairs, but sometimes more. If you have but one phone line, the other pair(s) are unused. This makes them available for use with wiring for DSL. Wire pairs are color coded for easy identification. SDSL and IDSL require a dedicated, or "dry", pair. If an unused pair is available, then no real re-wiring is required. It is just a matter of re-wiring an existing jack for the correct pair of wires, and attaching the modem.

2.5. Wire the Splitter

If you have the splitterless design (i.e. using "microfilters") or a dedicated line, you may skip this part.

The splitter will typically consist of two parts, the splitter and a small outdoor housing. Mount the splitter and accompanying housing per the telco's instructions at the Network Interface Device (NID) point (also sometimes called the SNI or ONI), usually the side of your house where the phone line is located. Put it on your side of the NID. The phone company may need to access the splitter for maintenance, so its advisable to locate it on the outside where they can get at it, but outside is not absolutely necessary.

The wire bundle should have at least two separate wire pairs. The splitter takes one pair, and separates the signal onto two pairs. One pair in the bundle will then go to all phone jacks, and the other to the modem's DSL wall jack. So connect the incoming telco line to the LINE side of the splitter. Then wire the inside pair for your telephone to the VOICE, and your inside wire pair for the modem to DATA.

Checkstep At this point, you should be able to pull dial tone off the voice side of the splitter. If this doesn't work, then you've wired it wrong. You can also plug the modem into the test jack in the NID box (most should have this). Plug in the modem's power cord, and if the line is provisioned correctly, you should "sync" in less than a minute. This test only requires the modem. (Internal and USB modems will require a driver to be loaded before syncing. This would mean having the computer there too.)

2.6. Wire the DSL Jack

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 read the directions, as the DSL-RJ11 wiring may be different for phones and DSL jacks. AND -- different modems may expect the signal on different pairs -- most on the inside pair, but some on the outside pair.

Figure 3: RJ11 Wiring options

 
    ||
    ||
    ||
   /  \
  |RJ11|   
  |    |  
   ----
   ||||
   
    ^^  <-- Inside     Most modems on inside pair
   ^  ^ <-- Outside    Some on outside, e.g. Alcatel 1000, SpeedTouch Home

   

2.7. Installing Microfilters

Pretty much a no-brainer here. If you are doing a "splitterless", self-install installation, then install the provided microfilters in all phone jacks except the one where the DSL modem will be connected. Don't forget devices like fax machines and analog modems. The filters filter out the higher DSL frequencies and will keep the DSL noise from interfering with POTS (or ISDN) equipment.

Warning! Alarm systems can present various problems, depending on the type of alarm and how it is installed. This may require telco help for proper installation so the one does not interfere with the other. Common microfilters tend not to work because most alarm boxes use a different size jack. Filters are now available just for alarm boxes, though traditionally this has been handled with a splitter type installation.

2.8. Installing an Ethernet Modem

To install, connect the modem's (or router's) power cord, and connect the phone line between the DSL wall jack and the modem. This cable should be provided. If not, a regular phone cord will suffice. With the ethernet interfaced modems, you may also connect the ethernet cable between the NIC and the modem (but not really necessary at this point just to verify an ethernet modem is working).

Checkstep At this point, verify that the modem syncs with the telco's DSLAM signal. Most modems have a green LED that lights up when the signal is good, and red or orange if not in sync. The modem's manual will have more details on the LEDs. If it doesn't sync, then check your wiring, or make sure that the DSL signal is being sent. Do this by calling your telco and verifying they have activated the service. Or by testing the modem at the test jack on the NID (see above). Note that having dial tone on the line does NOT confirm the presence of the DSL data signal. And vice versa -- perfectly possible to have dial tone and no DSL, or DSL and no dial tone. There should also be no static or noise on the voice line when everything is installed and functioning properly.

# ifconfig eth0 10.0.0.1 up


$ ping -c 50 10.0.0.1
PING 10.0.0.1 (10.0.0.1) from 10.0.0.1: 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.2 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.2 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=0.1 ms
<snip>

- 10.0.0.1 ping statistics -
50 packets transmitted, 50 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.2 ms


$ ifconfig eth0
eth0    Link encap:Ethernet  HWaddr 00:50:04:C2:09:AC  
        inet addr:10.0.0.1  Bcast:10.255.255.255  Mask:255.0.0.0
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:428 errors:0 dropped:0 overruns:0 frame:0
        TX packets:421 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:100 
        Interrupt:10 Base address:0xc800 

 

2.9. Installing a USB Modem

The physical installation of a USB modem is similar to an ethernet modem. There is no ethernet card necessary obviously. So connect the phone line between the DSL wall jack and the modem's DSL port, and attach the USB cable to the computer's USB port.

USB modems will require vendor and model specific drivers in order to sync and function properly. Assuming you are using the Alcatel SpeedTouch USB, this will require both a binary firmware driver available from Alcatel's driver page: http://www.speedtouchdsl.com/support.htm, and a separate modem driver.

This driver also supports both PPPoE and PPPoA, though the steps for getting either to work are quite different. See the Appendix for more on this modem.

The Eci Hi Focus ADSL Modem has some support in Linux now too. See http://eciadsl.sourceforge.net/.

3.1. Bridged vs PPPoX Networks

Before we get too far into the final stages of installing and configuring our system, let's look at how various DSL ISPs set up their networks. It will be very important for you to know how your ISP does this, as there is more than one possibility and the steps involved are quite different for each. This may not be the kind of thing the ISP is advertising, and since you are not using Windows, you may not have access to the setup disk that the ISP provides. If you're not sure, ask the ISP's tech support staff, or better, find other knowledgable users of the same service.

To muddy the waters even more, some ISPs may be offering more than one kind of service (over and above the various bit rate plans). Example: Verizon (formerly Bell Atlantic) originally offered static IPs with a Bridged connection. Now all new installs use PPPoE with dynamic IPs. For installation and configuration purposes, this is very different.

The two most common DSL network implementations are Bridged/DHCP and PPPoX. Both have mechanisms for obtaining an IP address and other related networking configuration details so we shouldn't have to worry about this. But there are indeed other, less common, means of connecting. Our job will be finding the right client, and doing what we have to, to get it up and running. The most common ones are discussed below.

Important! You need to know beforehand how your ISP is setup for connecting to his network. To re-iterate, the two main possibilities are Bridged/DHCP and PPPoE. These are mutually exclusive implementations. And there are indeed other possibilities as well. So you will need to know exactly what this is beforehand. And it must be the right one or you will waste a lot of time and effort. You cannot choose which one either. It is a matter of how the ISP is doing his network. Note that PPPoE can run over Bridged networks, so just knowing whether you are Bridged or not, is not necessarily good enough. If your provider is giving you a router, there is a good chance that the router's firmware will handle all of this for you.

If you are subscribing with one of the Baby Bells in the U.S., you can count on that being PPPoE, and thus you will need a PPPoE client.

There are a few provider specific FAQs and HOWTOs in the Links section below.

3.2. Configuring the WAN Interface

The most common configuration is a DSL modem in "bridging" mode. Both PPPoX and DHCP can use this setup. In this scenario, the WAN interface typically means your NIC. This is where your system meets the outside world. (If you have a router see below for router specific instructions.) So essentially we will be configuring the NIC, typically "eth0" since it is an ethernet interface.

With PPPoX, once the connection comes up, there will be a "ppp0", or similar, interface, just like dialup. This will become the WAN interface once the connection to the PPP server is up, but for configuration purposes we will we be concerned with "eth0" initially.

There are various ways an ISP may set up your IP connection:

• Static IP.

• Dynamic IP on Bridged Network via DHCP.

• Dynamic IP via PPPoX.

• Static IP via PPPoX.

Let's look at these individually.

 # ifconfig eth0 111.222.333.444 up netmask 255.255.255.0
 # route add default gw 111.222.333.1 dev eth0
 
 

---

3.2.2. Bridged/DHCP Configuration

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. dhcpcd seems to be the most common. pump comes with Redhat based distributions as of Redhat 6.0. The DHCP client will obtain an IP "lease" from the ISP's server as well as other related information: gateway address, DNS servers, and network mask. The lease will be "renewed" at regular intervals according to the ISP's configuration.

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.

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 ifconfig, and looks something like 00:50:04:C2:19:BC. You will need to give the ISP the MAC address before your first connection.

The other DHCP authentication method is via an assigned hostname. In this case, the ISP will have provided you with this information. Your DHCP client will need to pass this information to the server in order for you to connect. Both dhcpcd and pump accept the "-h" command line option for this purpose. See the client's man page, or your distribution's documentation, for specifics.

	Note
	If your ISP uses MAC address authentication, and you change your network device (e.g. NIC), you will need to register the new address with the ISP or you won't be able to connect.

---

3.2.3. PPPoE Configuration

PPPoE (PPP over Ethernet) is an alternate way for ISPs to control your connection, and is becoming increasingly popular with ISPs. Setting this up is quite different, and may be a little more work than with static IPs or DHCP above. Recent distro releases are now shipping PPPoE clients. If this is not the case for you, then you will have to download one. Check any Linux archive site like http://freshmeat.net, etc. or look below.

Some of the current GPL PPPoE clients available:

• The Roaring Penguin (rp-pppoe): http://www.roaringpenguin.com/pppoe/, by David F. Skoll. Reportedly very easy to set up, and get started with. This is a popular Linux PPPoE clients due to it's reputation for ease of installation, and is now being bundled with some distributions. rp-pppoe works as a user-mode client on 2.0 and 2.2 kernels, and in kernel-mode on 2.4 kernels.

• PPPoEd: http://www.davin.ottawa.on.ca/pppoe/ by Jamal Hadi Salim is another popular Linux client and is also bundled with some distros. This is a kernel based implementation for 2.2 kernels. A setup script is now included so no patching is required, making installation quick and easy. Also, less CPU intensive than user space alternatives like rp-pppoe (2.0/2.2 kernels).

• PPPoE Redirector: http://www.ecf.toronto.edu/~stras/pppoe.html. 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.)

• 2.4.x kernels include native PPPoE support. The PPPoE for 2.4 page is http://www.shoshin.uwaterloo.ca/~mostrows [link is dead, sorry, can't find new page] and is by Michal Ostrowski, the maintainer for kernel PPPoE. This includes detailed instructions for installing and configuring kernel mode PPPoE.

• EnterNet is a non-GPL'd PPPoE client from NTS, http://www.nts.com, that is being distributed by some ISPs as the Linux client. It does come with source code but the it is not available for free download. (I haven't found anyone that is impressed by this one.)

Depending on which client you have chosen, just follow the INSTALL instructions and other documentation included with that package (README, FAQ, etc.).

Once a PPPoE client connects, your connection should look something like the below example from Roaring Penguin, where "eth0" is connected to the modem:

$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.254 * 255.255.255.255 UH 0 0 0 eth1 208.61.124.1 * 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 208.61.124.1 0.0.0.0 UG 0 0 0 ppp0 $ ifconfig eth0 Link encap:Ethernet HWaddr 00:A0:CC:33:74:EB UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:297581 errors:0 dropped:0 overruns:0 frame:0 TX packets:266104 errors:1 dropped:0 overruns:0 carrier:2 collisions:79 txqueuelen:100 Interrupt:10 Base address:0x1300 eth1 Link encap:Ethernet HWaddr 00:A0:CC:33:8E:84 inet addr:192.168.0.254 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:608075 errors:0 dropped:0 overruns:0 frame:0 TX packets:578065 errors:0 dropped:0 overruns:0 carrier:0 collisions:105408 txqueuelen:100 Interrupt:9 Base address:0x1200 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:1855 errors:0 dropped:0 overruns:0 frame:0 TX packets:1855 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 ppp0 Link encap:Point-to-Point Protocol inet addr:208.61.124.28 P-t-P:208.61.124.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:297579 errors:0 dropped:0 overruns:0 frame:0 TX packets:266102 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10

Note

PPPoE adds 8 bytes of extra overhead to the ethernet frames and the correct initial maximum setting for the ppp0 interface MTU is 1492. If the MTU is set too high, it may cause a fubar packet fragmentation scenario, known as the Path MTU Discovery blackhole where the two ends of the connection fail to communicate. A typical symptom would be the failure of some web pages to load properly, and possibly other annoying problems. You may need to also set the MTU for interfaces on any masqueraded LAN connections MTU to 1452. This does not apply to PPPoA, bridged, or routed configurations, just PPPoE! See rfc2923 for a technical explanation.

Actually, for PPPoE the real setting should be at least 8 bytes less (the extra PPPoE protocol overhead) than any interface between you and the ultimate destination. All routers normally would be set to 1500, thus 1492 is correct from your end. But, it may happen that somewhere a router is configured at a lower setting, and this can cause problems, especially with web pages loading, and other traffic failures. The way to test this is to keep dropping the MTU until things 'work'.

---

3.2.5. PPTP/PPPoA with Alcatel Ethernet Modems

Alcatel SpeedTouch Home ethernet modems (supersedes the Alcatel 1000) support both bridged and PPPoA connections. The modem itself handles the PPPoA protocol internally. When in PPTP/PPPoA mode (as opposed to RFC1483 bridging mode), Linux will connect to the modem via PPTP (MS VPN). The Linux PPTP homepage is http://cag.lcs.mit.edu/~cananian/Projects/PPTP/, and works well with this modem. In addition to installing pptp, your kernel must also have support for PPP.

The modem has internal configuration pages than can be reached by pointing a browser to the default IP address of http://10.0.0.138. (You will of course have to have your NIC set up for a 10.0.0.0 network with similar IP such as 10.0.0.1, in order to reach the modem's configuration pages.) For PPPoA, the connection type is 'PPTP'. You will have to get the other settings from your provider if the defaults do not work. Settings such as 'VPI/VCI' and 'encapsulation' can vary from provider to provider. Of course, if the modem is coming from your provider, all this should be already configured.

The next step is to configure pptp, which is done by configuring the pppd files /etc/ppp/pap-secrets (or chap-secrets) and /etc/ppp/options. This is where the username and password is entered. For example:

/etc/ppp/pap-secrets:

# client secret server IP address 
login@isp.com  *    my_password_here    *

   

and /etc/ppp/options:

 
name "login@isp.com"
noauth
noipdefault
defaultroute

   

Once everything is configured properly, it should be just a matter of starting pptp, pointing it to the modem's address:

#pptp 10.0.0.138

	Note
	Alcatel supplies many sub-models of these modems. These features may not be available on all models, or may be altered from the defaults. This is something to be aware of, if buying a used modem. This modem only supports one concurrent PPTP connection.

---

3.2.6. Modem/Router Configuration

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, working NIC should be all that is required to make this work.

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 modem's firmware will handle this. The downside is that most of these do not have the flexibility of a Linux router, or other software solution. Of course, you could set up a Linux router behind the router, and have the best of both worlds. The ones with more and better features are also going to cost significantly more.

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 dhcpcd or pump (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.

If you are a PPPoX customer, and the router is handling this part of the connection, then you will have to configure at least your user id and password before connecting. If a Bridged/DHCP customer, you should just have to activate DHCP on the router, and possibly register the MAC (hardware address) of the router with your provider. Some routers have "MAC cloning" which means that they will report the MAC address of the attached NIC. If static IP, then you will have to configure this as well.

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.

# ifconfig eth0 10.0.0.2 up netmask 255.0.0.0 # route add -net 10.0.0.0 $ ping 10.0.0.1

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.

Even if the ISP is not offering any router options, there are quite a few available from third party manufacturers such as Netgear, Linksys, Cisco, Zyxel, Cayman, Alcatel and others. These will have all the features already mentioned and maybe more. Just make sure it matches your provider's DSL. This is one good way around the PPPoX bugaboo.

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 most measures. Be sure to read the fine print before buying and make sure you know how much real firewalling is included.

3.3. Connect

Everything should be in place now. You probably have already tested your connection. You should be seeing ping roundtrip times of 10-75 ms to the ISP's gateway. If something has gone wrong, and you cannot connect, either retrace the above steps, or see the Troubleshooting Section below.

4.1. Security Quick-start

Before going on-line full-time, do not underestimate the need for securing your connection. You will have two things that mischief makers and crackers of the world are looking for: bandwidth, and a Unix-like OS. You instantly become an inviting target. It is just a matter of time before someone comes knocking. Possibly a very short time. A quick start:

• 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 ps and netstat to see what services are running. (See man pages for specifics). Do you really need named, sendmail, telnet, ftp 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.

  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.

• If you decide some services are essential, make sure you are running the most current version. Exploits are found, and then get fixed quickly. Don't get caught with your pants down. A full-time connection makes staying updated very easy -- and very important. Check with your distribution to see what new packages are available. Then stay in touch. If they have a security mailing list, get on it.

• Take passwords seriously, using non-dictionary "words". Use shadow passwords (this should be a standard feature of newer distributions). Do not allow remote root logins. See the Security HOWTO for more details and ideas.

• Use ssh instead of telnet or rsh.

• Set up a firewall to limit access, and log connection attempts. This will be different depending on which kernel series you are using: ipfwadm for 2.0, ipchains for 2.2, and iptables for 2.4. See the below HOWTOs for a more in depth discussion on this and other security related topics:

• • Security-Quickstart-HOWTO and for Redhat based distros Security-Quickstart-Redhat-HOWTO

  • Firewall HOWTO

  • Security HOWTO

  • IPCHAINS HOWTO

  • Netfilter/Iptables docs

  • IP Masquerade HOWTO

  Additional references are in the Links Section below.

5.1. Tuning

OK, now we are up and running, and we want to be running at warp factor nine. No such thing as too fast, right?

Linux networking is pretty robust, even a default installation with no "tuning". You may well not need to do anything else. But if your connection is not performing up to what you think it should be, then possibly there is a problem somewhere. This may be a more worthwhile approach than the pursuit of any magical "tweak".

A very rough guideline on what you might reasonably expect as a maximum sync rate, based on distance from DSLAM/CO:

There are many conceivable factors that could effect this one way or the other. Newer generations of DSL will surely improve this, as will related technologies like repeaters.

You will loose 10-20% of the modem's attainable sync rate to networking overheads (TCP, ATM, ethernet). So a 1500 Kbps connection, is only going to realize about 1100-1300 Kbps or so of real world throughput. No tweaking is going to change the built-in protocol overheads. Also, if your service is capped at a lesser speed by your provider, then you can't get above that speed no matter what. AND -- that there are numerous variables that can effect your loop/signal quality, and subsequently your speed (aka sync rate). Some of these may be beyond your control.

But there are a few things that you might want to look at.

 #echo 262144 > /proc/sys/net/core/rmem_default 
 #echo 262144 > /proc/sys/net/core/rmem_max

 

 
 #echo 262144 > /proc/sys/net/core/wmem_default 
 #echo 262144 > /proc/sys/net/core/wmem_max

 

 # sysctl -a 
 net.ipv4.tcp_rfc1337 = 1
 net.ipv4.ip_no_pmtu_disc = 0
 net.ipv4.tcp_sack = 1
 net.ipv4.tcp_fack = 1
 net.ipv4.tcp_window_scaling = 1
 net.ipv4.tcp_timestamps = 1
 net.ipv4.tcp_ecn = 0

 

5.2. Installation Problems

Read this section, if you have no sync at all or are completely unable to connect. See your modem's owner's manual for interpreting the modem's LEDs. (Many will show a solid red (or orange) light if not in sync.)

5.3. Sync Problems

Read this section if you have had a working connection, but now have lost sync, are intermittently losing sync, your sync rate has dropped significantly, or are getting a "sync/no surf" condition. (Better quality modems will have a way to report sync rate, usually via telnet or a web browser interface. See the owner's manual.)

A loss of sync indicates a problem with the DSLAM, your line (inside or outside) or your modem. DSLAMs typically have "shelves" with "cards". Alcatel DSLAM cards, just for instance, have a capacity of four connections each. If the card goes bad, at most four customers are effected. The point being that sync loss outages can be very isolated. Unlike network outages that tend to effect large numbers of users. Sync outages are a telco problem, not an ISP problem. If your service agreement is with the ISP, you will need to contact them, who will in turn contact the telco.

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 dropped. This can really reduce throughput and slow a connection down. It is tempting to think of packet loss as a traditional networking problem, but with DSL it is possible to be the result of a bad line, impaired signal, or even the modem itself.

Some things to try:

• Power cycle the modem. Turn off the power button/switch, and physically unplug the cable to the wall jack for 30 seconds or so. Turn back on, and re-attach to the wall jack. This will force a resync. Unfortunately, the only way to power down a PCI modem, is to reboot. This may fix a "sync/no surf" condition that is caused by the modem, and maybe other conditions too.

• See the above section on moving the modem lock, stock and barrel to the NID and thus bypassing all inside wiring. If the situation is improved there, then the problem is inside somewhere. If not, it is a telco problem.

• RFI Bear-hunt: The DSL signal is fragile. There are a number of things that can degrade it. RFI, or Radio Frequency Interference, from sources in and around the home/office is one common source of reduced signal strength, intermittent sync loss, low sync rates and high line error rates that can cause retransmissions and slow things down. DSL frequencies just happen to be in a range that is susceptible to many potential RFI sources. Our test tool here is simply a portable AM radio. Tune it to any channel where you can get clear reception -- it makes no difference where. The AM radio will pick up RFI that is in the same frequency range as the DSL signal. It will sound like "frying bacon" type static. Put it against your computer's power supply. You should hear some static. Move it away and the static should fade pretty quickly. This will give you an idea of what RFI sounds like. A decent quality power supply should produce only weak RFI -- probably not enough to cause a problem. Use the radio like a Geiger counter and move it around your modem and DSL line. If you hear static, follow it to the source. Things to be suspicious of: power supplies, transformers, ballasts, electric motors, dimmer switches, high intensity lighting. Moving the modem, or rerouting cables is sometimes enough. Keeping the line between the modem and the wall jack as short as possible is a good idea too.

• Chronic sync problems are often due to a line problem somewhere. Sometimes it is something as simple as a bad splice or corroded jack, and easily remedied if it can be found. Most such conditions can be isolated by a good telco tech. Check with your provider, and politely harass them if you have to. If you get the run-around, ask to go over their heads.

• If you are near the distance limits of DSL, and having off and on sync problems, try the "Homerun" installation. See above. This can be effective in improving marginal signal/sync conditions.

• If using a surge protector, try it without the surge protector. Some may interfere with the DSL signal.

Another possibility is a nearby AM radio station, or bandit ham radio operator that are disrupting the DSL signal since they operate in a similar frequency range. These may only cause problems at certain times of day, like when the station boosts its signal at night. A good telco DSL tech may be able to help minimize the impact of this. YMMV.

5.4. Network and Throughput Problems

Read this section if your connection is up, but are having throughput problems. In other words, your speed isn't what it should be based on your bit rate plan, and your distance from the CO. "Network" here is the WAN -- the ISP's gateway and local subnet/backbone, etc. Remember that a marginal line can cause a reduced sync rate, and this will impact throughput. See above.

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 ping and traceroute. 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%.

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.

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.

 $ ping -c 12 -n www.tldp.org
 PING www.tldp.org (152.19.254.81) : 56(84) bytes of data.
 64 bytes from 152.19.254.81: icmp_seq=0 ttl=242 time=62.1 ms
 64 bytes from 152.19.254.81: icmp_seq=1 ttl=242 time=60.8 ms
 64 bytes from 152.19.254.81: icmp_seq=2 ttl=242 time=59.9 ms
 64 bytes from 152.19.254.81: icmp_seq=3 ttl=242 time=61.8 ms
 64 bytes from 152.19.254.81: icmp_seq=4 ttl=242 time=64.1 ms
 64 bytes from 152.19.254.81: icmp_seq=5 ttl=242 time=62.8 ms
 64 bytes from 152.19.254.81: icmp_seq=6 ttl=242 time=62.6 ms
 64 bytes from 152.19.254.81: icmp_seq=7 ttl=242 time=60.3 ms
 64 bytes from 152.19.254.81: icmp_seq=8 ttl=242 time=61.1 ms
 64 bytes from 152.19.254.81: icmp_seq=9 ttl=242 time=60.9 ms
 64 bytes from 152.19.254.81: icmp_seq=10 ttl=242 time=62.4 ms
 64 bytes from 152.19.254.81: icmp_seq=11 ttl=242 time=63.0 ms
 
 --- www.tldp.org ping statistics ---
 12 packets transmitted, 12 packets received, 0% packet loss
 round-trip min/avg/max = 59.9/61.8/64.1 ms

 

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:

 $ 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

 

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 traceroute, by just picking a random site:

 $ 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

 

The first hop is the gateway. In fact, for me the first two hops are always 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 (normal for me!):

 
 $ 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

 

And a problem with the same gateway on a different day:

 $ 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

 

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.

It's a little tempting on this last real-life example to think this gateway router is acting up. But, as it turned out, this was the result of a problem in the DSLAM/ATM segment of the telco's network. So any first hop problem with packet loss or high latency, may actually be the result of something occurring before the first hop. We just don't have the tools to isolate where it is starting well enough. Packet loss can be a telco problem, just as much as an ISP/NSP problem. Or conceivably, even a modem problem. In which case try resetting the modem by power cycling and by unplugging/replugging the DSL cable (from the wall jack).

It is also quite possible for the modem itself to cause packet loss. The fix here is to power cycle the modem, and resync by unplugging the DSL connection for 30 seconds or so. In fact, any part of the connection can be a source of packet loss -- modem, DSLAM, ATM network, etc.

If you do find a problem within your ISP's network, it's time to report the problem to tech support.

5.5. Measuring Throughput

One of the first things most of us do is check our speeds to make sure we aren't getting short changed, and that our system is up to snuff. Doing this accurately is easier said than done however. First, remember you are losing 10-20% right off the top due to networking protocol overhead. Just how much is "lost" here depends on your provider's network architecture, where and how you are measuring this and other considerations. Most of us may wind up being closer to 20% than 10%.

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.

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.

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 http://www.dslreports.com/stest/0. Another test is http://speedtest.mybc.com/ (both are Java). I find these to be better than some of the others out there.

Now keeping in mind that we are limited by the ~10-20% networking overhead rule, here is an example. My speed is capped at 1472 Kbps sync rate. Minus the ~15% is 1275 Kbps. My sync rate is known to be good and my distance to the CO is about 11,000 Ft, which is close enough that I should be able to hit my real world maximum throughput of 1275 Kbps or roughly 1.2-1.3 Mbps -- all other things being equal. From dslreports.com speed test:

 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.

 

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.

Big Caution: my ISP uses a caching proxy server for web pages. This is a big equalizer for these kinds of web based tests. Without that, I surely would have been significantly slower on this test. The effect of the proxy is that you are actually testing throughput from the proxy -- NOT the test site. Just FYI. Another note: at the same time I tried another test site and was consistently getting 600-700 Kbps. So YMMV with these tests. (Usually I get the same on each, more or less.) Timing a large ftp download from two different sites, I calculated about 1.25 Mbps.

6.1. The DSL Family

• ADSL

  Asymmetric Digital Subscriber Loop currently supports downstream rates up to 8 Mbps, and upstream of 1024 Kbps, hence the "asymmetric". ADSL is far and away the most widely deployed consumer DSL, and was specifically developed for the home and SOHO markets. The higher downstream rates lends itself to those not running serious servers -- at least anything more than a small, personal web site. ADSL is capable of sharing data with a POTS (or ISDN) voice line, so an additional line is not required. A big selling point. ADSL, like other DSLs, is limited by distance. 18,000 ft (5.5 km) is a typical cut-off point for telcos. ADSL does typically require either a splitter or filters to isolate the DSL signal from POTS. Sometimes referred to as "full rate" ADSL in order to differentiate it from G.Lite DSL. There are two line encodings for ADSL: DMT and CAP. DMT (a.k.a. Alcatel compatible) has won the standards battle and is now the standard and the most common. Also, note that modems must be compatible with the encoding. In other words, a CAP modem will not work with a DMT service, and vice versa. Also, ISDN requires "modems" (NTs), and related hardware such as filters, that are specific to that type of line since the signal on the line is very different for POTS and ISDN.

• G.Lite

  G.Lite is sometimes referred to as "DSL Lite", "Universal DSL" or "splitterless ADSL", is a slower version of ADSL that requires no splitters or filters. G.lite uses a "fast retrain" technique to negate the various signal disturbances caused by normal POTS usage. Currently G.Lite supports speeds up to 1.5 Mbps/512 Kbps, and at one time was expected to become the dominant consumer DSL service. As of this writing, it is not nearly as wide spread as "full rate" ADSL however.

• SDSL

  Single-pair Digital Subscriber Loop, or also sometimes referred to as "Symmetric Digital Subscriber Loop" since it is indeed symmetric with a current maximum rate of 1.5 Mbps/1.5 Mbps. SDSL requires a dedicated line, and thus true SDSL is not as readily adaptable to the consumer market as ADSL. SDSL also uses a 2B1Q encoding (same as ISDN and some T1) which is considered more robust than the DMT or CAP encoding of ADSL. True SDSL is generally considered more of a server quality DSL, and is typically marketed as a business class service. It is worth noting that some providers may be promoting a "SDSL" service that is really ADSL pinched so that upstream/downstream are the same. Or vice versa, SDSL with asymmetrically allocated bandwidth. Wasn't all this confusing enough already?

• IDSL

  ISDN Digital Subscriber Loop, 144 Kbps/144 Kbps is really a new and improved ISDN from Lucent Technologies and uses the same 2B1Q line encoding as ISDN, SDSL and others. IDSL does require a dedicated line however. The benefits are that it is an "always on" technology, like other DSLs, and provides an additional 16 Kbps over traditional ISDN. It is being marketed by some DSL providers as a low end bit rate option, where line quality is not sufficient for higher speeds such as that of ADSL. Ironically, IDSL is generally priced significantly higher than ADSL.

• RADSL

  Rate Adaptive Digital Subscriber Loop was developed by Westell and has a potential of 2.2 Mbps downstream and 1.0 Mbps upstream. What makes RADSL more flexible is that the sync rate can be dynamically adjusted up or down as line conditions change. This makes it more of a viable alternative where line conditions are marginal due to distance or other factors. In many respects, RADSL is an enhanced ADSL to meet a more diverse set of line conditions. Like ADSL, RADSL can piggyback on the POTS line. RADSL does not require any splitters or filters.

• HDSL

  High bit-rate DSL was one of earliest versions of DSL. HDSL requires multiple, dedicated wire pairs, and is symmetric at 1.5 Mbps/1.5 Mbps (the speed actually depends on number of wire pairs used). Not a viable alternative for the consumer or SOHO markets.

• VDSL

  Very high rate Digital Subscriber Loop is a DSL still in development with a current downstream capacity of 52.8 Mbps, and upstream of 2.3 Mbps. At this time, VDSL is limited to very short loop lengths, and is not yet a viable alternative. It may find application where there is fiber to the neighborhood, and thus the copper loop segment is relatively short.

• UDSL

  Unidirectional Digital Subscriber Loop is a proposal from Europe that is not yet in use.

• G.SHDSL

  The standards for G.SHDSL have just recently been finalized. SHDSL includes many enhancements, including better reach, better rate adaptation, and better upstream bandwidth. G.SHDSL is symmetric with speeds up to 2.3 Mbps, and will more than likely be marketed as an SDSL alternative.

6.2. The DSLAM

This technology is made possible by the placement of DSLAMs, or Digital Subscriber Loop Access Multiplexers, from such suppliers as Alcatel and Cisco, in the telco's Central Office, or sometimes a suitable remote location. DSLAMs come in various shapes and sizes, and are the one, single complex and costly component of a DSL connection. When a qualified phone line is connected to a modem at the user's end of the loop, a high speed digital connection is established, typically over ATM, or sometimes frame relay. The DSLAM splits the signal back into separate voice and data channels. The voice channel stays within the telco network, whereas the data is picked up by an ISP (typically).

Figure 4: A Typical DSL Connection Path

 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
 
   

 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->

 

6.3. DSL Modems

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!

For Linux users, the modem is a very important consideration! There are many modems supplied by ISPs that are not Linux compatible. Your best bet is an external, ethernet interfaced modem (or modem/router combo) that connects via a standard ethernet NIC, since many other modem options (PCI, USB, onboard) will not work due to a lack of drivers at this time! All ethernet based modems will work fine. (See the Modems Section for an up-to-date list of compatible modems.) ISDN users will need a modem (NT) designed specifically for DSL over ISDN.

With ethernet modems, the only potential compatibility issue is the Network Card (NIC). (And really any compatible ethernet NIC should do just fine -- 100 Mbps is not even necessary.) You are probably better off anyway, since PCI and USB modems can be more problem prone. If your chosen provider does not offer a compatible modem as an option, then you either need to look elsewhere, or you will have to buy one outright from a third party.

As always, there are exceptions. Xpeed now has drivers for two PCI modems included with the kernel drivers (as of 2.2.18, not in 2.4 yet though AFAIK). These are the first open source Linux DSL modem drivers, and is welcomed news. Alcatel's ADSL SpeedTouch USB modem now has Linux drivers. And more recently, the Eci Hi Focus ADSL USB Modem has drivers (and some related chipsets are supported as well, see http://eciadsl.sourceforge.net/). IteX PCI ADSL modems, based on the Apollo chipset, have Linux drivers. (Modems using this chipset are sold under a number of various brand names.) Diamond also makes [made?] an internal PCI modem which has binary-only drivers, but it is not in widespread use, and seems to be discontinued at this point. It is also possible to make a direct ATM connection using a modem plus an ATM network card, though this delivery system is not used in the U.S. as far as I know, and should not be considered as a viable option. This would also require a 2.4 kernel.

The most common type of modem in use today is actually a combination "bridge" and modem device. The bridge is a simple device, typically with little configuration. Network traffic passes blindly across the ATM to ethernet bridge in either direction. Your point of exposure is the interface (typically a NIC) that is connected to the modem/bridge.

Some ISPs are also offering "routers". These are basically combination modem/routers that can handle NAT, and may have other feature enhancements such as port forwarding, a built in hub, etc. These are all external, so should work too. But probably not a big deal for Linux users, since Linux can do anything these do, and more. A locked down Linux box makes a most excellent firewall/gateway/proxy!

To confuse things even more, there are also all-in-one devices: combo bridge+router+modem, sometimes called "brouters". In this case, the modem can be configured for either bridged or routed modes -- but it can't be both at the same time.

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).

While some ISPs provide modems that are not readily available through normal retail channels, there are a number of manufacturers that are getting on the DSL modem bandwagon, and offering a good selection. Most have a number of enhancements. At this time Alcatel (now owned by Thomson), Intel, Zyxel, Cisco, 3Com, and Cayman have products available. Depending on model and feature set, prices range from a little over $100 US to $800 and up. Many of these handle their own authentication and encapsulation (DHCP, PPPoE, etc).

Are some modems better than others? Short, easy answer: no. Modems are not much of a factor in speed in most cases. But some do have enhanced features, such as diagnostics or the combo modem/routers. Ethernet modems are generally considered the most reliable. Fewer IRQ hassles, no buggy drivers, etc. So the fact that Linux users are mostly relegated to ethernet modems is a blessing in disguise really. Are any of these better than others? Hard to say since most of this is so new there is not enough of a track record to compare brands and models with any degree of assurance. In other words, any old external, ethernet modem should do -- provided it matches your provider's DSL, and is configured for that service. Remember, there can be differences here.

Make sure any third party modem or router you may purchase is compatible with your DSL provider. There are two major line encodings for ADSL (CAP and DMT a.k.a. Alcatel compatible), and several options for IP encapsulation. And different DSLs (SDSL, IDSL, etc) will require their own modems too, as will ISDN lines. Your provider should have a list of compatible options. It may well have to be configured for your ISP's service too. Don't expect it to work right out of the box either (unless it does indeed come from your provider). Many are accessible via telnet, or a web browser, where the configuration options are available. See the owner's manual for this.

6.4. The ISP Connection

The modem connects to the DSLAM, and then the DSLAM is connected to the telco's ATM network (or frame relay), where it is picked up by the ISP. The ISP typically will take over at what we "see" as the first hop on a traceroute. Everything up to that point is in the hands of the telco/DSL provider. The ISP will connect to the telco's ATM network via a high-speed data connection, usually ATM over a DS3 (45 Mbps) or possibly an OC-3 (155 Mbps). The important thing here is that an ISP must "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.

The Baby Bells (RBOCs) in the U.S. all own ISPs. These, of course, are connected to their DSLAMs, and are providing Internet services via the telco's ISP subsidiary. Many independent ISPs are availing themselves of the ILEC's DSL services, and in essence "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.

CLECs (independent telcos) are now installing their own DSLAMs in many U.S. markets. This makes them a direct competitor to the ILEC. In this scenario, there would be two (or more) DSL providers in the same CO, each with their own DSLAM(s), and each competing against each other. This complicates the ISP situation even further, as each DSL provider will be "partnered" with one or more ISPs. If you are lucky here, you will have many choices of plans and pricing structures.

At this time, there is a shake out going on in the U.S. market. The independents are all struggling to match the deep pockets of the regional phone companies. The independents that have survived are now focusing more on small business and higher-end consumer customers. This means, it will cost more, but you should also expect to get more. Especially, in the quality department.

Typically, your service agreement is with the ISP, and not the DSL provider. This makes the actual DSL provider a "behind the scenes" player. This may vary, and in some cases, you may wind up with a separate service agreement for both the DSL provider and the ISP.

6.5. Availability

Who can get DSL? The first requirement is that a telco has installed the necessary hardware somewhere on their end. Typically this is in the CO. You have no choice on which CO is yours -- it is wherever your loop terminates. If your CO has a DSLAM, and the necessary other components, then DSL may be available to you. This is often known as "pre-qualifying", and is Step One in getting service.

More and more "remote terminals (aka DSLAMs)" are being deployed. This is certainly good news for those that are a long way from the CO. CO distance is not the limiting factor it once was.

6.6. Choosing Providers

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.

• A compatible modem. For now with Linux (or any alternative OS) this essentially means an ethernet interface. (There are rare exceptions.) "Routers" (i.e. combo modem/routers) should be OK too since these seem to be all ethernet devices.

• Installation. A self-install option, of course, let's anyone get up and running, and is less expensive. But if there is no self-install available, will the provider install onto a Linux only site? Many will not! Having a Windows (or Mac) box temporarily available is a work around here. Even a laptop may be enough.

• Static vs Dynamic IP Address. If wanting to run servers, or hosting your own domain, static is the way to go. A dynamic IP, on the other hand, makes you a little harder to find should you wish to remain "invisible", or a least harder to keep track of.

• Encapsulation. 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.

• Server Policy. 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.

• Contract. Is there a contract, and what are the out clauses? Cancellation fees?

• Connection Limits. Is it "always on" (at least theoretically :-)? Are there session limits, or idle timeouts? Is bandwidth metered and limited to so much per month? Do they forbid a LAN behind the connection (dumb!)?

• Linux Support. 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.

• Free Dialup Account. A nice thing to have if the connection is down, or you just need to check mail from another location.

• Setup program. 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.

• Reliability and Quality of Service. 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?

There are a number of other options and features that might be worth looking at too: multiple IPs, domain hosting (DNS), free web space, number of email accounts, web mail, etc. All things considered, the better plans are probably going to cost more for a reason.

8.1. Links

• Other related documentation from the Linux Documentation Project:

  • Firewall HOWTO

  • Security HOWTO

  • IPCHAINS HOWTO

  • IP Masquerade HOWTO

  • Home Network mini HOWTO

  • Ethernet HOWTO

  • Networking Overview HOWTO

  • Net HOWTO, previously named the NET3-4-HOWTO, the definitive, in-depth guide to various Linux networking topics.

  • Linux 2.4 Advanced Routing HOWTO. All the great features of Linux's sophisticated traffic management capabilities are explained here, including performance enhancing ideas relevant to DSL.

  • DHCP HOWTO

  • VPN HOWTO

  • VPN Masquerading HOWTO

• More on the 2.4 kernel packet filtering from The Netfilter Project at http://netfilter.samba.org/. Several good HOWTOs for the new features available with 2.4 kernels and iptables.

• Check your security and see what ports are open at http://hackerwhacker.com/. This is one of the better sites for this. Some only test a relatively few ports.

• SuSE's Linux PPPoE page is at http://www.suse.de/~bk/PPPoE-project.html. Good information on most of the available Linux PPPoE implementations.

• Bob Carrick's definitive PPPoE site is at http://www.carricksolutions.com/. His Linux PPPoE page is at http://www.carricksolutions.com/linuxpppoe.htm. It has some other DSL related information as well. All OSes are covered.

• The NTS EnterNet for Linux documentation can be found at http://support.efficient.com/KB/NTS/Docs/ENLinux13rel.html. This is a non-GPL'd PPPoE client that is distributed by some ISPs.

• ATM on Linux: http://linux-atm.sourceforge.net/. Where to find the latest info on PPPoA and raw ATM connections.

• FreeSwan, http://www.freeswan.org, is an IPSec and IKE VPN implementation for Linux.

• VPN and Masquerading on Linux: http://www.tldp.org/HOWTO/VPN-Masquerade-HOWTO.html

• PPTP-linux allows you to connect to a PPTP server with Linux. The home page is http://cag.lcs.mit.edu/~cananian/Projects/PPTP/.

• Justin Beech's http://dslreports.com, 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.)

• John Navas's Cable and DSL site, http://cable-dsl.home.att.net, has good general info, tweaks, troubleshooting, hardware info, etc. for all OSes.

• TCP Performance Tuning tips: http://www.psc.edu/networking/perf_tune.html. Tips on Linux, and other OSes.

• A great Linux security site is http://linuxsecurity.com. Good docs, and references for Linux. Another is http://linux-firewall-tools.com/linux/. Lots of info from Robert L. Ziegler, author of Linux Firewalls. Many links to other security related sites as well.

• http://www.seifried.org/lasg/, The Linux Administrator's Security Guide by Kurt Seifried. Good tutorials on a variety of topics -- not just firewalls, but the big picture.

• The Seattle firewall is a packet filtering firewall that can be used on a dedicated masquerading firewall machine (including LRP), a multi-function masquerade gateway/server or on a stand-alone Linux system. The ipchains project is located at http://seawall.sourceforge.net/. And for iptables: http://shorewall.sourceforge.net/.

• Here a few pages dedicated to using Linux with specific providers. (I could use some submissions for more please.)

  • Verizon: http://www.panix.com/~dfoster/prog/linux/pppoe.html

  • Southwestern Bell: http://home.swbell.net/sdboyd56/DSL/connect1.html

  • BellSouth: http://personal.bellsouth.net/sdf/h/b/hburgiss/dsl/survival/linux.htm

  • HomeChoice (UK): http://www.maxuk.net/hc/faq.html. (This gets my vote for the strangest ADSL service anywhere.)

  • BT-Internet (UK): http://www.tldp.org/HOWTO/mini/BTI-PPP/index.html This covers both dial-up and ADSL connections.

  • German T-DSL: http://www.datenhighway.com/adsl/

  • France Télécom's Netissimo: http://www.rhapsodyk.net/adsl/HOWTO/. Good information on setting up PPTP with Linux for Alcatel modems.

  • Austrian Highspeed Internetconnection & Linux HOWTO: http://www.members.aon.at/heimo.schoen/at-highspeed-howto.html.

  • Israel (various ISPs covered): http://vipe.technion.ac.il/~mulix/adsl-howto.txt

• Now that you have a full-time connection, want a routable hostname for your computer? Dynamic DNS services can do this, even if your IP changes from time to time. Just a few of the many available services:

  • http://dyndns.org

  • http://tzo.com

  • http://easydns.com

  • http://no-ip.com

  • http://www.microtech.co.gg/dns

• ADSL Deployment 'round the World Claims to have a complete list - looked accurate for my area - gives providers, prices, speeds, etc.

• comp.dcom.xdsl FAQ. Actively maintained, and a great technical reference for DSL technologies.

• comp.dcom.xdsl, DSL discussions, vents, and flames on Usenet. Good place to get technical questions answered that your ISP can't.

8.2. Glossary

A dictionary of some of the jargon used in this Document, and in the telco and DSL industries.

8.3. Other Consumer Class High Speed Services

8.4. Compatible Modems

This list is limited to those modems and delivery systems that are readily available, and should work with any current Linux distribution without having to go to extraordinary lengths. Alpha and Beta projects are not included. All modems listed are POTS (analog) modems at this time.

Ethernet Interface

• All external, ethernet based modems, and modem combination devices, will work (provided they match the provider's DSL). The only requirement is a compatible ethernet network card. This is the preferred way to go.

PCI (Internal)

• Xpeed X200 IDSL http://www.xpeed.com/Products/x200/x200_c.html (as of kernel 2.2.18)

• Xpeed X300 SDSL http://www.xpeed.com/Products/x300/x300_c.html (as of kernel 2.2.18)

• IteX PCI ADSL modem based on the Apollo chipset, also sold under various other brand names such as Dlink and ALH110. http://www.itexinc.com/.

USB

• Alcatel SpeedTouch USB (ADSL): http://www.speedtouchdsl.com/support.htm. The driver is kernel module and requires a 2.4 kernel. See the Appendix for driver information.

• Eci Hi Focus ADSL Modem: http://eciadsl.sourceforge.net/. This project seems to support several modems and chipsets, including ez-usb an2131qc, gs7070 and gt3180.

8.5. Setting up Linux as a Router

Depending on your local setup, you should consider some other issues. These include a firewall setup, and any associated configurations. For my setup, shown in Figure 5 below, I use an old i486 machine configured as a firewall/router between the DSL connection and the rest of my home network. I use private IP addresses on my private LAN subnet, and have configured my router to provide IP Masquerading and Firewalling between the LAN and WAN connections.

See the IP Masquerade HOWTO , and Firewall HOWTO for more information. For 2.4 kernels see the Linux 2.4 Advanced Routing HOWTO. My experience is that Linux is more flexible and provides superior routing/firewalling performance. It is much less expensive than a commercial router -- if you find an old 486 machine that you may be using as a doorstop somewhere. There any number of brands of "DSL/Cable" routers on the market as well. These might be the way to go for pure ease of use, but lack the sophistication of what Linux can do.

Figure 5: A typical SOHO Network Setup

  
 <--Private Subnet/LAN-> Linux <-----ISP's Public Subnet----><--inet-->
      192.168.1.0
 

 X--+   -------- 
    |   |      |        --------      (eth0:0)---------
    +--=| Hub/ |       | Linux  |     +------=|  DSL  |=-DSL-> ISP's
 X-----=|Switch|=-----=| System |=----+       | Modem |       Gateway
    +--=|      |  eth1 |(Router)| eth0        ---------
    |   --------    |   --------    |
 X--+               |   IP_Masq     |
                    |  IP_Firewall  |
   |                |    Gateway    |
   |                |               |
   |                V               V
   V           192.168.1.1         Dynamic or
 192.168.1.x   LAN Gateway         Static IP
LAN Addresses  IP Address          from ISP pool
                                   

 
   

What I did is setup a Linux router (Redhat Linux 5.0 on a i486) with two ethernet interfaces. One interface routes to the ISP subnet/gateway (eth0 in above example), and the other interface (eth1 above) goes to a hub (or switch) and then connects the LAN with private network addresses (e.g. 192.168.1.x). Using the private network addresses behind your router/firewall allows some additional security because it is not directly addressable from outside. You have to explicitly masquerade your private addresses in order to connect to the Internet from the LAN. The LAN hosts will access the Internet via the second NIC (eth1) in the Linux router. Just set their gateway to the IP address of the second NIC, and assign them addresses on the same network.

Caution Make sure your kernel is complied with IP forwarding and the IP forwarding is turned on. You can check this with 'cat /proc/sys/net/ipv4/ip_forward'. The value is "1" for on, and "0" for off. You can change this value by echoing the desired value into this file:

 # echo 1 > /proc/sys/net/ipv4/ip_forward
 
 

You will also need to set up "IP Masquerading" on the Linux router. Depending on your kernel version, this is done with ipfwadm (2.0), ipchains (2.2), or iptables (2.4). See the documentation for specifics on each. AND -- do not forget to have that firewall set up too!

There are also several projects that are devoted specifically to using Linux as a router, just for this type of situation. These are all-in-one solutions, that include security and various other features. Installation and configuration, is reportedly very easy. And these will run on very minimal hardware -- like a floppy drive only. The best known is http://www.linuxrouter.org. You might also want to look at http://www.freesco.org and http://www.coyotelinux.com. There is also http://www.clarkconnect.org/index.html, which is a similar concept but more full-featured and is designed to be monitored and configured with a set of Windows based utilities.