Book Review – CoCo: The Colorful History of Tandy’s Underdog Computer

I recently picked up a copy of “CoCo: The Colorful History of Tandy’s Underdog Computer”, written by Boisy Pitre and Bill Logudice, charting the evolution of Tandy’s TRS-80 Color Computer line. The book mainly covers a period from the inception of the value-oriented product line in 1980 through to the cancellation of the Tandy CoCo 3 in 1991. However, it also touches on Tandy’s beginnings as the Hinckley-Tandy Leather Company, it’s ownership of the Radio Shack chain through which the CoCo was sold, and the CoCo’s origins as the VIDEOTEX text terminal.

As the home computing market of the 1980s was characterized by fierce competition and a seemingly endless number of hardware models and platforms, I was happy to be going into this history with a bit of personal context. My first PC was a hand-me-down CoCo 1, received in 1994, and I have some fond memories of it’s unique look and feel. The computer was simple in appearance and operation for a novice, and I had no trouble picking up the nuances of Color BASIC, even if I may have spent more time fiddling with RF modulator to keep a consistent image on my old TV. With that being said, I was largely unaware of the unit’s backstory, and I was surprised to read how well-supported and influential the CoCo line would grow to be.

There’s a lot of information to be packed into less than 200 pages, and the book sometimes feels like more of a broad survey than a detailed history, especially when dealing with the significance of software releases for the line. However, Pitre and Logudice make a point of concisely covering all aspects of the unit’s impact on the computing scene of the time; be it the hardware design, Tandy’s notorious approach to cost-cutting, clones such as the Dragon 32, or the surging third-party developer community that sprung up as users began to flock to the platform. Additionally, the book includes a large selection of color images featuring marketing materials, advertisements, screenshots, and photos of the hardware and software.

I felt like this book worked especially well as a snapshot of the CoCo user community. Falsoft’s RAINBOW magazine was documented extensively, as was the rush of ill-fated user-conceived CoCo 3 successors following Tandy’s official discontinuation of the product line. As this sort of information relies on the memories and accounts of those involved, it can be especially fleeting compared to the more readily available details regarding Tandy’s side of the CoCo canon, and the authors’ efforts to preserve this history are appreciable.

Overall, I’m of the opinion that hardened CoCo veterans may find this effort a little more rewarding than more casual readers/PC history buffs. While there are many great ancedotes to be found throughout, I feel the story of the CoCo series tends to pale a little compared to its 80s contemporaries, lacking the sheer industry-wide impact of Apple or hubris of Commodore. Regardless, the book breezes by, and the vast amount of insight to be found relating to the machines’ development and marketing should still spark some interest in nostalgists and neophytes.

You can buy a copy of the book here.


Mistakes We All Make #2: One Man’s Trash..

A recent CBC news story detailing the recovery of a 30 gigabyte hard drive containing personally-identifiable information of military personnel at a local recycling depot compelled me to share a similar experience regarding improper disposal and sanitation of IT assets.

In my previous article, I described how I had begun to build a CCNA test lab to help in my studies, including a a few 2651XM routers that I purchased from a wholesaler via eBay. While exploring their file systems and experimenting with backup and restore through TFTP, I happened upon a curious text file in the root directory.

It became quickly apparent that this router was once owned by a major US telecommunications company and contained its share of information that the organization would likely prefer to keep private.

In this case, the evidence existed not in the unit’s startup config (which had likely been erased both by the telecom and the wholesaler prior to the router being re-sold), but in a file labelled with a .old extension, suggesting it had been used as a backup before a configuration change was made.

From this configuration, I could determine:

– The name and username of the user who edited the configuration file

– The hostname of the router.

– A long list of sub-domains associated with the company’s domain name.

– The IPs of the name servers being used.

– The fact that the user used TACACS+, the IPs of the TACACS+ servers, and the key being used.

– Telnet and console passwords, using level 7 encryption that was easily broken. To the admin’s credit, the passwords were technically strong in their use of a larger keyspace through upper-case/lower-case/numbers/symbols. However, they were very generic, and I would not be shocked if they had been re-used across network devices.

– The hostnames to which each port on the switch connected (left in the description of the interfaces) and the VLANs with which they were associated.

– The IPs of logging servers.

– A long list of permitted IPs in the unit’s ACL.

– SNMP community strings.

– The physical location of the router, as specified in the EXEC banner. (Cross-referencing this information through Google resulted in quite a few contact telephone numbers.)

A couple of years have passed since the router was decommissioned, but even if only one or two items in this list are still relevant, they clearly compromise the security of the network in question.

Nowadays, most users are aware that data can be recovered from a hard drive or SSD, and are careful to securely dispose of these components. However, non-volatile storage extends beyond the scope of these examples, and not everyone will make similar considerations when dealing with devices such as the aforementioned router.

Furthermore, even if the a component doesn’t contain any personal information or financial data, these details can form the basis of further attacks centered around social engineering, or tip off attackers to probable vulnerabilities. Poking around a switch or router isn’t likely to give an attacker any credit card numbers, but it’s an awfully strong first step toward doing so, if this is one’s intent.

It’s easy to find even more egregious examples in the consumer electronics realm. Consider how many cell phones get tossed to the curb without a second thought once their users accidentally smash the screen or kill the battery, and instead decide to move to the latest and greatest model. A Playstation or XBox found at a pawn shop might contain cached login credentials, friend lists, purchase histories, and saved network profiles. Wherever non-volatile storage exists, the potential for exploiting its contents exists as well. Even if this information is encrypted and seems secure at the moment, there’s no telling if it might become accessible in the future.

Of course, if you’ve been tasked with operating a computer in the last 20-30 years, this is likely a speech that you’ve heard many times before. However, this sort of advice need not be exclusively aimed at those who Post-It their login credentials to their monitor, or those whose password is “password”. As professional responsibility increases, so does the of the information that is handled, and everyone is well-served to pay mind to an occasional reminder of the consequences of lazy or short-sighted security policies.

Mistakes I Made #1: The Quest for Ping

Here’s one in a series of many stories of failure, frustration, and figuring things out.

I’ve been studying for Cisco’s CCNA certification recently and decided to purchase some older gear in order to set up a test lab, familiarize myself with IOS, and get used to the the physical wiring/configuration of these devices. Thus far, I’ve had some fun putting everything together, learned a lot in a short span of time, and I can still afford rent. My first router came in the mail the other day, so I figured I’d set up a basic layout in order to test its functionality.

The goal was simple enough: 2 hosts (a Windows 7 laptop and a Raspberry Pi running Raspbian), 2 2950 switches, and a 2651XM router in the middle. Set them up, ping back and forth.


Simple enough, right? If you answered “yes”, congratulations on being as arrogant as I was. This simple setup threw me for a loop, taking several hours to properly configure and causing me to question the hardware involved, basic routing and networking theory, and my sanity in general.

With a plan in place and success assumed, off I went. Console to each switch, config, console to the router, config. I assigned IPs to the router’s Ethernet ports, defined my routes. Interfaces are up, green LEDs everywhere, I’m good to go.

And then I ping, and then it fails. So I ping from the other PC, and it still fails. Hmm. Basic network troubleshooting skills kick in, and I start pinging out from the host to each successive link. At both sides, all goes well until pinging the router’s external interface, the point where the two networks connect and my packets fall off a cliff. This doesn’t make sense! Those interfaces are physically connected. How could the router be so stupid as to not know how to direct the requests? I check the routing table, all looks well. I run out of ideas and begin to gradually cycle between the stages of the Kübler-Ross model of grief.

To make this whole process a little easier, each PC also had a wireless interface connected to my home network, enabling me to SSH/TeamViewer in to either. This was my first mistake. As the host had no idea where the 192.168.3.x network was, it was sending the ping requests out of the wrong interface.

Previously, I had set up an IP for the management VLAN on each switch, which ended up being helpful in solving the last few pieces of the puzzle. I hopped back onto the switches and found that once I had the default gateways properly configured to the router’s connected interface, I could ping between the switches, crossing the router. OK, so the router’s good, switches can communicate, but pings from the hosts stop at the router’s internal interface, and pings from the switch to the host stop at the switch on the other side. Feeling defeated and figuring I’d probably be a networking philistine for the rest of my life, I decide to sleep on it. I wake up the next morning, the eureka moment hits, and I scramble back to the PCs.

I configure static routes from the PCs to the router’s internal interfaces for the networks needed.

Ping from the Windows PC: Great success!
Ping from the Linux PC: Great fail!

Wait, what?

I double-check the route, it looks OK. I’m perplexed. I start to wonder if the guys from “Windows Tech Support” that keep calling me can actually help out on this one.

Here’s my second mistake: I’d become so conditioned to pinging within the same subnet on Windows machines that I assumed it also worked the same way for pinging from an external network. This is not so. Windows Firewall blocks ICMP echo requests from external networks, which is required to ping from external hosts. This explains why I was able to ping from the adjacent switch and router, but not across the router’s interfaces.

Windows Firewall > Advanced Settings > New Inbound Rule > Custom Rule > Protocol Type > ICMPv4 > Any IP > NextNextNextNextNextNext problem solved. I am now a hero in my own mind.

What are the takeaways from this ordeal? A. Consider how the hosts will rout if multiple interfaces are configured and share a default gateway without any static routes. B. Consider how different operating systems react to traffic and requests. C. Question the obvious. D. Don’t get cocky.