DSL, or Digital Subscriber Loop, is a high-speed Internet access technology that uses a standard copper telephone line (a.k.a. "loop" in telco parlance). DSL provides a direct, dedicated connection to an ISP via the existing telco network. DSL is designed to run on up to 80% of the telephone lines available in the United States. By using line-adaptive modulation, DSL is capable of providing data speeds of 8 Mbps or more.
DSL services are now being aggressively marketed for home and small business use. DSL is typically priced below ISDN, and well below T1 service, yet can provide potentially even greater speeds than T1 without the cost, complexity, and availability issues of T1. Since DSL is a dedicated, often "always on" service, it avoids the delays and use charges that are common with ISDN. Making this quite a nice technology for the bandwidth starved masses.
While all this sounds exciting, DSL does have some drawbacks. The quality of the DSL signal, and thus the connection, depends on distance (the length of the copper "loop") and various other factors. Also, there is no such thing as standard "DSL". There are various flavors of DSL, and many, many ways DSL providers are implementing their networks. In typical fashion, Linux users are often left to fend for themselves, since the DSL providers are often taking the easy way out, and catering only to "mainstream" Operating Systems.
The topics included in this HOWTO include qualification and pre-installation, installation, configuration, troubleshooting and securing a DSL connection. As well as other related topics. There are also appendices including a comprehensive DSL Overview, Frequently Asked Questions, a listing of related links, and a glossary.
Due to the fast pace of change in the telco and DSL industries, please make sure you have the latest version of this document. The current official version can always be found at http://www.tldp.org/HOWTO/DSL-HOWTO/. Pre-release versions can be found at http://feenix.burgiss.net/ldp/adsl/.
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:
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) ;-).
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.
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 at GNU GPL.
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.
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!
Any and all comments on this document are most welcomed. Please make sure you have the most current version before submitting corrections! These can be sent to <email@example.com>
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.
Before actually ordering service, there are several things you may want to explore. Please note, that there are many ways any given telco might decide to handle qualification and installation procedures. Much of what is described in this section, is how it is commonly done in the U.S.
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:
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.
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.
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.
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.
The optimum method of wiring for the DSL modem is sometimes called a "homerun". It is called this because it is one, straight shot from the splitter to the modem's DSL jack. What this does is bypass the existing inside wiring altogether, and any problems that might be lurking there -- like a corroded connection somewhere on a voice jack. Inside wiring deficiencies can cause a degradation of the DSL signal.
This also allows you to route the cable to avoid any potential RFI (Radio Frequency Interference) sources. RFI anywhere in the circuit can be a DSL killer. Routing the cable away from items that may have electric motors, transformers, power supplies, high intensity lighting fixtures, dimmer switches and such, is a smart way to go. And you are also less likely to have a failing microfilter cause problems -- one potential point of failure instead of several. You can also use a better grade of cable such as CAT 5.
If your existing installation is "splitterless" (i.e. using microfilters) now, converting to a homerun will entail purchasing a splitter. And, of course, will also mean some new wiring will need to be run. Microfilters also add to the effective loop length -- as much as 700 ft per filter in some cases! So if you have several microfilters installed, and your sync rate or distance is marginal, eliminating these filters may result in a significant improvement.
A poor man's splitter can be rigged by using a microfilter inside the NID. This is not "by the book", but seems to work just fine for many.
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.)
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.
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.
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.
Ethernet modems will, of course, require an ethernet network card. If you haven't already done so, install the NIC in your Linux machine, configure the kernel, or load modules, etc., etc. This is sometimes the biggest stumbling block -- getting the NIC recognized and working. See the various Linux references for doing this, such as the Ethernet HOWTO for more information. Also, see the Troubleshooting Section below. This is certainly something you could conceivably do ahead of time if you already have the NIC.
Be sure the RJ45 cable between the NIC and the modem is now connected. You can "hot plug" this cable, meaning there is no need to power down to do this.
We can do a few quick tests now to see if the NIC seems to be functioning properly. First we'll attempt to bring up the interface. Then we'll see how well it is responding by pinging it. And lastly use ifconfig to check for errors:
If "eth0" comes up without errors, and you can ping it without errors, and ifconfig shows no errors, we most likely have all our hardware in working order now, and are ready to start configuring Linux. If not, see the Troubleshooting section below.
Gotcha: A few modems may already be wired as a 10baseT crossover, and require a direct Category 5 cable for a direct connection to a NIC, rather than a crossover cable. I lost around 12 hours figuring this one out, so don't make the same mistake - make sure you RTFM first.
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/.
After you have connected the modem and it's getting sync, then you're ready to configure Linux and verify your connection to your ISP. Although I will refer to a Linux System, you could conceivably connect any type of 10baseT device to the modem. This includes a router, hub, switch, PC, or any other system that you wish to use. We'll just cover the Linux aspects here.
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.
In the good old days of a year or two ago, purely "Bridged" connections were the norm. PPPoE had not been invented yet. This type of network puts you on a local subnet just like a big LAN. You are exposed to much of the local subnet traffic, especially ARP and broadcast traffic. The typical means of authenticating in this set up, is via DHCP.
DHCP is a standard, established networking protocol for obtaining an IP address and other important network parameters (e.g. nameservers). This is a standard, well documented networking scheme and is very easy to set up from the end user's perspective. It is also a very stable connection. You can actually unplug the modem for say 10 minutes, plug it back in, let it re-sync, and the connection is still there -- same IP and everything.
The main alternative now is PPPoX, meaning either PPPoE (PPP over Ethernet) or PPPoA (PPP over ATM, aka PPPoATM). Both of these related protocols are currently being deployed, but at the moment, PPPoE seems to be the more common of the two. PPPoX is a relative newcomer, and, as the name implies, is a variation of Point-to-Point Protocol that has been adapted specifically for DSL networks.
There are several PPPoE clients for Linux (see below). PPPoX simulates a dialup type environment. The user is authenticated by user id and password which is passed to a RADIUS server, just like good ol' dialup PPP. A routable IP address, and other related information, is returned to the client. Of course, no actual dialing takes place. The mechanics of how this is handled, will vary from client to client, so best to RTFM closely. Typically you will set up configuration files like pap-secrets, etc.
It is worth noting that PPPoE will also work on non-ethernet devices like USB, provided the correct drivers are installed.
From the ISPs perspective, PPP is much easier to maintain and troubleshoot. From the end user's perspective, it is often more work to set up, often uses more CPU, and the connection is maybe not as stable. So anyway, this seems to be the coming trend. Many of the large telcos around the world, especially the RBOCs (Baby Bells) in the U.S., have committed to PPPoX already. Setting up a PPPoX connection is completely different from setting up a bridged/DHCP connection.
Since the traffic on the wire from the DSLAM to the modem is typically ATM, a raw ATM connection would seem to make sense. While possible, this is rare, if it exists at all in the U.S, and would require a modem in addition to a PCI ATM card, such as the Efficient Networks 3010. Recent 2.4 kernels do have ATM support. (See the Links section for more information.)
This may be a viable solution at some point, but it is just not "there" yet, mostly because this is more costly to implement.
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:
Let's look at these individually.
A "static" IP address is an IP that is guaranteed not to change. This is the preferred way to go for those wanting to host a domain or run some type of public server, but is not available from all ISPs. Note that while there are some noteworthy benefits to having a static IP, the disadvantage is that is more difficult to remain "invisible". It is harder to hide from those with malicious intentions. Skip this section if you do not have a static IP, or if you have a router, and the router will be assigned the static IP.
Configure the IP address, subnet mask, default gateway, and DNS server information as provided by the ISP. Each Linux Distribution (Redhat, Debian, Slackware, SuSE, etc.) has a different way of doing this, so check on your distro's docs on this. Each may have their own tools for this. Redhat has netcfg for example. You can also do this manually using the ifconfig and route commands. See the man pages on these or the Net HOWTO for more information and specifics. A quick command line example with bogus IPs:
Be sure to add the correct nameservers in /etc/resolv.conf.
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.
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:
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:
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'.
PPPoA (PPPoATM, or PPP over ATM) is a cleaner solution than PPPoE since most of the work is done in hardware, and since the raw DSL traffic is ATM. There is no user space client necessary to manage the connection as with PPPoE, and the additional ethernet protocol layer is not required. Authentication is still the same: user id and password to connect, but the mechanics are different since no ethernet encapsulation takes place.
PPPoA is either done completely in hardware or is implemented as a device specific driver. There is no such thing as a generic PPPoA software client like there is for PPPoE. There is an ATM patch for 2.2 kernels, support for ATM in the 2.4.x kernel, and a project based on the Efficient Networks 3010, as well as other ATM cards. The ATM on Linux homepage is here: http://linux-atm.sourceforge.net/. And even more info is at http://www.sfgoth.com/~mitch/linux/atm/pppoatm/ from the kernel developer of this project. Existing PPPoA implementations are hardware/driver based, and Linux PPPoA modem drivers are scarce as hen's teeth at this time. The above modem does not seem to be available through normal retail channels. This may be a problem, if this is the only protocol an ISP delivers, and an external modem that supports PPPoA is not available.
If PPPoA is your ISP's only option, you might consider one of the router/modems that can handle PPPoA connections, and let the hardware handle everything.
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:
Once everything is configured properly, it should be just a matter of starting pptp, pointing it to the modem's address:
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.
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.
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.
This section is intended for those who have not previously dealt with the security implications of having a full-time Internet connection. Or may not understand some of the basic concepts of security. This is meant to be just a quick overview, not a comprehensive examination of all the issues! Just enough to give you a gentle shove in the right direction. Please see the Links section for sites with more details. Also, your distribution surely has plenty of good information as well.
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:
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.
For many of us, a default Linux installation is going to give something close to optimum performance. Windows 9x users often get a big boost by increasing their TCP Receive Window (RWIN). But this is because it is too small to start with. This is just not the case with Linux where the default value is 32KB.
The exception here is if you have to routinely deal with a high latency connection. For instance, if your provider has a satellite uplink that is consistently adding unusual latency (250ms or greater?). Then a larger TCP Window will likely help. For more on TCP Receive Window and related issues, look at http://www.psc.edu/networking/perf_tune.html.
The Receive Window is a buffer that helps control the flow of data. If set too low, it can be a bottleneck and restrict throughput. The optimum value for this depends completely on your bandwidth and latency. Latency being what you would find as average roundtrip time (RTT) based on your typical destinations and conditions. This can be determined with ping. For example, the Linux default of 32KB is acceptable up to speeds of 2 Mbps and a typical latency of 125ms or so, or 1.0 Mbps and latency of 250ms. Setting this value too high can also adversely effect throughput, so don't over do it.
An example courtesy of Juha Saarinen of New Zealand:
The Receive Window can be dynamically set in the /proc filesystem. This requires entering a value that is twice the desired buffer size:
The above example actually sets the value to 128K. The Send Window can also be set, but is not as likely to be a limiting factor on DSL connections as the Receive Window:
These values can also be set using the sysctl command. See the man page.
Other suggested kernel options for those who want to squeeze every last bit out of that copper (selected entries only):
A brief description of these, and other, options may be found in /usr/src/linux/Documentation/networking/ip-sysctl.txt, in the kernel source directory.
"Interleaving" is an error control mechanism of ADSL with DMT line encoding. DMT is now the standard for ADSL, and is by far and away the most prevalent form of ADSL. Interleaving buffers the raw data and corrects errors on the fly at the DSLAM. This can significantly help marginal loops that may be prone to line errors. The downside is that this buffering also adds significant latency to the connection. So for those with reasonable quality lines, interleaving is of no real benefit, and may actually add unnecessary latency.
Interleaving is an adjustable parameter and can be turned on or off by the telco. Many telcos seem to like to have this on by default, since it probably reduces tech support calls in those cases where it does help stabilize a line. But everyone else pays a price.
How to know if your line is interleaved or not, and how to change it? Good question. Generally speaking, if your first hop or two on a traceroute is less than 25ms or so, you can pretty much figure that interleaving is off. But there may be other factors such as how far away those hops actually are. Unless your modem accurately reports this, the only other real way to know is to talk to someone at the telco. This may prove easier said than done.
"FastPath" DMT is synonymous with "interleaving off". Again, this only applies to ADSL/DMT.
DSL connections may suffer performance degradations under certain circumstances. Thankfully, Linux has very robust and flexible networking tools to help us deal with these.
One such common situation is where traffic bottlenecks are created whenever data from a fast network segment hits a slower one. Such as ethernet hitting a DSL modem/router. This can cause short term traffic backlogs, known as "queues" in the device. Queuing can result in degraded performance, particularly for interactive protocols (like telnet or ssh) and streaming protocols (like RealAudio), and increased latency for ICMP and other network protocols. This is most evident when the upstream link is saturated (since downstream data is queued at the ISP's end and we can't do as much about that). The queued traffic is processed such that lower volume traffic protocols (like ssh) often get drowned out so to speak, by the higher volume, bulk traffic (like http or ftp), as there isn't any special prioritizing in default usage.
And if the upstream queuing, or other factors, causes enough of a delay, it can even decrease downstream bandwidth utilization by slowing the ACKnowledgements (which are heading upstream), that are required to keep a download moving at optimal rates. So it is possible that an upload can hurt a simultaneous download.
Such effects can be largely mitigated with Linux's built-in traffic shaping abilities. The user space tool for manipulating the kernel's advanced traffic routing features is iproute, sometimes packaged as iproute2. This includes various tools that can classify and prioritize traffic with a considerable degree of flexibility. It also requires various kernel config options to be turned on. And is also fairly close to Black Magic ;-) The definitive document on this is the Advanced Routing and Traffic Control HOWTO (http://tldp.org/HOWTO/Adv-Routing-HOWTO.html). Pay particular attention to the "Cookbook" Section #15, and in particular #15.8, "The Ultimate Traffic Conditioner: Low Latency, Fast Up & Downloads". A great read!
PPPoE and PPPoA both rely on the venerable PPP protocol. This protocol incorporates the Link Control Protocol (LCP), which is used to maintain the viability of the connection. Each end can send LCP echoes to other end, and if there is no response in the alloted time frame, the session is presumed dead, and is torn down. Again, either end can initiate this process. The client should then negotiate a new connection. But, this normally means a new IP address is assigned along with the new session.
Perhaps this is undesirable? While you certainly can't control what happens on the remote end in this regard, you can adjust PPP's very flexible way of dealing with LCP echoes on your end, to increase the number of echoes, extend the interval and timeout period on your end. This might help prolong the life of an unstable connection in situations with marginal line conditions, or a buggy peer on the other end. Read your client's documentation. YMMV.
Some providers may deliberately enforce some time limit. There is not much you can do about this.
Also, frequently dropped connections are often an indication of a line problem of some kind. This is something the telco should investigate.
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.)
The modem sync LED has never been green.
Symptoms here are: NIC is not recognized, modules won't load, or ifconfig shows the interface is not up, or is generating lots of errors, etc.
Read this section if you are sure the modem is syncing, the NIC is recognized and seems to be working properly, client software is installed and running without error, but the connection to the ISP fails. Verify the modem is indeed syncing by the LED(s). An IP connection failure may be evidenced by ifconfig not showing an active eth0 interface (or ppp0 for PPPoX), or pinging gateway and other destinations generates 'network unreachable' or similar errors.
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:
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.
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.
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:
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:
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!):
And a problem with the same gateway on a different day:
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.
Some odds and ends:
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:
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.
DSL is a telephone loop technology that uses existing copper phones lines, and provides a dedicated, high speed Internet connection. One of the big advantages of some DSLs (notably ADSL), are that they can co-exist on the same line with a traditional voice service such as "POTS" (Plain Old Telephone Service), and even ISDN. This is accomplished by utilizing different frequency ranges above the voice range (voice is up to 4KHz). Essentially, this gives two lines in one: one for voice, and one for Internet connectivity. When all is working normally, there should be no interference between the two "lines". This gives DSL a potentially broad consumer base, and helps minimize costs for service providers.
DSL is positioned for the Home and Small Office (SOHO) market that is looking for high speed Internet access at reasonable prices. Since it also typically provides dedicated, "always on" access, it can be used for interconnecting low to mid range bandwidth servers, and provides a great access solution for small LANs. It is also great for those Linux power users that just want a fat pipe :-).
Phone companies, and other independent telecommunications providers (CLECs), are now deploying DSL to stay ahead of the Cable companies -- the main consumer and SOHO competition for DSL providers. This mad rush to get "a piece of the pie", is bringing much competition (a good thing!), much diversity, and some confusion, into the consumer market. The DSL provider (often, but not always, the phone company) will provide the DSL infrastructure. This would include your line, the DSLAM, and physical connection to the outside world. From there it is typically picked up by an ISP, who provides the traditional Internet services.
Consumer DSL plans are typically "best effort" services. While boasting speeds approaching T1, and even surpassing that in some cases, it is not necessarily as reliable as T1 however. Business class DSL offers more reliability at a higher cost than consumer plans, and is a good compromise where both reliability and bandwidth are at a premium. All in all, the cost of DSL compared to traditional telco services, such as T1, is attractive and substantially more affordable for home and small business users.
DSL providers often do not have service contracts for home users, while business class DSL services typically do include similar SLAs (Service Level Agreements) to that offered for a T1 line.
The downside is that DSL is not available everywhere. Availability, and available bit rate (speed), are purely a function of where you live, where the telco has installed the prerequisite hardware, how far you are from the DSLAM/CO, and the quality of your phone line (loop). Not all loops are created equal, unfortunately. The primary limitation is distance.
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).
A good, working connection to the DSLAM is referred to as "syncing". This is typically indicated by LEDs on the modem. Without sync, nothing happens. The modem will establish a sync rate which is often throttled by the provider at a predefined limit. This limit, or "cap", is at the provider's discretion and is part of the service that is being provided. Your modem may well sync at a higher rate than the "cap", but your speed will be limited to whatever "cap" the provider is enforcing. So while ADSL has an upward theoretical limit of 8 Mbps, you will not see that speed -- unless of course your provider is selling an 8 Mbps plan. Most plans are well below this.
Below is the status information from a SpeedStream 5660 modem/router via the built-in telnet interface. In this example, the customer is on a 1.5 Mbps/384 Kbps service:
First notice the "Current Attainable Rate" in the "ATU-C" column. This is the downstream sync rate negotiated by the modem and DSLAM, which is over 3.5 Mbps. The actual speed is limited, however, to 1.5 Mbps/384 Kbps from the first row "TX Rate". This is the theoretical limit of this connection. This limit, or "cap", can be enforced at the DSLAM, as is the case the here, or further upstream. Had the first row "TX Rate" been lower than the provider's imposed limit, then this would indicate some kind of problem with the connection, perhaps due to distance or some kind of line impairment.
The attainable sync rate is the result of a number of factors, including wire distance to the DSLAM, quality of both inside and outside wiring, the loop wire gauge and various other factors within the loop. Actual measurable, real world throughput, on the other hand, is first of all dependent on sync rate. Low sync rate means low throughput. In the above example, had the sync rate been lower, say 500 Kbps, then that would be the maximum for that connection, even though the customer is paying for a 1.5 Mbps service.
Secondarily, throughput will depend also on the ISP's network, and then the ISP's upstream provider. You will lose approximately 10-20% of potential throughput to networking overhead. In the above example where the connection is throttled at 1.5 Mbps, the actual, real-world maximum throughput would be somewhere around 1.2-1.3 Mbps when overhead is taken into account. Moreover, once you hit the Internet proper, all bets are off as there are any number of factors that may impact throughput. A overloaded or busy server is likely to be slow no matter how fast your DSL connection is.
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.
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.
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.
Before ordering service, check to see what providers there are in your area. Look for options on both the telco/DSL side and the ISP side. You may have several options, including the large phone companies, as well as smaller, local ISPs. Once an order is placed, you must wait for the qualification process before a provider will agree to provide service.
Once local availability is established, the next step is "qualifying" your loop. The provider will run various tests to make sure that your loop can handle the DSL signal. This is to determine how suitable your line is for DSL, and maybe what level of service will be available to you. You probably will have to order service just to find out this much. It can be a fairly involved process, with a variety of different tests being run. There are a number of things that may "disqualify" a line. The most common limitation is distance.
All DSLs have distance limitations. ADSL is limited to a loop length of roughly 18,000 ft (5.5 km), but the actual cut off point will vary from provider to provider. The further away you are, the weaker the signal, and the potential for poor connections is greater. With ADSL, if you are within approximately 12,000 ft (3.7 km), you should be able to get at least 1.5 Mbps -- all other things being equal. IDSL has even greater reach, mainly because the maximum speed for IDSL is considerably lower at 144 Kbps/144 Kbps.
Still even if you're close enough, there are a number of potential impediments that may disqualify a line. Two such common impediments are load coils and bridge taps. These are aspects of the old telco infrastructure that once were deemed beneficial, but now are getting in the way of the newer, digital technologies. Whether you hit a snag like this or not, is pretty much hit or miss. Fiber anywhere in the loop is also a disqualifier. The provider may take steps to "clean" the line. Just how far they are willing to go will vary from provider to provider, and this will likely add additional time to the installation process.
Once the line is "qualified", the next step is deciding on which plan is suitable for your situation. The provider may have differing plans available depending on how strong a signal they think your line can handle. If you are marginal, you will not be qualified for the higher speed plans. And if price is a factor, having a tiered pricing structure is good also since the lower end plans are obviously less expensive. How this is structured also varies wildly from provider to provider. Since, DSL is a new service, and providers are trying to find the right price/feature combinations that will attract the most users and thus gain a competitive edge.
Some common data rates:
and a near infinite number of other possibilities. The cost of different plans generally goes up with their speed.
Should you be disqualified, and have other options, get a second opinion. Calculating the effective loop length is by no means an exact science. There is plenty of room for errors. Also, some providers may go to greater lengths to "clean" the loop than others. And, if you have more than one phone line, and are disqualified, then try the other line. Just because they both terminate at your location, does not necessarily mean they are the same length! The telco network is full of surprises.
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.
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.
Some Frequently Asked Questions about DSL and Linux.
This is but a very small sampling and should not be construed as endorsements of the products listed. It is just a simple illustration of a few of the available products.
A dictionary of some of the jargon used in this Document, and in the telco and DSL industries.
The Telcos see DSL as a competitor to the Cable Company's Cable Modem, and as such, are providing competitive pricing and configuration offerings. Although Cable Modems are advertised as having 10-30Mbps potential bandwidth, they use a shared transmission medium with many other users on the same line, and therefore performance may vary, sometimes greatly, with the amount of traffic, time of day, and number of other users on the same node. But YMMV.
It is often heard that DSL has an advantage in that it is a private pipe to the Internet, with dedicated bandwidth. This is mostly a myth. You do have a private pipe to the DSLAM, but at that point, you enter the telco's ATM (or frame relay) network, and start sharing bandwidth. You are at the mercy of how well your DSL provider and ISP manage their networks. The consensus seems to be that DSL providers and ISPs are mostly doing a better job of managing bandwidth than the Cable companies. It is easier for them to add and adjust bandwidth as needed to meet demand. You are less likely to have speed fluctuations due to other users being on line at the same time. But, again, this gets down to how well the specific network and bandwidth are managed.
DSL probably has a small security advantage too. With most Cable modem networks, it is like being on a big LAN. You are sharing your connection (and bandwidth) right at the point of connection. But if you are not doing something to filter incoming connections already, you are asking for trouble either way. And, the cable companies are addressing this now, with more secure approaches. This should not now be a major deciding factor.
There also seems to be a better chance of having ISP alternatives with DSL than Cable. At least, in the U.S. this is true. Choice is a good thing, and so is competition. It seems most Cable outfits give you just one choice for an ISP. If you don't like it, you are out of luck. The number of options with DSL probably varies greatly by geographic areas. Populous areas, like Northeast U.S., seem to have many options.
So which is better? The differences aren't as much with the technology, as they are with the implementations. If you look around, you can find plenty of horror stories on either. And plenty of happy customers too. The way to know what may be the best for you, is to do comparative shopping based on experiences of other users in your area. Don't base your choice on one person's opinion. This is statistically invalid. Likewise, don't base your choice on someone's opinion who has had a particular service for only a short time. Again, statistically not worth much. Get as many opinions from those that are using the exact same services that you are looking at.
In some areas, newer neighborhoods are being built with fiber optic cable instead of the traditional telco copper lines. While the fiber is a definite problem for DSL services, it has it's own potential advantages. Existing fiber is potentially capable of 100 Mbps, and it looks like this could easily go up soon.
So while telco fiber customers are being shut out of the DSL market (since DSL is a copper only technology), they may have much to look forward to. Technologies are under development, and in some cases just now being deployed, to take advantage of fiber telco phone loops. Known as "FTTC" (Fiber To The Curb), or "IFITL" (Integrated Fiber In The Loop), this technology is another high speed service that telcos can offer. The speeds are sufficient for VoD (Video on Demand) and VoDSL (Voice over DSL), and other high bandwidth services. One nice advantage here is, that since there is no DSL signal on the wire, the only required CPE is a network card. In other words, no modem -- just connect a NIC to the wall jack and off you go! This will also allow the telco to provide other digital services such digital TV.
FTTC is Fiber To The Curb. The last leg into the house is still copper. FTTH (Fiber To The Home), on the other hand, is an all fiber loop with even higher potential.
There is a lot of buzz about wireless technologies these days. Wireless would certainly seem to have a place in the broadband market, especially for areas that don't have ready access to cable or telco networks. There are still some inherent problems with the current state of this technology that may prevent it from becoming a major player in the near term however. Weather can still impact the wireless signal -- heavy cloud cover or rain for instance. Also, there is some pretty hefty latency if the uplink is via satellite. Surely these drawbacks will improve over time. But how soon?
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.
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.
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:
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.
The Alcatel SpeedTouch USB modem is one of a very few non-ethernet modems with Linux drivers. This modem is quite popular in Europe (Alcatel's home turf), and is widely used elsewhere as well. Hats off to Alcatel!
For this to work, you will essentially need three things: the Alcatel modem firmware and management utility (supplied directly by Alcatel in closed source, binary form), a properly configured kernel and PPP daemon, and the Linux modem driver and related configuration. The modem driver itself is open source. There are currently two distinct, unrelated drivers available.
When drivers were first released, the installation process required a fair amount of patching and rebuilding to make things work. Since then, things have progressed, and it can now be done without any patching (see below). How well all the pieces go together may depend on how old your Linux installation is, the kernel and PPP versions, and possibly what patches your vendor may have applied to their own packages. Recent Linux releases probably have most, if not all, of this already done, and hence you may not need to do any patching. I believe this is true of recent SuSE, Mandrake, and Debian (and probably others as well). You still need the Alcatel binary firmware, and a driver for the modem (if your distro does not include this). I would suggest checking your distro's web site, and search their archives for documents relating to this modem, and go from there as a first step. YMMV.
One obvious requirement is a kernel with USB support. USB and ATM support are better in recent kernels, and I would suggest if not using a very current Linux distribution, then at least get a recent kernel. And a quick note on kernels and patching: if using the kernel source supplied with a Linux distribution, it is most likely very heavily patched already. Applying patches to these can be hit or miss.
As always with Linux, there is more than one way to skin a cat. This is true of this modem and is resulting in some confusion since there are various documents circulating on this modem with various approaches taken. Some are more current than others too. Keep this in mind if you run into conflicting recommendations. Again, your distribution is probably the best source of documents.
There are two separate driver projects for this modem. The installation and configuration are completely different, as is the code base. Both are open source and GPL. One is a kernel module solution, originally developed by Alcatel, and now maintained by Johan Verrept. His HOWTO is located at http://linux-usb.sourceforge.net/SpeedTouch/howto.html. I think most would agree that the installation of this driver is the more complex of the two, and more than likely will require some patching (unless your distro has already done this). But, it may have some slight performance benefits since it runs mostly in kernel space. This driver can potentially support both PPPoE and PPPoA connections.
The other driver is by Benoit Papillault and friends. This one has a less complicated installation, and can be done with no patching. All the important parts here are done in user space. For inexperienced users, or just plain ease of use, this may well be the most painless way to go. The home page is http://sourceforge.net/projects/speedtouch and related docs are http://speedtouch.sourceforge.net/docs.php. This driver can also work with 2.2 kernels (2.2.17 or later). PPPoE is not an option with this driver at this time. This driver also does not use the management utility that is part of the Alcatel supplied binary package. It extracts the modem firmware, and then does its own "management", so less dependent on proprietary code. Mandrake is reportedly including an RPM of this driver now.
Since this modem potentially supports both PPPoE and PPPoATM connections, which one is better? Which ever is supported by your ISP, and then which ever works best for you! If your ISP supports both (some do and some don't), you might try each approach and make your own decision. There is no absolute right or wrong on such things. There are just too many variables. Theoretically at least, PPPoA should utilize a little less overhead and system resources.
There are other USB modems on the market that use an Alcatel chipset, such as the Efficient Networks 4060. Do not expect either of these drivers to work with other modems. They won't. You should get a compatible ethernet modem in such situations. There are other USB modems with Linux drivers also. See http://eciadsl.sourceforge.net/.