v1.71, 2002-07-21
Revision History | ||
---|---|---|
Revision v1.71 | 2002-07-21 | Revised by: hb |
Add another supported modem only. | ||
Revision v1.7 | 2002-07-14 | Revised by: hb |
More small updates. | ||
Revision v1.6 | 2002-05-23 | Revised by: hb |
Various small updates. | ||
Revision v0.92 | 1999-04-10 | Revised by: df |
First release (ADSL mini HOWTO). |
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/.
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.71: Add info on the IteX PCI ADSL modem only.
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)
B Ediger (Xbediger@csn.net) Great Description of loop impairment.
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.
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.
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>
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.
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.
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.
" I would not use microfilters if I lived across the street from my CO. A splitter is the only way to go. " | ||
--A retired BellSouth ADSL installer |
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.
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:
# 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 |
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.
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/.
![]() | Before you connect to your ISP, make sure you understand all security issues of having a direct connection to the Internet via DSL. Depending on your ISP, most outside users can access your system, and you should setup any firewalls, deactivate ports/services, and setup any passwords prior to connecting your machine to the world. See the Security section below, and the links section for more on this very important topic. Do not make this an afterthought! Be ready. |
There are a few provider specific FAQs and HOWTOs in the Links section below.
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:
Static IP.
Dynamic IP on Bridged Network via DHCP.
Dynamic IP via PPPoX.
Static IP via PPPoX.
Let's look at these individually.
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:
# ifconfig eth0 111.222.333.444 up netmask 255.255.255.0 # route add default gw 111.222.333.1 dev eth0 |
Be sure to add the correct nameservers in /etc/resolv.conf.
![]() | 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. |
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'.
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:
/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. |
# ifconfig eth0 10.0.0.2 up netmask 255.0.0.0 # route add -net 10.0.0.0 $ ping 10.0.0.1 |
![]() | 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. |
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.
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
Additional references are in the Links Section below.
0-12 K ft �(0-3.6 km)��� | ������2000 Kbps or more (8100 max for ADSL) |
12-16 K ft (3.6-4.6 km)��� | ������1500 Kbps to 1000 Kbps |
16-18 K ft (4.6-5.4 km)��� | ������1200 Kbps to 512 Kbps |
18-?? K ft (5.4-?? km)��� | ������512 Kbps to �128 Kbps or less :( |
But there are a few things that you might want to look at.
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 commonly used formula for working out the the tcp buffer is the "bandwidth delay product" one:
������Buffer size = Bandwidth (bits/s) * RTT (seconds)
In my case, I have roughly 8Mbps downstream, but the ATM network can only support ~3.5Mbps sustained. I'm far away from the rest of the world, so to squeeze in a sufficient amount of 1,500 byte packets, with average RTTs of 250ms, I should probably have a buffer of (3,500,000/8)*.25 = 106KB. (I've got 128KB at the moment, which works fine.)
The Receive Window can be dynamically set in the /proc filesystem. This requires entering a value that is twice the desired buffer size:
#echo 262144 > /proc/sys/net/core/rmem_default #echo 262144 > /proc/sys/net/core/rmem_max |
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:
#echo 262144 > /proc/sys/net/core/wmem_default #echo 262144 > /proc/sys/net/core/wmem_max |
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):
# 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 |
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.
"FastPath" DMT is synonymous with "interleaving off". Again, this only applies to ADSL/DMT.
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!
Check the manufacturer's web site for Linux documentation. Or look at Donald Becker's informative site at http://www.scyld.com/network/.
Some Linux NIC drivers reportedly work better as non-modular. In other words, compile them into the kernel instead of as a module.
It is also possible that the card is bad, or the drivers just aren't up to snuff. Try another card. And you don't need an expensive, high quality card necessarily either.
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.
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.
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.
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).
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-> |
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. |
Some Frequently Asked Questions about DSL and Linux.
Q. Where can I find drivers for my PCI (or USB) modem?
The are exceptions to every rule. See the Modems Section for a list of compatible modems as of this writing.
If an incompatible modem puts you in a bind, hopefully you will take the time to politely harass the manufacturer ;-).
This situation is changing for the better. Xpeed now has drivers included in the kernel for source for their PCI IDSL and SDSL modems. This is good news! Alcatel has released drivers for the Alcatel SpeedTouch USB ADSL modem. IteX has also released drivers for their PCI ADSL modem. Hopefully more will follow suit. (Make sure you are reading the latest version of this document, as I have intentions of keeping this situation updated as needed.)
Q. How fast or good of a network card do I need?
Any card that is compatible with Linux should work fine. Remember even low-end cards are 10 Mbps, and no consumer class DSL is near that at this time. I would suggest a reasonably good quality card, just to help eliminate the possibility of errors and premature failure.
Q. How can I find out when DSL will be available in my area?
Just where and when DSL gets deployed is totally in the hands of your friendly local telco. They obviously can't do everyone at once, so they probably are selecting areas based on competitive factors. Getting a straight answer from a telco on this question can also be a challenge. Probably so as not to tip their hand to competitors. Unfortunately, it is a question only they can answer.
Q. I was disqualified because I am too far away. What can I do?
Move? Seriously, there isn't much you can do. If there are other providers, get another opinion. You never know. Determining the loop length is an inexact science, and there is room for errors. Many use databases for this, and these databases routinely have some inaccuracies. Some providers too, may be more aggressive in taking steps to help you out and clean up the line. Also, some providers offer low-end speed services that have greater reach. Maybe this will become available in your area. Or, the telco may install, at some point, remote devices for customers who are now too far away.
Q. I am told I am 20,000 ft from the CO. Isn't that too far? Will my speeds be really bad?
Not necessarily. This distance limitation is not where the CO is, but where the DSLAM is. These are often installed in CO's, but more and more are being installed in remote locations in order to expand the reach of DSL service.
Q. What are the speed tweaks for Linux?
This may not be necessary. Linux is pre-tweaked for the most part, unlike some versions of Windows that really need some registry hacks to get optimum performance. If you have a high latency connection, you may benefit from increasing the TCP Receive Window. See the Tuning section.
Now if you are convinced you are not getting the performance you should based on your distance and line conditions, then there might be a problem somewhere. See the Troubleshooting section for more. What you may need is a fix, more than a tweak.
Q. My service is limited to 640K (for example). Can I get better speed by getting a faster modem? Any way around this?
No, and no. The modem has little bearing on how fast your connection is for all intents and purposes. The provider has a mechanism in place for limiting your speed somewhere in the pipe before you hit the Internet. There is no way to defeat this.
Q. Can I download and upload at the same time? Is one effected by the other?
The upstream and downstream channels use separate frequency ranges within the DSL signal, so simultaneous upload/download is not a problem and available bandwidth is not normally impacted.
Where there may be somewhat of an adverse impact, is with asymmetric DSLs like ADSL, and both the upstream and downstream are simultaneously saturated. This is a TCP 'feature' and not DSL related though. This can adversely effect the faster stream (i.e. the downstream). How much of an impact depends on a slew of factors and is beyond the scope of this document, but is more pronounced with higher ratios of downstream to upstream (e.g. 640/90). See the Tuning on how to mitigate this effect.
Q. I am paying for 768 Kbps service, and the best I ever get is 640 Kbps or so. Why? Is the service oversold? I am not getting what I pay for.
You will lose 10-20% of the rated capacity due to the overhead inherent in the various protocols utilized. Most of us will probably fall closer to 20%. This is just a fact of life for everybody. Just how much is lost here depends on various factors. You seem to be close to your maximum when this is taken into consideration. Also, if you read the fine print, many ISPs are advertising speeds "up to" such and such. Check your service agreement and see if there are any guarantees. If there are, they may be well below the advertised maximum speed, and may be based on sync rate instead of actual throughput. Though this may vary from provider to provider as well.
Also, be careful how you test this. Some of the so-called test sites can be pretty unreliable. There can be many factors between you and that site that can impact your throughput and skew results -- not the least of which is how many people might be trying that same test at the same time. The best test is via FTP download from a known good, close, not too busy site.
Q. Can DSL work with ISDN, and how is this different?
Yes, there have been DSL capable modems and service providers for some time. In fact, this is common in parts of Europe. So this is not an issue.
What makes ISDN different is the underlying signal on the line is fundamentally different than a POTS line. This means that any physical layer hardware has to be compatible with ISDN (and conversely it is incompatible with POTS lines). So this means the NT (modem), filters, etc, all have to be designed for ISDN. Other than these low level issues, the other aspects of DSL implementation are the same (e.g. network protocols).
Q. Why does PPPoX have such a bad rap?
The occasional disconnects is one of the biggest gripes. PPP seems to be sensitive to any interruptions in the connection. Generally a disconnect means a new IP. And there are those that say PPP, by its very nature, was never meant to be an "always on" protocol. PPP is a session management protocol at heart, that requires a user to initiate a connection and authenticate him or herself. PPPoE/A are not yet particularly mature protocols either. They do not have much of a history or track record. Some would say the telcos and hardware manufacturers have rushed this out the door. PPPoE also requires an additional layer of software just to maintain the connection. This is one more layer of code and one more potential point of failure. Also, more system overhead is utilized to manage the connection.
The impact of the disconnect problem can potentially be eased by adjusting the PPP LCP-echo settings to extend the period before the local end of the connection decides to terminate the session. Each end of the connection uses LCP echoes to make sure the other end is still "there". Nothing much can be done if the remote end decides to tear down a session (other than to do what you can to make sure you are responding to it's LCP echoes).
Q. Why PPPoX? This seems like a bad idea!
PPP gives several advantages to the provider: they can use their existing infrastructure and hardware that they now use for their (larger) dialup customer base. It is easier to control user authentication and potential abuse situations, and easier to manage their network and related issues. In fact, it most boils down to its just easier for them. Easier, means saves man hours, and therefore saves costs (at least from their perspective).
It is not a conspiracy to conserve IP addresses, or thwart heavy users. IP address costs are insignificant in the overall scheme of things.
Q. The only provider in my area does not support Linux. What can I do? Will I have to use Windows?
NO! "Support" here is support as in "tech support". They are just saying that they will not give you tech support when and if you have problems. This does not mean you cannot use Linux on their network. Just that you may have to fend for yourself when and if a problem does arise. Anything that is forbidden will be in their Acceptable Use Policy (AUP), or Terms of Service (TOS) agreement.
I have heard stories where a new tech or installer has misinterpreted their own company's policy on this and told someone "you can't use Linux here". Same with NT server. But this is almost always a misinformed individual.
But -- if a provider does not support Linux, they may balk at installing onto a Linux box. Hopefully, they will have a self-install option to get around this annoyance. YMMV.
Q. My fax software does not work with my DSL modem. Why is that?
Faxes are normally transmitted over typical analog phone lines by dialing the fax machine on the other end. Analog modems can handle this, but DSL "modems" have no dialing capability. Don't throw out that 56K yet!
Q. What does "FastPath" mean? Is it better? Faster? What is interleaving? How can I get better ping times?
Interleaving is a feature of DMT line encoding. Essentially it is a form of error correction that is configurable at the DSLAM. The side effects are a slower connection, especially higher latency. With FastPath (or sometimes called non-interleaved) DMT, gateway pings can be in the 10-25 ms range. With interleaving, this is more likely to be in the 40-75 ms range depending on the degree of interleaving that has been enabled.
On the positive side, a marginal line is more stable and less prone to errors with interleaving. Many telcos have interleaving on by default since increased stability would seem to be a good thing. But this is only beneficial for marginal lines, and everyone else is paying a latency tax for this. Some telcos may be amenable to turning this feature on/off. YMMV.
Q. How fast and powerful of a computer do I need for DSL? My ISP says I need at least a Pentium 200. Why?
At the most basic level, a 386 will work fine. In most situations, you are connected to what is essentially an ethernet based network. So theoretically anything that can handle a very slow ethernet connection would work. No comment on how well Netscape will run on a 386 though ;-) But as far as just managing a raw connection, a 386 is indeed workable. What else you can do with it, is another matter.
Where this gets a little more complicated is the modem, and the client that the ISP may require. Any PCI or USB modem is going to require drivers, which means more CPU and system resources. Also, PPPoE does even more processing, so again the potential CPU load is increased. Windows tends to be not so efficient with all this going on, hence the requirement for mid range Pentiums by some ISPs.
With Linux it will depend on what you are going to do. A low end Pentium should be fine for most uses. A 386/486 should do nicely for just a firewall/gateway box in most situations. Just remember if you are running PPPoE, you may take a performance hit on low end hardware.
Q. I just got my DSL installed, and my speed sucks, and/or my connection constantly drops. What is the problem?
Not enough information to say, really. There are many, many things that can cause a poor connection. The list is too long to mention them all.
One of DSL's weaknesses is that the signal can be fairly fragile. Many things can degrade the signal, making for poor connections, and thus speed. This can be caused by poor or substandard inside wiring, a wiring problem outside (like bad splice), RFI from any number of sources, AM radio signal interference from a nearby station, bridge taps on your line, excessive distance from the DSLAM and so on. Not to mention possible hardware problems with your modem, NIC, or the telco's DSLAM, etc. Not always easy to sort out.
Your provider should be able to assist you. First, make sure the problem isn't with your setup as they likely won't help solve a Linux problem. Then be persistent, and don't hesitate to go over someone's head if the help is not forthcoming. Most problems are solvable. The trick is isolating it. A good telco tech, trained for DSL, can find all kinds of obscure wiring problems.
Q. My provider's tech support staff is clueless. What can I do?
Common complaint. Seems to be the nature of the beast. First line tech support is an entry level position, and mostly filled by young people with little technical or networking knowledge. Grin and bear it, or try calling back.
Q. Now that I have a dedicated line, do I really need an ISP? Can't I be my own ISP?
Yes, and no. Linux has everything needed to run a small ISP. But even though the "line" is a dedicated connection, it is only dedicated to the telco end-point equipment. You still need someone to sell you bandwidth, and gateway access to the Internet. So, traditional ISPs still have their role. You might see if there is a local provider of some kind that will just sell you the bandwidth without all the frills (e.g. email and news). But this probably will not save any costs.
It is also technically possible to connect two DSL modems via a "dry" copper line. In some areas, a dry line (with no dial tone), is fairly inexpensive (but in others areas it's not). And then you need someone on the other end who is willing to provide the bandwidth and whatever services may be needed. Not all DSL modems support this (some common SDSL modems apparently do). This is also going to require dealing with the local phone company for something that is not a consumer type service (read: might be a real PITA). There is also a significant start up investment, that may not come with any telco guarantees for the intended use.
Q: Are there ADSL Standards?
Sort of. The U.S. Bell Operating Companies have standardized on Discrete Multi-Tone (DMT) (ANSI T1.413) in their current roll-out. Most others should follow their lead in the states. There are other types of modems, most notably Carrier-less Amplitude Phase Modulation (CAP), which of course, is incompatible with DMT.
A biased comparison from an DMT-based vendor on this subject can be found at the http://www.aware.com. Still, it provides the best detail on this issue I have seen so far.
A rather expensive copy of the ANSI standard can be ordered at: American National Standards Institute ANSI Home Page
Asymmetric Digital Subscriber Loop (ADSL) Metallic Interface
ANSI TI.413-1995
Note: ANSI TI.413 Issue 2 was released September 26, 1997
Q: Can I use ATM to connect to DSL?
Technically speaking, you can. Some DSL modems (at least the Alcatel version) has a ATM Forum 25Mbps interface, which connects to a PCI ATM card. But this is rarely done in practice since many Operating Systems can't speak ATM natively, and the cost of ATM cards is more than ethernet. See http://linux-atm.sourceforge.net/ for more details.
Q: Why does DSL have all these bit rates (384/1.5/7.1M/20M/etc) options?
The basic problem is the 100 year old design of the copper loop. It works great for analog phone, but it presents a real challenge for higher performance signals like DSL. Remember that the distance of a loop is inversely proportional to the data rate that it can carry. Rate adaptive technologies are great for making a digital signal work in many situations, but it can't provide a consistent bandwidth for all applications, especially for very long (over ~15,000 ft) loops. The different bandwidths that you see advertised reflect various marketing battles of vendors equipment, and the telco struggle to finalize on a standard set of data rates. The bottom line is for the telco to be able to reach as broad a customer base as possible.
Check out the next question on the loop impairments that cause this to happen.
Q: What are all these loop impairments (bridge taps, load coils, DLCs) that could disqualify my line from DSL? (thanks to Bruce Ediger)
Load coils: in-line inductances that improve voice-frequency transmission characteristics of a telephone circuit. Essentially, a "load" steals energy from high frequencies and gives it to lower frequencies. Typically only used in very long (> 9,000 ft) phone lines.
By "bridges" I assume you mean "bridged taps". In older neighborhoods, the phone wiring will have been used by more than one customer. Perhaps these customers lived at different (though near-by) addresses. The unconnected "spur" of wiring is a "bridged tab" on the currently connected circuit.
DLCs, Digital Loop Carriers: there's a bunch of systems for carrying more than one voice transmission on a single pair of wires. You can shift the frequencies up or down, or you can digitize the voice transmissions and divide the telephone circuit by time or code or something. The more general term is "pair gain".
These things cause different problems for high-frequency communications.
Load coils will completely mess up things by filtering high frequencies and passing low frequencies. They probably also change the "delay envelope", allowing some frequencies to arrive before others. One byte's tones will interfere with the next byte's.
Bridged taps act as shunt capacitances if they're long in relation to the signals wavelength, and they'll actually act as band pass filters if they're about 1/4 wavelength of the signal. That is, they'll pass particular frequencies freely. Particular tones of a DMT modem might get shunted back, rather than passed along to the receiving modem, reducing bandwidth for that telephone line.
Pair gain, digital or analog, limit the bandwidth available to one transmission in order to multiplex several on one wire. High and low tones of a DMT transmission get filtered out by the apparatus.
The book "Subscriber Loop Signaling and Transmission Handbook", by Whitham D. Reeve, , IEEE Press 1992, ISBN 0-87942-274-2 covers the math of how to calculate the effect of line length, bridged tap, etc on the transmission characteristics of a telephone line. It's pretty expensive, however.
Q. Can I run a web server with my DSL connection?
Sure. You are connected to a TCP/IP network, so theoretically you can run any service that the protocols allow -- mail, ftp, ssh, irc, etc. Where there may be problems, is with the ISP's TOS (Terms of Service). Some ISPs are pretty open on this, while others forbid any type of server, and may even block certain ports. You should research this, or ask the ISP before making any plans. ISPs that are selling a consumer service are not going to allow any high volume servers -- just personal, or low traffic services at best. If this does not fit the bill, then you can check with any local Business class DSL providers. This will cost more, but the Terms of Service, and guarantees, are generally much more suited to higher bandwidth usages.
If you do not have a static IP, you can get around this with one of the many Dynamic DNS services that are out there for just this purpose. See the links section.
Q: Do you have examples of DSL Modems?
Short Answer: Yes. Real Answer: The evolution of this technology is moving too rapidly for anyone to keep up to date in a HOWTO. Check http://dslreports.com/information/equiprated/all for up to date information.
However, below is a list of some of the current modem offerings as of January 2002. All are ADSL modems with DMT encoding (a.k.a. Alcatel compatible), unless specified otherwise. [Note: Some items retained from original list dated June 1998.]
Router/Modems with 10/100baseT Ethernet Interface:
Examples: Flowpoint 2000 DSL(CAP), 3COM Viper-DSL (CAP), Westell ATU-R-Flexcap (CAP), Aware x200, Zyxel P641, Efficient Networks SpeedStream 5660 and 5861, Cayman 3220H, Cisco 673 (SDSL), Cisco 675 (ADSL/CAP), Cisco 677 (ADSL/DMT), Alcatel SpeedTouch Pro
Bridge/Modems with 10/100baseT Ethernet Interface:
Examples: Alcatel 1000, Alcatel SpeedTouch Home [note: Home == ethernet, there are also USB and PCI SpeedTouch versions!], Westell ATU-R-Flexcap2 (CAP), Efficient Networks SpeedStream 5260, Efficient Networks SpeedStream 5251 (SDSL), Westell WireSpeed.
Modems with ATMF Interface:
Examples: Alcatel 1000, Alcatel SpeedTouch Home, Cisco 677 (DMT), Ariel Horizon II
Bridge/Modems with V.35 Serial Interface (T1, Serial Router)
Examples: Westell ATU-R
Modems with USB Interface:
Efficient Networks SpeedStream 4060, Intel 3100, Alcatel SpeedTouch USB
PCI Modems:
Examples: Cisco 605, Efficient Networks SpeedStream 3060/3061, Intel 2100, Xpeed X200 (IDSL), Xpeed X300 (SDSL), Alcatel SpeedTouch PCI
Wireless Modems (IEEE 802.11b):
Examples: Alcatel SpeedTouch Wireless
Dedicated Router (no built in modem) with 10/100baseT Ethernet Interface:
Examples: Netgear RT311, SMC 7004BR, Linksys BEFSR11
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.
![]() | Modem manufacturers often ship modems to meet an ISP's specifications. Features are sometimes enabled or disabled as requested by the ISP. There are conceivably numerous, possible variations on each model. Something to consider if buying one second-hand. |
Other related documentation from the Linux Documentation Project:
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.
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:
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.
A dictionary of some of the jargon used in this Document, and in the telco and DSL industries.
Address Resolution Protocol. Converts MAC addresses to IP addresses.
A combination DSL modem that can be configured to act as either a bridge or a router.
Synonymous with "full rate" ADSL. Used to distinguish between full rate ADSL, CAP based ADSL and G.Lite. See DSL Family for more.
A lesser version of ADSL that has lower maximum speeds, and requires no splitter or filters. Not DMT compatible. See DSL Family in this HOWTO for more.
High bit rate DSL. See DSL Family in this HOWTO for more.
Incumbent Local Exchange Carrier. The Regional phone company that physically owns the lines. Examples: Bell Atlantic and Pacific Bell. FCC regulations are forcing the ILECs to open up their networks to independent providers. This is allowing an independents like Covad to offer competitive services. This is a good thing for consumers IMHO.
Interleaving is a tunable aspect of DMT/ADSL line encoding. It essential controls the 'interleaving' of bits in the transmission, and is used as a form of error correction. As interleaving increases, so does stability of marginal lines. It also increases latency.
Internet Protocol. Also, often used to simply refer to an IP address.
Internet Service Provider. Even full-time connections require an ISP to provide basic Internet services and connectivity.
Local Area Network. A network of computers that are segregated from the WAN (Wide Area Network, i.e. the Internet). Often using private, non-routable IP addressing, e.g. 192.168.1.1 or 10.0.0.1.
Link Control Protocol, one of the sub-protocols used by PPP, and derivative protocols like PPPoE. As the name sounds, it used by both the client and server to determine if the connection is viable. Either end may terminate the session if LCP indicates the connection is not responsive.
The two wire twisted pair from the telco Central Office that terminates at a customer location. For DSL, a "clean" copper loop within the distance limitations is required.
Media Access Control Address. Sometimes also called "hardware" address, it is a unique identifier of network devices and is an important aspect of some network environments.
Remote Access Multiplexer, a mini DSLAM. Typically with very few connections -- eight is common. Used for remote areas too far from a CO.
Maximum Transmission Unit, the largest packet size, measured in bytes, that a network can transmit. Any packets larger than the MTU are divided into smaller packets, or "fragmented", before being transmitted.
Network Address Translation is a means of allowing computers on a LAN to access the WAN while "masquerading" with the IP address of a host with a suitable address and configuration. With Linux this is called "ip-masquerading". Often used to share one public, routable IP address among hosts located on a LAN behind a masquerading proxy where the local addresses are private and non-routable.
Network Interface Device - The telco housing on the side of your house. Typically where the telco's responsibility ends, and the owner's begins. Also, sometimes called the "SNI", "TNI" or "ONI" or other descriptive acronyms.
Network Interface Card - An internal PC card that supports the required network interface. Often an ethernet 10/100baseT or an ATMF-25Mbps card in this context.
Network Service Provider. An ISP's upstream provider or backbone provider.
A fiber optic line capable of 155 Mbps.
Plain Old Telephone Service - The service that provides a single analog voice line (i.e. a traditional phone line).
Point-to-Point Protocol over ATM (RFC 2364) is one of the PPP protocols being used by some DSL providers. This is really a device specific driver, and in many respects quite different from PPPoE. A hardware device, i.e. a combination modem/router, is one alternative if this is the only option available to you.
Point-to-Point Protocol over Ethernet (RFC 2516). Another PPP protocol in use by providers. This one is more common, and there are several Linux clients available. See the Links section for more. Not to be confused with PPPoA (PPPoATM) since there are fundamental differences.
Used to refer to PPPoE and PPPoA collectively.
Rate Adaptive DSL. See DSL Family in this HOWTO for more.
Regional Bell Operating Company. The "Baby Bells". The U.S. phone companies that have had a state sponsored monopoly since the break up of AT&T.
Radio Frequency Interference. DSL is susceptible to RFI if in the right frequency range, and if close enough to the DSL signal. This can disrupt and consequently degrade the DSL signal. Unfortunately, DSL seems to operate in the frequency range of quite a few potential disrupting influences.
Shorthand for 'Receive Window', aka the TCP Receive Window, a tunable aspect of TCP network stacks.
Single Line DSL. Or, sometimes also "Symmetric DSL". See DSL Family for more.
Subscriber Network Interface - The Telco term for the phone wiring housing on the side of your house. It designates the point between the Telco side and the Inside Wire. This is also called the Demarcation Point. Sometimes called a "NID" also.
The passive device (low-pass filter) at or near the NID that splits the DSL signal into separate voice and data channels. Filtering is required for most DSLs that share a regular voice phone line (whether POTS or ISDN).
A DSL installation that does not require a splitter. For higher speeds, a RJ11 filter (sometimes called microfilters) is placed on every extension phone jack where an analog phone or other non-DSL device is used, thus filtering the DSL signal at the jack, rather than at the NID. For lower speeds, no filter is necessary. Without a filter or splitter, the DSL signal tends to cause audible interference on voice phones. G.Lite needs no splitter, nor filter, but this is the exception to the rule.
Small Office HOme
The speed as negotiated by the DSL modem and the telco's DSLAM. This represents the theoretical maximum speed of the connection before any networking protocol overhead is taken into account. Real world throughput is always something less than the modem's sync rate.
German Telekom's ADSL implementation. See DSL Family for more.
a.k.a DS1 - A digital dedicated line at 1.544 Mbps comprised of 24 channels, used for both voice (24 DS0s) and data.
a.k.a DS3 - T1's big brother, a digital dedicated line at 44.736 Mbps, used for both voice (672 DS0s or 28 DS1s) and data.
VPI is "Virtual PATH Identifier" and is part of an ATM cell header. VCI is "Virtual Circuit Identifier", also part of an ATM cell header which contains circuit information. Technically speaking, these are really remote VPI and VCI (RVPI, RVCI). They are both important configuration aspects for modems and routers attached to ATM networks. They must match what the provider is using. Frequently used VPI/VCI pairs include 0/32, 0/35 and 8/35.
Very high bit rate DSL. See DSL Family for more.
Video on Demand.
Voice over DSL.
Wide Area Network, a large publicly accessible network. For example, the Internet.
Used to refer to the entire DSL family of related technologies: ADSL, SDSL, IDSL, etc.
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/.
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.
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:
# 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.
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/.