When one is faced with a device like Netopia's R-series and D-series whose firmware is defective by design, the right thing to do is to either put new free & open source firmware on the gadget, or make a new hardware product altogether that functionally supplants the old crippled one. In the case of Netopia's pseudo-modular router platform, I strongly prefer the latter approach (designing and building new hardware, not just software) for the following reasons:
UMB3 has an MMU-less processor (68MH360), 1 MB of flash and 4 MB of RAM. It's plenty enough to write an ad hoc router firmware suite, but I would rather not go that direction: aren't there enough substandard router software designs already? I would much rather use Linux or BSD running on a PowerQUICC as my foundation.
Reverse-engineering enough of UMB3 just to run the most basic software of our own on its processor would already be a pain.
Reverse-engineering and implementing the highly ad hoc interface to talk to the wanlets would be even more pain.
Developing a fully modular & open source software suite only to have it forever limited to running with the selection of old Netopia wanlets at the mercy of the surplus market would be grossly unfair.
The most important reason: if we design and build new hardware of our own, the economic reward in the form of volume hardware sales to ISPs would go to us, the people devoting an insane number of man-hours to the cause of making the core network infrastructure Free as in free speech, rather than to surplus equipment dealers reselling crap made aeons ago by unworthy companies like Netopia.
I see nothing wrong with making some money selling hardware to larger companies like ISPs as long as all software and even the hardware design source files remain absolutely free.
The Netopia replacement product the design for which I already have in my head will be based on a Freescale MPC86x PowerQUICC processor running Linux or BSD. This processor is a more powerful successor to the M68K QUICC used by Netopia (68MH360), and it has 5 network interfaces on chip: 1 Fast Ethernet Controller (FEC) and 4 Serial Communication Controllers (SCCs) similar to those in the 68MH360. Having the FEC means that we no longer have to lose one SCC for Ethernet, so all 4 SCCs will be available for WAN connections. Instead of arbitrarily dividing these SCCs between internal wanlet slots with RJ45 outlets and an auxiliary port like Netopia has done, I will bring all 4 SCCs out to 4 identical daughtercard connectors, and each SCC daughtercard will come out to the rear panel of the enclosure to provide whatever external connectors are appropriate.
The first SCC WAN daughtercard will be a glue module for a standard synchronous serial external interface; we'll use the OSDCU for SDSL connections and common DSUs from the surplus market for T1 and DDS. Later SCC daughtercards with integrated DSUs can be made for those WAN media types that are in most demand.
Please see this page for more information.