Even though the CopperRocket was sold as a configurationless user-inaccessible soapbox without any kind of console port, it does in fact have an EIA-232 serial port after all, but it's hidden and accessing it requires soldering a few extra components inside the unit and breaking compliance with some standards.
The serial port is implemented on the 68LC302 processor's SCC2, which puts out a TTL serial interface on two chip pins. PCB traces connect these pins to a footprint for a MAX232 style EIA-232 transceiver, which is not populated on the standard unit. If you populate the missing EIA-232 transceiver, you'll get a true EIA-232 serial port, but where is it wired? There is no DB25 or DE9 connector anywhere in sight, right?
At first I thought that the EIA side of the MAX232-style chip wasn't connected anywhere useful, so I had soldered wires directly to the pads. Further investigation has revealed however that the EIA-232 port is wired by PCB traces to some otherwise unused pins of the Ethernet jacks! At first I was bewildered at how CM could get away with doing this (co-opting the unused pins of a standard interface like Ethernet for some totally unrelated purpose is generally a bad thing), but then I got it: an unhacked CopperRocket as shipped by CM does not have EIA-232 on unused Ethernet pins, it just has those pins connected to an unpopulated footprint on the PCB, which is completely harmless. Populating the EIA-232 transceiver chip gives one access to the hidden debug port, but it also makes the unit's Ethernet interface unclean.
The CopperRocket has two Ethernet jacks wired in parallel: one is wired as a station port and the other is wired as a hub port, so you can have whichever way you want without needing a crossover cable. But this only concerns the active Ethernet pins 1&2 and 3&6, or the orange and green pairs in the standard cable. What about the other pins? Pins 4, 5, 7 and 8 are not used by 10BaseT Ethernet, and the last 3 of those have been co-opted for the EIA-232 debug port on the CR201. Pin 8 carries serial output from the unit, pin 7 takes serial input to the unit, and pin 5 is used for ground. The latter is also unconnected in the standard unhacked unit: it goes through a zero ohm resistor, which is of course also normally unpopulated.
As I have discovered empirically, once the EIA-232 transceiver has been populated on a CR201 board, it is no longer safe to connect it with a standard Ethernet cable to any random hub. One would think that 10/100 Mbps hubs/switches (i.e., non-Gigabit ones) would leave the extra pins alone, but apparently they sometimes do something else with them — short or ground maybe? Therefore, you need to use a cable that connects just the two active Ethernet pairs, but not the other two. You can either make your own cable or sacrifice one from a store and mutilate it by cutting the unwanted pairs.
The serial hack
pins are wired identically to both Ethernet jacks,
so use whichever one you want for Ethernet (with a 10BaseT-only cable), and
the other jack will be your serial port.
When you make your serial cable, connect only the 3 pins used for the serial
port on the CopperRocket end.
I do not recommended crimping all 8 wires on the CopperRocket end and selecting
the 3 serial ones on the other end; the Ethernet pins are connected in parallel
on both jacks and bridged tap can't be good for Ethernet.
If your CopperRocket is of the same hardware revision as ours or sufficiently close, you should see an unpopulated SOIC-16 footprint at reference designator U17 in the Ethernet area of the board, surrounded by similarly unpopulated pads for 4 surface mount capacitors. This is the classic MAX232 style EIA-232 transceiver, converting from TTL to EIA-232 voltage levels.
To enable the debug serial port you need to populate the missing EIA-232 transceiver and its caps. Use a 5V part in a SOIC-16 package. I've put an LT1381CS with 0.1 uF caps on ours. This addition by itself will already taint the Ethernet ports, so you may as well finish the job by populating the zero ohm resistor for the ground connection.
The zero ohm resistor is an 0805 at reference designator R4. It's located directly behind the Ethernet jacks between the Ethernet magnetics and the big electrolytic cap at the power input.
With these modifications you don't need to solder any blue wires, just populate some extra components into already wired footprints on the PCB. You can then put the board back into the enclosure and close it up, but you should mark the unit and note that its Ethernet ports are no longer clean.
There is also an unpopulated footprint nearby for a 3-pin header, reference designator J12. It looks like another way to connect to the serial port, but it isn't wired to the EIA pins. Its outer pins are ground and +5V, and the middle pin is the TTL TxD signal (not EIA-232). This connector seems to be intended for getting the debug output without populating the EIA-232 transceiver on the board.
As we now know, there is a serial port. However, the statement that CR201 has no console control or configuration capability is still true. The standard firmware does not listen for any input on the serial port and only sends debug output, thus at least as long as you stick with the original firmware and the original overall device function, the serial port is best described not as a console port, but as a debug output port. The settings are 9600 baud, 8 bits, no parity, 1 stop bit.
The debug output is quite verbose and includes BT software TDEBUG on the CR201s. If you want to see the CopperRocket's debug output but don't feel like soldering, you can look at some we've captured. This output was captured from our CopperRocket connected by a very short loop to our Netopia D7100-C sitting on the same tabletop and configured for HTU-C operation. The two devices sync up and show link OK status, but then keep shutting the link down and re-establishing it. I originally thought that my table-sized DSL loop was making them unhappy, but this debug output suggests that the CopperRocket gets worried about seeing no Ethernet packets from the HTU-C and decides to shut down the link and restart.
Even though the debug port is output only for the standard firmware, the Rx path is perfectly good in the hardware. The debug output port has been turned into a bona fide console command port in our Hack-o-Rocket.