A DSL, or ADSL modem is based around processing an analog signal in order to carry a digital signal which is a serial stream of bits. These bits are conceived as having a structure that represents units or "atoms" of data as frames or packets of information. As you scale up from bits to bytes to frames to packets there is a lot of redundant complexity to the protocols. The ISO layer system defines ways of handling bits and bytes and frames at each level to a different end result. Success at one level does not guarantee success in communications at another level.
As much as is practical a DSL modem offloads handling the more well known and "standard" ways of communicating to hardware chips on its motherboard, so that these functions don't change and can be assumed to be handled in a bug free way. Unfortunately that is not always the case, and some DSL chips even accept firmware upgrades themselves.
Regardless the major DSL chip vendors are Alcatel, TI, NEC, Infinieon, Broadcom and so forth.
After many years and much branding and marketing these chipsets have swapped hands and been known by many names.. and per usual standards have drifted and conventional implemenation has trumped actual conventions and agreements.
The end result is there have been many DSL generations that used semi-standard chipsets with various success rates in perfect and less than perfect Copper pair connection environments over time.
Navigating these waters is hard.
Above the chipset that handles what we assume is a bedrock of stability (grin) is the modem software.
Which for various reasons tends not to be individual proprietary software, but only a few variations of a theme and usually based on a small version of Linux tailored to execute the Busybox init daemon on a custom embedded SoC processor. The small embedded process is used over a larger more general purpose Linux install due to cost, size, support chips on the motherboard and reduced need for things like cooling capacity.
Unfortunately.. although Linux, most embedded modem vendors choose to not document all of the details of their work, and chipset vendors hold them to a non-disclosure agreement where the details regarding how to directly interface to their DSL chipsets are concerned.
Thus the Linux binary images on the DSL modems often contain opensource, and while some release the opensource used, they include or do not include static binary files in the opensource code that they do release. They provide actual executable programs with no source code that actually interfaces with the DSL modem chips.
Linux has a long history regarding device drivers for "reverse engineering" how to directly interface with a chipset that is undocumented. But the trajectory of the evolution of DSL chips has been such that the use of DSL chipsets did not evolve on very many PCI interface cards for the IBM PC and were changed to support a broader and more evolved version of ADSL as time went along.
Further vendors begain offering DSL solutions that acted and looked like external modems using serial and USB ports.. and eventually as self configured DHCP ethernet gateways. So that the Linux kernel "reverse engineering" people deprioritize the effort and never bothered.
This is unfortunate in that nobody outside the chip vendors actually has the tools to truly debug line problems. End users CO and CPE based are reduced to trial and error by swapping equipment and changing vendors wholeshop rather than being given the opportunity to "debug" the problem at their own expense and cost [for free] for the vendor.. so the chipset vendor "loses", the CO provider "loses" and the CPE customer "loses".. to protect a marginally debatable "trade secret" regarding non-disclosure interfaces.. strange loss all the way around.. but mostly demonstratably for the chipset vendors who stand to lose "everything"
Lantiq has reportedly strived with OpenWRT and DDR-WRT to make a version available for a Buffalo DSL modem.. but it is under some question.
Sangoma had the S518 and S519 though the later was little more than an Ethernet card with a telnet interface to a DSL modem running Linux.
The norm seems to be to now provide Ethernet port access to a DHCP self configured DSL modem and at most a Telnet interface to the underlying Linux operating system which is generally on an embedded system running Busybox some version of the xdslctl driver from a squashfs with lzma compression filesystem.
Cisco 1720 and Cisco 877 class routers had variants of a WIC-1ADSL card which could communicate over ADSL using the Alcatel or later STmicro and then Broadcom chipsets direct.. with a little more information availble on a slightly beefier and reliable platform.. but are somewhat expensive and difficult to use. Conflicts with the Globespan/NEC/Easynet chipset at the DSLAM appear to be common and related to a chipset firmware bug that may or may not have ever been fixed in a much later generation router. The suggestion was line training was not similarly implemented and the only workaround was to sync at a lower connection speed than other chipset providers for interoperability.
DSL modems have both fallen in price and increased. First because the cost of components and software fell as Linux became the host of choice and required no licensing. Second because they keep trying to make the DSL modem product more fully functioned by expanding the services Linux offers as a media server, print server, firewall, WiFi router, VPN connection server and so forth.. these also conflict with resource utilization if all turned on, and lead to memory leaks, line instability and wholesale indeterminate DSL modem failure on a random basis. While trying to reduce the price of components.. ram, nand, ect.. they are placing greater dynamic demand for those resources by offering more features at odds with stability and tools to help diagnose or record problems.
It is possible to extract and modify then put back the existing nand copies of most DSL modems firmware, but requires a high degree of technical skill and is error prone, consequences of an error can lead to "bricking" or permenantly making the DSL modem unusable . OpenWRT and DDR-WRT are known to be pursuing these goals on indetermenant and unpredictable timelines for many products with a focus on WiFi capable routers.
