NOTE: this page describes CopperRocket 201, SDSL and IDSL versions. It appears that there have been other models, but we don't really know anything about them, so we don't have anything useful to say about non-201 CopperRockets.
The CopperRocket was Copper Mountain's most basic CPE for SDSL and IDSL. Its primary distinguishing features are:
Our project's relationship with the CopperRocket is somewhat paradoxical. On the one hand the principle on which it's based should be the very antithesis of our project. We are all about user empowerment, requiring the user to have a Ph.D. in telecom and network hacking and emphasizing the console port for hacking at almost the processor assembly level, whereas CM made a big deal of pride in the CopperRocket having no console port and no user configuration. Shouldn't the CopperRocket be our antithesis and arch-enemy on this basis?
In a paradoxical way, however, the CopperRocket actually happens to be one of the most tolerable devices for us out of the repertoire of existing SDSL CPE. How can this be?
The answer is that our project's true arch-enemy are the feature-laden, IP-aware, NAT and DHCP-oriented, GUI-configured CPE routers. Being a bridge rather than a router and being quite dumb and minimalist, the CopperRocket doesn't exhibit this problem, and can sometimes be used with the bridging workaround. As for having no configuration facilities, what is there to configure on a dumb bridge anyway?
One thing we don't know about the CopperRocket functionality is whether it does a MAC-learning bridge function or a dumber straight forwarding of all frames between the Ethernet port and SDSL.
Consider the following scenario: the Ethernet segment bridged over SDSL with the CopperRocket and whatever netmodel is used on the DSLAM has two or more hosts connected to it at the subscriber's site. These hosts communicate over this Ethernet segment amongst each other and with the gateway on the upstream end of the SDSL pipe. What will happen to packets sent from one LAN host intended for another LAN host? Will the CopperRocket send them upstream (dumb forwarding) or will it know to exclude those packets based on the history of MAC address usage (MAC-learning bridge function)? We don't know the answer to this question.
The CopperRocket was designed by the CM folks themselves rather than by a company like Netopia that specializes in CPE. There are different versions for SDSL and IDSL, but they share a lot in common, basically everything except the DSL transceiver. The CopperRocket hardware is actually quite an interesting toy in itself, completely separate from and irrespective of its intended function as a configurationless bridge, and can be put to some totally different uses in our Hack-o-Rocket project.
For some reason CM was into the silly game of rebadging with the
CopperRocket.
While most CopperRockets actually say Copper Mountain
on them, some
are badged 3Com
, called 3Com SDSL Modem
or
3Com IDSL Modem
.
The SDSL version also existed as Netopia M7100
.
In all cases the board inside is exactly the same, the metal enclosure is exactly the same, just painted differently. Even the cardboard box in which the product was shipped was exactly the same except for the imprinted logos! What the point of the exercise was remains a mystery to me.