How to create a SDSL (2B1Q) back-to-back connection?

This is about setting up a direct, point to point / back to back connection using SDSL (the 2B1Q technology, not the successor SHDSL aka G.SHDSL). The purpose of this effort is twofold:

To be able to set up a cheap high-speed long-range computer network connection using drilled copper wire, which is the simplest and cheapest cable that can be used for this purpose. Bell wire 2×0.8 mm² on 250+ m coils costs ~0.1 EUR/m.
Setting up such a connectio with minimal hardware costs. Using SDSL hardware is the cheapest alternative as of 2011-07: both SDSL routers together have been obtained for aboute 40 EUR in used condition, while a similar setup with VDSL2, which of course is up to 100 MBit/s, would be 360 EUR (AllNet ALL126AM and ALL126AS) or with ADSL it would about be about 200 EUR at least (CATENA CN24 MODEL 211 MINI-DSLAM, and a simple ADSL “client-side” router). The problem is that VDSL and ADSL server hardware is nearly impossible to come by in used condition; while this is possible for SDSL hardware, as server functionality there was seemingly more common as “just another firmware feature”.

The equipment you need

SDSL server. In this case we use a Zyxel Prestige 681.
SDSL client. It is highly recommended to use the same product that you also use for the SDSL server, just configured as a client. Because, SDSL hardware that can be used as a server normally is meant to be used that way, and tested that way. Trying to use any ordinary SDSL router or modem on the client side might or might not work. In this case, using a NETOPIA R7200 SDSL router as a client for the Zyxel Prestige 681 did not work out: even though the same link compatibility mode (here: Ascend/Lucent) and speed (multiple tests with different speeds) was tried, syncing failed. If you want to try a normal SDSL modem: a modem has to be connected to a PC in order to make a connection. So in case you want to connect multiple PCs to an Internet connection on the remote node, better choose a router.
Telephone wire. You can use any two-core bell wire or phone wire, but note that the speed and reach of the connection depends on the cross-section. For example, using AWG 26 wire (means 0.129 mm²) one can use the full SDSL speed of 2320 kbps up to a distance of 2.3 km [source]. It’s also noted there that using thicker wire increases this distance.
WLAN router (optional).

Note that SDSL devices are rare in Europe as they have never been in widespread use here, but more common in the U.S. though falling out of use there, too. For that reason, obtaining two pieces of the same SDSL hardware, as proposed here, can prove to be quite difficult. You may take some months of observing eBay auctions, and better look to the U.S. market as SDSL had been way more common there.

If you want to try combining different devices as SDSL server and client (you have been warned not to do so!), selecting your SDSL device, you also need to take care to get matching SDSL flavors: SDSL was a proprietary protocol, and thus has multiple vendor-specific SDSL flavors. The common ones found in the wild are Ascend/Lucent and Copper Mountain. In many product descriptions, these identifiers are missing, but you can still detect the supported flavors by the supported speedsteps:

Ascend/Lucent link compatibility mode is supported if the following speeds are supported: 144K, 272K, 400K, 528K, 784K, 1168K, , 1552K, 2320K [source].
Copper Mountain link compatibility mode is supported if the following speeds are supported: 160K, 208K, 320K, 416K, 784K, 1040K, 1568K [source].

Note that there are many devices which support both modes.

List of SDSL devices with “SDSL server” / “Central Office (CO)” functionality

ZyXEL Prestige 681. Resources on that device:

manual, configuration examples and firmware
support note (the missing document in the previous source because of a dead link; includes all kinds of useful information from FAQs to password reset etc.)

Net To Net (Paradyne/Zhone) SNE-1000 SDSL Ethernet Extender Kit (containing two devices in one package)
some model of Speedstream SDSL modems, with support of the Ascend/Lucent SDSL flavor [source]

Setting up the back-to-back connection

In case you have the ZyXEL Prestige 681, refer to the document “LAN-LAN Konfiguration Prestige 681 (Bridgemode)” (German).You might want to make adaptations to get a routing configuration, which puts less load on the SDSL connection as no broadcast packages are transmitted.

In case you have different hardware, refer to its manual and maybe to the collection of tips below.

Tips on using SDSL

From my limited experience (note that my attempt to set up the connection with ZyXEL and Netopia devices failed!), here are some interesting notes and hints on starting to work with SDSL:

The best source of technical information on SDSL on the Internet seems to be the OpenWAN project.
It might be that the Netopia R7200 with the SDSL/ATM wanlet (as was mine) only supports “flavor A” SDSL and therefore could not sync with the ZyXEL Prestige 681 which supports only flavor B (namely Copper mountain and Ascend/Lucent). This seems strange as the configuration menu also offers the option “Lucent”, which normally means flavor B in variant “Ascend/Lucent”. But in the OpenWAN project they state that “[o]ur experiments using the Hack-o-Rocket have revealed that all profiles other than Nokia correspond to Flavor A” [source].
The Netopia R7200 as SDSL router can come in two variants: with the Copper Mountain wanlet, or with the SDSL/ATM wanlet. You can differentiate between them by what link compatibility modes are offered to you in the WAN configuration: if it includes Nokia etc., it’s the SDSL/ATM wanlet. If there is no such selection at all, it’s the Copper montain wanelt. The Netopia R7200 manual for example is written for only the Copper Mountain wanlet.
If you want to combine a SDSL server with a SDSL client that is not the same product, they need not only support the same SDSL link compatibility mode and speed (see above) but also the same encapsulation mode. Encapsulation mode refers to how MAC level network package information is “packaged” when travelling over the SDSL link. Compatibility in this matter might simply not be the case, as there is a chaotic set of different choices. In just two devices I have seen these:

RFC 1483
RFC 1490
CM 1483 (which is the “Copper Mountain” SDSL flavor’s variant of RFC 1483)
CM 1490 (which is the “Copper Mountain” SDSL flavor’s variant of RFC 1490)
PPP (with various authentication modes that did not match either: None, PAP, CHAP, PAP/CHAP, …)
and there are more

It seems to be irrelevant for SDSL if you switch its two copper cables. At least my setup behaved exactly the same when doing so (starting to sync, the client immediately after the server, but failing to sync finally for reasons explained above). The reason seems to be that both cables are used for transmitting data (no “ground”) and that syncing will make the system learn which data should go in which direction. See this quote: “[A]t the bitpump level the SDSL line is not much different from one of the loops of an HDSL system. […] An HDSL system consists of two metallic loops like a traditional T1 system. However, whereas in a traditional T1 system each loop carries data in only one direction, in an HDSL system each loop carries one half of the DS1 payload in both directions.” [source]
At OpenWAN, there is a great technical overview (and rejection of their design choices) of Netopia R-Series SDSL routers [link].

Conclusion

SDSL is a “severely broken” technology that never was independently standardized and thus is a total mess of proprietary “standards” and their extensions and variants and flavors and modifications. The only meaningful way to operate a simple SDSL back-to-back connection (as we intended here) is to use two exactly identical devices of which one will be configured as the SDSL server and one as the client. Cross-device Interoperability in the SDSL sphere is a nightmare. The devices were just meant to be provided by one ISP to his customers, and thus the ISP only had to solve the interoperability problem with his SDSL servers once and for all (but even that is too much for a single back-to-back connection as we want).

For anything that is not a simple SDSL back-to-back connection between identical devices, better never ever touch SDSL. It’s a total mess.

Let’s close with a quote from the world’s “most total” SDSL nut 🙂

In fact the lack of any semblance of a standard for SDSL and the proliferation of wildly different flavors makes it virtually impossible to market SDSL CPE to end users. How would an average user or even someone who is an experienced network administrator but not a total SDSL nut like me figure out which CPE version or configuration to choose? [source]