We have implemented a rudimentary IP router application on our Hack-o-Rocket platform, and we have used it to prove successful 100% open source connectivity to Covad SDSL and IDSL circuits cross-connected to 3rd-party ISPs (not Covad IP).

The HoR IP router is extremely primitive and bare-boned; it comes nowhere close to complying with RFC 1009. However, at the present time it is the only router in the world to the author's knowledge which makes a 100% open source connection to SDSL. The router code exists in 3 versions:

The only encapsulation supported on the line is straight routed, i.e., routed RFC 1490 for IDSL and Flavor B or routed RFC 1483 for Nokia SDSL/ATM. No support for bridging, MER or PPP on the line. (Please read this page for a good explanation of the difference between routed and bridged circuits.)

Performance

The IDSL and SDSL Flavor B versions of the HoR IP router use the CR201 hardware pretty much in the way it was meant to be used: the MC68LC302 SCC speaks HDLC and does a very good job at it, the CS8900 Ethernet chip sends and receives packets on the LAN interface, and the code running on the CPU routes IP datagrams between the two interfaces just like a traditional gateway design. The only differences from CM's original CopperRocket are that we do IP routing instead of bridging, don't speak CMCP and have a very Spartan configuration mechanism. We have no good way to test it, but we expect the Flavor B version to perform well at all SDSL data rates all the way up to 1568 kbps just like the original CopperRocket.

On the other hand, the Nokia SDSL/ATM version is an example of thinking outside the box. We use the MC68LC302 SCC to receive and transmit 432 octet long Nokia frames and implement the higher ATM and AAL5 layers in pure software. Amazingly, it works, but there are significant performance limitations. Here is how we perform at different Nokia SDSL data rates:

192 kbps
Works well with the line saturated in both directions.
384 kbps
Handles a fully saturated downstream pipe, but is able to fill only a portion of the line bandwidth in the upstream direction (transmits a lot of idle cells/frames). An upstream FTP transfer test clocked in at about 26 kbyte/s.
768 kbps
Same story as at 384 kbps, but the effective upstream bandwidth as measured by FTP transfers is even less (about 24 kbyte/s) due to the greater interrupt load and saturating the pipe in both directions with two FTP transfers at the same time causes occasional recoverable underruns (shutdowns followed by restart).
1152 kbps
1536 kbps
Unusable — the slightest bit of downstream traffic causes an immediate underrun. The link gets re-established, but as soon as TCP retries sending, another underrun immediately occurs.

The executive summary is that the Nokia SDSL router works well at 192 kbps, OK at 384 kbps if one is willing to live with a reduced effective upstream bandwidth, risky and not recommended at 768 kbps, unusable above that.

Haunting Ethernet problem

The other serious problem with the Hack-o-Rocket router besides Nokia SDSL performance is some strangeness with the CS8900 Ethernet interface which we have never quite nailed down.

We have used the Hack-o-Rocket IP router as real operational CPE on two live circuits provisioned via Covad (one 384&nbps;kbps SDSL pipe from Verizon Business and one IDSL pipe from a small ISP), and it worked for many months without a hitch, although the load was light. However, when we moved our main servers and operations to the site that had the Verizon Business pipe served with an SDSL Hack-o-Rocket, it ran fine at first, but then some strangeness started occurring. Once in a few days at a completely random time the rocket's Ethernet interface would freeze, i.e., stop receiving and transmitting packets for an unknown reason.

The Ethernet freeze meant that no IP traffic could pass through the router, i.e., effective total downtime of all connected systems. The solution was simply to reboot the rocket, but by Murphy's law the hiccups occurred when there was no staff at the site, and having to dispatch someone to the site in a drop-everything emergency manner twice a week to reboot the damn rocket was clearly unacceptable. Therefore, we were forced to go back to using Netopia R7200.

The reason we have not allocated any time or resources to tracking down the Hack-o-Rocket Ethernet problem is because we want to move on past this rocket to move interesting things — see below.

How can I get one?

The HoR IP router is part of the Hack-o-Rocket software kit. See our main page for information on how you can make a Hack-o-Rocket unit or get one made for you.

Going forward

The Hack-o-Rocket was a proof-of-concept implementation and has done its job. It is now time to put it to rest for the most part. Its intended replacement is the OSDCU aka VersaDSU, in combination with some old Cisco router or our planned HECGW.