Netopia's R-series was an interesting family of routers for various WAN connection types, including several flavors of SDSL. There also was a closely related D-series of pseudo-DSU products, which were actually exactly the same hardware as the R-series routers and even ran exactly the same firmware, but were configured with a different feature key as explained below.
R-series and D-series products feature a fairly flexible modular
hardware platform, but are unfortunately severely hobbled by Netopia's
proprietary firmware design choices which fall into the category of
defective by design.
The R-series/D-series hardware consists of a common motherboard called
UMB3 and two WAN daughtercard slots.
WAN modules or wanlets were made for a number of well-known standard
network interfaces (Ethernet, analog modem, ISDN, synchronous serial,
T1, DDS) and also for some flavors of SDSL as explained below.
The motherboard features an Ethernet hub and a so-called auxiliary port;
the latter is capable hardware-wise of acting as an asynchronous serial
port (e.g., dial backup), as a V.35
DCE port (used on the pseudo-DSU
products as explained below), as Apple LocalTalk and perhaps other things,
but Netopia's defective-by-design firmware severely restricts its use.
A sensible software design for a modular hardware platform like Netopia's R-series would have been to enumerate the hardware interfaces (WAN modules) that are present, allow each of them to be configured independently for options like the encapsulation type, and then give the user the ability to configure any desired cross-interface networking function: routing, bridging or FR cross-connect as in their pseudo-DSU products. But unfortunately this is absolutely not the way Netopia's firmware works. Instead their firmware consults a flag stored somewhere in flash or NVRAM (not configurable by the user and not changeable by mere mortals at all) which tells it whether the unit was sold as R-series or D-series, and enables one of two different and mutually exclusive sets of functionality:
router behind a bridgefunction, no straight bridging allowed.
V.35function of the D-series is not available.
V.35synchronous DCE port.
As one can see from this summary, neither mode is inherently better
than the other.
Each mode has features not available in the other (in fact there is not one
operational configuration that is supported in both modes!), and the
functionality of each mode may be useful to someone depending on circumstances.
Common sense says that a user may very well have a legitimate need to switch
back and forth several times between different configurations, and Netopia's
failure or refusal (we may never know which of the two it was) to provide a
firmware version that combines the capabilities of the R
and D
modes or at least allows users to switch between the two freely constitutes
a criminally anti-social stance.
It is pretty clear that Netopia used modular hardware on the R-series only to ease their own design flow, manufacturing and inventory management, not to present the end user with a modular product. In particular, Netopia's attitude to changing or adding WAN modules in the field was rather paradoxical. On the one hand they used to sell their WAN modules as options intended to be installed into field-deployed R-series and D-series units, either replacing the original WAN module or as a secondary (see below), and provided instructions on how to install them. But on the other hand, Netopia's plastic enclosure design is such that opening it in order to get to the WAN module slots requires a bit of mutilation.
Netopia's plastic enclosure opens and closes like a clamshell, but there
is a screw that needs to be removed first.
The problem is that the screw hole is intentionally covered by the legend strip
that identifies the LEDs, and although it is possible to peel it back carefully
and then press it back on without totally shredding it (that's what Netopia's
wanlet upgrade instructions tell you to do), the result will still be very
obviously mutilated
for lack of a better term.
It is of course perfectly common for products to feature such cover strips
labeled warranty void if removed
or warranty void if opened
,
but in Netopia's case it is hypocritical given that they explicitly sold
WAN modules with instructions on how to install them inside the box.
Aside from the mechanical/cosmetic issues, the user's ability to exploit the modularity of Netopia's hardware is severely limited by the defective-by-design firmware, namely the arbitrary restrictions stored somewhere in flash or NVRAM which instruct the firmware as to which features should or should not be enabled. The main firmware image itself is not the issue: it appears to be exactly the same for all configurations, and one can install the latest and greatest firmware version that supports everything, but the set of available features will still be just as restricted as before.
The dirty bits
telling the firmware what features should be enabled
appear to come from 3 sources:
The R vs. D
flag set at the factory.
Although this ability was never granted to mere mortals, there does seem
to be some way to change this flag outside the factory assembly line.
Netopia's
firmware version history page lists
D7100 to R7100 upgrades/sidegrades
under the same version
in which the D-series support first appeared, and the
R7171 unit that has been donated to us
by MegaPath for reverse engineering
had originally begun its life as a D7100-C, as revealed upon a more thorough
examination.
We suspect that there is a secret feature upgrade key
(see below)
which turns a D into an R; no idea if it is possible to go the other way.
And once again it needs to be emphasized that neither mode is fundamentally
better
than the other, some applications need one, others need the other,
hence it is conceptually wrong to use the term upgrade
for changing
in either direction and it is extremely anti-social and reprehensible for
Netopia to impose this whole situation upon us.
The model number suffix.
When Netopia's firmware displays the model number in the configuration menus, it seems to use the following algorithm to reconstruct it from the physically present configuration:
This suffix appears to be stored in the feature control
area of
flash or NVRAM along with the R vs. D
flag, as both persist through
various swapping of WAN modules.
In some cases this suffix is probably just cosmetic
(this seems to be the case for the -C suffix on units made for CM SDSL),
but there are also cases
in which it appears to control what functionality is enabled or disabled.
It appears that R3100 units for ISDN/IDSL use this suffix to determine whether
the ISDN mode or the IDSL mode is enabled, and for which flavors.
The -T suffix corresponds to units made for Covad and appears to be the most feature-deprived configuration. It also appears that Netopia used to sell feature upgrade keys (see below) that restored some of the features removed from -T units. These -T units are very easy to identify visually because they have Covad's logo instead of Netopia's on the top plastic piece.
Feature upgrade keys.
Netopia's process for unlocking features in their routers involved having
the user give Netopia the serial number (last 3 octets of the MAC address)
of the unit which was to receive the upgrade
, buying the feature key
for money, then entering the received magic code into a special dialog box
in the router's configuration menu.
Obviously the magic codes are some function of what feature is to be enabled and the MAC address. This function along with the list of all possible features can certainly be recovered by undertaking a full reverse engineering (disassembly) of the UMB3 firmware, but the man-years of hacker talent that would have to wasted on that project would be much, much better spent creating a whole new router hardware platform to replace Netopia's instead.
Given a modular platform that supports multiple physically independent network interfaces, one would expect the router software to treat them as logically independent of each other and present them all to the common IP stack. But again this is not the way Netopia's defective-by-design firmware works. Netopia does not seem to have ever supported using the 2nd WAN module as simply another network interface to be added to the overall network picture as one would want to do, for example, if one wanted to connect to two different ISPs simultaneously or to use the Netopia router in a private network application with links going in different directions.
In a rational world there would have been nothing wrong with, for example, putting together an R7172 or an R7271 for simultaneous connection to two ISPs of which one uses CM DSLAMs and other uses Nokia, but again Netopia doesn't seem to have ever supported such usage. Instead Netopia-approved uses for the 2nd WAN module slot appear to be limited to the following two:
dedicatedwanlet like T1, DDS or SDSL in WAN slot 1 to support dial backup. It's entirely possible that a special feature key is needed as well.
When the Netopia motherboard detects a wanlet in slot 2 which it refuses to support for whatever ungodly reason, it includes that wanlet's identity in the reconstructed model number and in the system information screen, but refuses to admit it into the functional configuration, i.e., all menus look and the router behaves as if that second card isn't there. The Ready LED for WAN slot 2 is lit solid red.
It appears that Netopia had served as
Copper Mountain's second reference
CPE
platform after their own CopperRocket, or maybe
even the first for some modes.
Netopia's original SDSL WAN module was actually
designed by CM it appears, and supports only CM SDSL.
Netopia had then built another WAN module for
SDSL/ATM, primarily
Nokia but also supporting generic
Flavor A.
We are not aware of any other SDSL options from Netopia for the R-series.
In particular,
to our knowledge Netopia had no generic
SDSL WAN
module for non-CM and non-ATM flavors, i.e., no generic
Flavor B
.
However, the rival (in)Efficient Networks 5851
seems to have many more different submodels.
Netopia had also supported IDSL with their generic ISDN hardware, although again different models (different packaged configurations) probably offered different artificially restricted sets of configurable options. (Note that CM had built a special wanlet for Netopia with their own microprocessor and firmware only for SDSL. For CM IDSL Netopia had to implement CMCP on their motherboard, and it appears that they did indeed.)