Cisco 877, How To enable SDM

This is more a landing page for more notes to follow(?) [and for Security Nerds, yes its an old "toxic Smurf stew" of moldy old software stirred together to support this, but packaged up in a nice virtual machine and used purely for management (not surfing the high-seas of Randsome ware Pirates) its an acceptable use-case.. chill..]

A few things (I really like) about a "real router".. modular upgradability (RAM and Flash)  as hardware costs come down and needs increase. True dedicated IOS focused on WAN LAN routing functions with "best in class" hardware, designed from the start with proper thermal footprint cooling considerations.. proven designs that are tested over a long time, on-going development and support for baseline features.. without going off the deep-end suffering from product feature creep, or over promising on poorly delivered features. Ancient structured configuration methodology over serial, telnet and ssh consoles (all available), true industry standard "Syslog" and "SNMP v2" capability.. supported gui, and a long.. long.. line of available production quality and tested firmware images, for the router and the peripheral WAN cards. And.. most important.. not "prophylactically" locked down for "your safety!"

I bought a nearly out of support (Dec 20, 2016) Cisco 877 router and retrofitted it to max out its RAM and Flash memory and deduced how to enable one of the many "next generation" user interfaces Cisco was promoting last decade. 

They're long gone now, nearly buried and "all but" abandonned, but like ancient cities or temples hidden away and forgotten.. I'm hoping the 800 series ADSL routers can perform the task of a wan to lan router with a reasonable NAT firewall much better than something orders of magnitude cheaper and plain too weak for the purpose of providing stable DSL service. I'm not totally ignorant of iptables, ipchains or ios access-lists, but a simple gui to help cut through the memory fog will be a welcome respite.

fwiw - Firefox 3.5.7, IE8, java 1.4.12-20 [ all available online for resurrection in a google search engine near you ] will run the SDM properly on XP, here in 11/2016 - but IOS evolved beyond SDM support when it was replaced with Cisco-CP and any IOS image after c870-advipservicesk9-mz.124-20.T.bin lost the ability to support the SDM gui write changes to the running config in the gui memory space back to the 877 and possibly other routers. 

[Note:] Windows 7 and later, or "modern" Firefox or Internet Explorer, even Chrome simply cannot be reconfigured sufficently to support running SDM. I did get fairly far with an experiment in doing this, however the overlapping layers of security and intrusion prevention circutry inside these software products "hides" or otherwise disabled so much of the SDM java applets that it just wasn't feasibly practical to use Win7 and any "modern" browser to run SDM. -- for one thing the "Additional Task" panel under Configuration was totally unresponsive and disabled.. this forms the "core" of the purpose of SDM which is the tool used to manage the overall Run Configuration for the router.

It makes sense this "would happen" since the SDM was retired by that time. SDMs virtue however is it will work with Cisco 1700 series routers where Cisco-CP began its life supporting the "newer" Cisco 1800 series routers. 

The [Reset] switch at the back of the 800 series routers will [not only] wipe the startup and running configs of the 800 routers, but also [restore + re-configure] the default VLAN and LAN/WAN ports, with a static IP address (10.10.10.1) and pre-configure a "one time use" Level 15 enabled username and password.. so you can hook up a LAN cable to the "Reset/Pre-configured" router and statically configure your Laptop/PC ethernet port to 10.10.10.2 and immediately login (using telnet or ssh)  without needing a serial cable (or you "can" add a logical IP to the existing interface of your laptop and stay connected "simultaneously" to both your previous local LAN subnet and the routers pseudo-temporary subnet). 

This is  "important"  because the LAN switch ports on the back of the 877 and presumably all of the 800 series are by default VLAN capable and enabled, so rather "unintuitively" you can't just assign IP addresses direct to those interfaces (frustrating to say the least for any hack half-way experienced with Cisco IOS products) rather you have to "know" you must create or manage the VLAN interfaces to which the FastEthernet interfaces are granted "switchport access" and assign the IP addresses to the pseudo-VLAN interfaces which represent their domains...sigh.. facepalm.. what were they thinking in a consumer grade product.. {anyway get over it..} .. just know, its easier to start out with a ready-made template and default security context with a running-config by "using the Reset button.. Luke!" and you don't even need a usb-to-serial converter cable.

[Note:] Know this, the documentation and some of the SDM dialog text refer to the Cisco 877 as having the SDM applets "already" onboard the flash drive of the router. This is not always so, especially for a refurbished, or "somewhat used/abused" router (not "fresh" from the box) that has had its flash mangled or maligned by CLI users.. often they throw things away to make space, or in the case of a flash upgrade don't even have an IOS image until its tftp loaded using the bootstrap monitor. 

Manually loading the SDM applets onto the router using tftp isn't documented or supported as far as I could see.. so your best option is to download the full SDM from Cisco for free and use its windows installer to perform a Local PC install (only) of the SDM. then use the Local PC SDM to "bootstrap" connecting to a "Reset to factory default Preconfigured" router, to change the one-time-use password. Then you can re-run the windows installer for SDM and perform an "Install to Router (only)" install in order to get the SDM applets re-loaded on to the routers flash drive.

"trust your Nose" if your router doesn't have that "New Car Smell" and smells a little bit more like a roaming Gnome.. expect to have to bootstrap your router with the PC "two-Step" dance.

If you have installed SDM on the PC it can connect to the static router IP and walk you through changing the one-time-use username and password to something more secure. 

Uploading SDM to the router works with the older (but still "compatible" with SDM image)    870-advipservicesk9-mz.124-20.T.bin  but does not work with later IOS images.. 

The router just spins saying "Connecting" and then "fails to connect" and never allows the SDM installer from the PC to finish the task of uploading the SDM express "mini-java applets" to the routers flash drive.. the older image  does  allow the SDM installer to connect, then presents choices for what components to upload and completes this mission.

ADSL, How it Works

ADSL is something of mystery with regards to how a DSP chip which is essentially used as a high frequency "sound card" line trains or "syncs" with a line card in a CO (Central Office). This is how that works.

Basically the CO sends a set of tones which the CPE (Customer Premise Equipment "your DSL modem") detects and then proceeds to perform a line qualification, or training session.

A set of test tones is sent and used to determine suitability of various tones for reliably carrying data bits. These represent "buckets" into which the bits can be assigned during a tranmission. Part of the buckets are used for "Upstream" transfers, some of the buckets are used for "Downstream" transfers. The majority of the buckets are assigned to "Downstream" transfers and that is why the "A"DSL is "Assymmetric" or "lopsided" - it "favors" the downstream direction.


To actually prepare and transfer a sequence of bits or "byte" of information, the DSP chip assigns the individual bits to the available buckets for transfer (some of the buckets may be deprioritized, or "black listed" as predetermined by the line "training" session).


Then it performs a Fast Fourier Transform to convert the composite arrangement of bits into a continuous waveform. It essentially "smears them into an analog signal" and sends that signal. The assumption is that by transforming from the digital to the analog domain, or the "Frequency Domain" the signal will be more resistant to signal degradation or "damage" in the instaneous "Time Domain".. basically this means if there is a snap crackle or "pop" on the line. The transmission will likely make it "across" the line in some fashion which can be "error corrected" when its converted back from the "Frequency Domain" into the "Time Domain" and the individual bits are recovered from the designated buckets.

The CO equipment also has a "map" of the chosen frequency bins determined during the line training session with the CPE equipment, and this influences how it actually carries out the [Inverse Fast Fourier Transform].

Bit error correction is  conducted by a combination of Reed Solomon and other methods, and the Near and Far indications are used to describe whether an error was corrected at the CPE receiving end or at the CO transmission end and vice versa.

CRC or "check sums" are used to verify the RS error correction actually worked, or failed in which case "Uncorrectable" errors are determined to have occurred and a "re-transmission" of the data is automatically requested.

Excessive uncorrectable or RS activity should automatically trigger a "line retraining" event, a "line drop" or a "re-sync event".. the purpose of which is to re-characterize the line and try to construct a "new algorithm" from the detected available Frequency Bins on a line. Some modems do not do this step well, or in co-ordination with the CO. Line "syncing" is not always successful and a complete failure can lead to an inability to "re-connect" event after a previously successful connection.

Typically during "training" the CO and CPE "agree" on a "sync rate" or how fast the Upstream and Downstream rates will be once the the "training" event is over and communications begins. Based on various chipset implementations the "sync" rate may be higher or lower, either as a result of or consequence of compatiblity in their sync procedures, and or various deviations from the established "Standards". For example one vendors chipset may choose to sync at a "faster" rate in Upstream or Downstream or both when it detects it is communicating with equipment made by the same vendor.. and yet choose to negotiate a slower (more stable) rate with equipment made by a different vendor.

End users on the other hand may want to attempt faster sync rates for various reasons, or have the ability to "override" the decisions of the chip makers. This has lead to a number of supported and unsupported "hacks" by end users seeking to monitor and influence the training session.

Unfortunately since there are few direct implementaions of "special functions" made available by chipset or modem vendors. This is something of an art, and something of a dying art at that as ADSL chips move further and further into history.

ADSL, Chips and Salsa

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.

ADSL, Bats in the Belfry

ADSL is a multi-tone technology that measures the available tone spectrum from close to zero to very high inaudible frequencies on your Copper pair phone line. A small lower frequency portion is reserved in case you also have a voice line service over the same DSL line. And a Low bandpass "signal splitter" can further isolate that from harmonic interference both above and below the demarc established for voice or data traffic. This can improve voice clarity, and data transmission reliabilty.

But this takes place from the CO to the CPE (Central Office to Customer Premise Equipment) over a copper pair that is assumed dedicated and trouble free to the NID (Network Interface Device) or the little gray box on the outside of your house. Often the NID is supplied by the local telco and conforms to an industry standard like the Seicor Corning CAC 7600 style NID box.

The NID box has a cable entering generally from below on one side through a Subscriber Grommet to keep moisture out and is terminated on a terminal bus then bridged to the customer side of the NID box through a [test jack] which is a conventional RJ11 plug and socket. The RJ11 is then terminated at two screw terminals where a customer can connect "premise" wiring which travel down the opposing side of the NID box from the telco side, through another Subscriber grommet to keep moisture out and back into the house.

All of the telephone wiring and Copper pair to and from the NID is subject to the outdoors. UV and Weatherproof or "burialproof" cable should be use to make sure the Copper pair is not compromised by the elements when it runs from the NID to either the CO or into the customers house.

Once the Copper pair enters a house it often gets split off into multiple pairs or "tapped" in several places to run Copper pair to different rooms. Each bridge or "tap" introduces signal losses and reflections like in a fun house echo chamber into the line. Which a phone or DSL modem must struggle to nullify and reduce or ignore. If a DSL modem is not successful it can end up passing along some of this "noise" into the DSP (digital signal processing) chips used by the modem to read and write ATM packets to and from the Copper pair.

And each connection jack exposes the Copper pair direct to the air where moisture and corrosion can introduce short circuits, random snap crackles and pops and unstable or unpredictable noise. The additional runs also act like mini-antenna into the house which can pickup additional noise from light switch current surges, CFL/LED light bulbs, blenders, microwave ovens, WiFi routers, computers, cell phones and all manner of electrical noise.

Our homes are very noisy electrical dens and can make trouble for a DSL modem trying to sift through all of the noise to find a "true" DSL signal.

The best DSL connections are a "Home Run" or a straight line from the DSL modem direct to the NID and to either a splitter or the actual Copper pair assigned from the CO at the NID. But this requires quite a bit of preparation, and the use of specific outdoor grade telephone cable, and possibly an enhanced grade of telco cable like CAT5 or above to eleminate any crosstalk between the wires and dampen any external signals that might be picked up when running from the DSL modem to the NID.

Further, however it is wired to the NID or the DSL modem, its best to coat the terminals or jacks with an Anti-Corrosion resistant Moisture proof or resistant gel which will allow electrical contact without a short circuit and prevent the connection from degrading over time.. essentially a kind of di-electric gel that does not dry out. This can be hard to find.

Finally it goes without saying, any line length added by bringing the Copper pair into the house to service additional RJ11 jacks for other phones, also increases the distance from the CO to the CPE, sometimes significantly because builders often want to leave "spare" cable length. This is so they do not have to "pull cable" later if they want to add additional connection drops.. these "loop lengtheners" can add up fast into the 100's of 1000's of feet. It does not matter if the DSL modem is the "first drop" or last drop along this extra cable.. it all counts to the total length due to reflections and additonal noise level introduce simply by the extra resistance of the total length of cable.. it raises the ground floor of the noise and makes the DSL modem behave as if it were at the very end of the cable.

ADSL, Back to the Future

Just setup a DSL line to a home in a remote community near Branson, Missouri - the only affordable option was CenturyLink DSL. This is that Odyssey.

First came the sign-up through the CenturyLink (CL) online Chat service. Took a little over an hour, not that there are a lot of options, but a lot of backend checking, coordination and swivel chair searching for the obligatory "Compatible Modem". -- In this case an xDSL modem.

DSL - "Digital Subscribe Line" is an evolved version of online Internet Dial-up, evolved such that it is (always) online. There are have been many generations of it beginning shortly after I left the world of Trumpet Winsock and Windows 3.11 way back in the early 1990s.

Essentially back then you had limited options if you wanted to connect to the Internet. You could get to your ISP (Internet Service Provider) over a direct Ethernet connection (from school or work), or over a T-1 (Terrestrial One) Digital Subscriber line (these were more commonly use through a CSU/DSU to carry voice or data traffic) or you could get a "pure" ISDN line, which again was a voice or data technology which used TDM - Time Division Multiplexing, to "share" the line between packets intended to carry voice or data traffic.

Current DSL was an evolution of the acoustic dial-up modem and ISDN. Basically its not a T-1. ISDN was "symmetric" in that upload and download speeds were the same and traffic was dedicated to either voice or data but not both, later versions would make this more flexible and relax early restrictions, this was all before VoIP came along.

So take the DMT - Dual Multi-Tone technology used by dial-up modems and qualify or "train" the line between the Central Telephone Office (the "CO") and your house (the "CPE" Customer Premise Equipment) and you can split up the available audio "tones" or audible "tones" and frequencies "beyond" those tones you can actually hear into [channels] each of which can carry a few bits of a byte simultaneously. This "spread spectrum" approach to dicing up a byte into bits spread across different tones means that a "good" line can carry a lot more traffic than a "bad" line.

Generally copper lines to your house get "noisy" and harder to use "full spectrum" for pushing and pulling bits the further away from the "CO" you get. And the "thinner" the copper in the lines the noiser they get "too". Mostly however lines are of a standard size. But heavier "larger diameter" lines will carry more traffic with less noise.

Copper is subject to corrosion over time, and injury from backhoes and other equipment in the wild, even squirrel bites and nibbling. So they need to be replaced after 10 or 20 years.

Also Copper is a "conductor" and it will pickup "cross talk" or "oersted induced currents" simply from being laid next to another wire with a varying current.. like a power cable or electric line. To make things worse laying either in the ground or running over head Copper lines act like very long "Antenna" and pickup all manner of Radio Frequency interference.. which tends to increase during the day or early evening when people are using RF generating equipment like radios, cars, microwave ovens ect.. the interference doesn't have to be "exactly" on the same frequency as the data traffic to cause interference harmonics and natural resonance circuits in the surrounding landscape can do the job nicely as well.

So while "clever" that basically the acoustic modem has evolved into a modem that uses not only audible tones but those far beyond the range of human hearing over the same lines.. Copper presents a constant maintenance problem. And a constant challenge when setting up a new subscriber to service.

The CO equipment has varied greatly over time, but basically its called a DSLAM or MSAN and its a DSP - "Digital Signal Processing" box with "line cards" that terminate the Copper pair coming from your house (the "CPE" customer premise equipment). These are pretty dumb and simply establish a "trained" circuit using ATM virtual circuits over virtual paths between your modem and the central office.

Once the virtual path is "Up" anything can connect to the interface of the virtual circuit and shout a login method to something on the other size. Very often this logon method is PPP Over Ethernet.. or PPPoE. PPPoE is a combined standard, it marries serial link PPP with the standard expectation that you will be connecting the PPP protocol interface over an Ethernet port. So these modems usually provide a dumb Ethernet interface that routes the PPP packets to ther other end.

The DSLAM or MSAN doesn't know anything about PPP but it does know what a serial link is, and it connects that to an Ethernet port which can carry the PPP to its backend access server.. the RASPPPoE server which can accept PPPoE login requests from a customer. If successful, or allowed by the RASPPPoE server, then the customer can begin sending TCP packets to route over the Internet. Part of PPP optionally also requests a DHCP or Dynamically assigned IP address as part of the logon process.. but its optional, if the customer has a known static IP address all they need do is login sucessfully and the are on the Internet.

Problems can crop up with the DSLAM or MSAN equipment because they are made by different manufacturers, they have Interoperability "bakeoffs" but that doesn't mean they all perform up to the same performance. CO equipment connected to by CPE equipment at the customer site may have "interop" issues and only connect as slower rates.. if at all. To say nothing of the [Type] of DSL that CO has decided the CPE is allowed to use.

Over time xDSL has evolved from ADSL to ADSL2 to ADSL2+ to VDSL to VDSL2 and so on.

ADSL is "asymmetric" or "lopsided" DSL.. it means the packet traffic path "down to the customer" is "larger" than the packet traffic path "up to the internet"

that is 1000 Kbs / 384 Kbps for example

1000 Kbs "down" to the customer

384 Kbps "up" to the internet

The reason for this [A] in DSL is because when it was decided to invent ADSL the assumption was customers would rather use [more] of that Multi-tone frequency range for [pulling] data from the Internet than [pushing] data to the Internet.. they weren't expected to run Internet servers.. they were expected to do things like use Internet Browsers or Watch Netflix.. [so more would be downloaded than uploaded].

This ADSL became a [standard] its unbalanced to "favor" download capacity in the customers interest.

SDSL on the other hand, which was more akin to ISDN, was "symmetric" DSL and considered "Business class" because those customers "might" indeed want to run Internet Servers and want the capacity equally split. So it was priced appropriately for "Business class" users and is usally more expensive.

[Provisioning a Port] to the telco company means, hooking that Copper pair to a DSLAM that has chipsets and hardware for supporting only [one-type] of DSL.. ADSL or SDSL.. not both and can't be switched without a "Port change" (moving the copper pair to a different box) and changing your Bill for Services to charge you for the higher or lower cost of that service.. its a major pain.. so basically people buy ADSL or SDSL but not both and not both at the same time.

Within ADSL there have been ADSL, ADSL2, ADSL2+, VDSL, VDSL2 and so on.. these are all asymmetric services for customers (lopsided) on purpose. Generally ADSL has the longest "reach" or can "work" over the longest length of phone line Copper pair from the CO to the Customer but it offers the slowest service and is at the bare edge of possible. A closer connection using ADSL and not ADSL2 for example will run at ADSL speeds and be slighlty more reliable.

Each later generation ADSL2, ADSL2+ ect.. is higher speed, but shorter reach.. and harder to keep "Up".. when a line is "trained" between a Modem and CO line card it runs ATM packets all the time, if something happens to degrade this, (i.e if enough ATM packets are "garbled" in transmission and thus "uncorrectable") one or the other of the CO-to-CPE side will "disconnect" and often not notify the TCP or PPP link above it.. leaving those virtual connections in a state of undefined limbo.. and the customer wondering why the Internet has stopped working.

A clever customer may then manually try to "reboot" or reset the DSL modem hoping to "clear"  the lines of communication and re-establish a connection. But whatever external cause precipitated the first ATM disconnect is likely to persist and thus they will probably not be successful .. at least until much later when it will magically appear to "connect".

This can be very frustrating.

Some high-end modems can monitor the DSL ATM connection status and automatically "retrain" and re-establish, but likely will have the same amount of success as the "clever customer" and may fail to reconnect until after the conditions that lead to the first disconnect subside.

And worse ADSL and VDSL are incompatible.. later generations of VDSL modems [might] backwards detect and support ADSL with an [auto] feature but its rare and doesn't work well, often it fails.. and many new modems no longer support ADSL "at all".. so usually a truck-roll involves using a handheld gadget at your outside phone box (NID) to actually "measure" how far you are from the Central Office.. that tells them what is "possible" and they communicate how the [Port] for you should be "Provisioned" ADSL or VDSL for example and then by subcategory 2+, 2 or 1.

They usually try to start "high speed" with the maximum speed service they offer, (aim high) and then reel in their expecations after a site visit to measure what is really possible with your Copper line.

CO equipment also doesn't always work well with Customer CPE Modems, especially if they are known to have buggy software or were made with chips from a manufacturer other than the manufacture that made the chips in their DSLAM.

Tracking the chipsets between CO and CPE equipment is hard, made harder because even if you can get their manufacturer names.. often those companies have been bought out or changed names. xDSL tech is almost 30 years old, so there has been a lot of water under the bridge.

"Approved" modems by your CO provider (CenturyLink) are usually little more than "best guesses" that equipment they have seen work before.. may work again. They don't know if the most recent models from different vendors will work with their DSLAM or MSANs in a particular CO.. its usually a matter of trial and error. Modem makers also change their software and chipsets from time to time because of cost and parts availability.. so a particular modem replacement may have the same outside "shell" or cover on it.. but the internal circuit board may be a Version 1 or Version 2 or Version 3 and be totally different.

This ends Part One of my story regarding setting up DSL in 2016.

Later parts will cover Customer Premise wiring problems, Modem selection and diagnosis problems, and methods of overcoming really difficult Uptime problems.