The Big Sleep, or a Short Nap

US Robotics ‘Fesses Up To Big ‘Pause’ Problem

(with apologies to Raymond Chandler)
Originally published in BugNet, October 1996

IT HAD BEEN a slow day at the BugNet Detective Agency, and I was about to close up shop when in walked a case that had “Big” written all over it.

US Robotics, one of the most-respected modem manufacturers in cyberspace, was being accused of selling modems with a serious problem. What was worse, many people were saying that they had known about it for months, but went on selling the bad modems anyway. Clearly, this was an issue that begged to be brought to justice.

Word on the street was that there was a bug in the US Robotics 28.8 Sportster V.34 chip set that caused the modem to unexpectedly doze off. The modems worked fine when they were dealing with a steady stream of data, like downloading a file or a web page.

But if they were faced with intermittent bursts, such as you get when logged on to a BBS or a chat room, they would pause for anywhere from thirty seconds to three minutes. Not quite “The Big Sleep,” but more like a lot of annoying little naps. The modems in question had chip sets dated from 10/18/95 to 3/4/96.

So, I thought, bad chip sets have hit the market before. It was maybe a little surprising to see a respected name like US Robotics involved, but let me tell you, Sweetheart, it happens in the best of families.

What really got my attention was the allegation that USR had known about this since March, and had been stonewalling its customers over updates and/or information. Some really persistent customers seem to have gotten an exchange, but most people couldn’t get much more than the time of day.

I DECIDED to check it out. First, I went over to comp.dcom.modems. The USENET neighborhood is pretty rough and tumble, but you never know what might turn up. When I got there, you would have thought I was back in the LA riots, with so many nasty flames erupting between the pro- and anti-US Robotics forces.

Next I headed over to one of the victim’s web sites, Kenneth Chen’s. The pieces were beginning to come together by the time I arrived at the US Robotics site in the quiet, upscale part of town. They let me poke around, but they certainly didn’t have any evidence lying there on a silver platter. So it was time to call it a night. Who knows, a fresh start in the morning might make a difference.

Maybe it was all a coincidence, or maybe they heard that BugNet was on the case, but it all broke open the next day. It wasn’t on the front page of The Times,but it was there if you knew where to look. On the US Robotics forum on CompuServe was a file called “Update.Txt.” On comp.dcom.modems was a posting called “Sportster Update Information”. And back at the US Robotics web site, if you followed a link called “Sportster Supervisory Update Information” you ended up at

Their story was that, yes indeed, some of their modems may just possibly sometimes stop sending data, but that it is “a fairly isolated occurrence.” (Remember, the first step is to admit you have a problem). While they call it isolated, their note comes with a long list of products that may be affected, along with information on how to get either an upgraded chipset or a replacement modem.

Meanwhile, I discovered a work-around that has helped some: go into terminal mode with a program like Windows Terminal, Procomm, or Qmodem, and set register S12=0.

I wasn’t going to wait around and see if US Robotics and their customers had a tearful reunion scene, or if the recriminations were going to last for awhile. At least the two sides would have something to talk about. And it was time for me to move on to the next case.