My phone rang early Thursday morning. It was my boss again.
“Can you take a look at the RAS server? I’m tied up in meetings all day so I won’t have a chance to fix it myself.”
The RAS server is a small beige Lucent box. I’d dealt with it on the client side far too many times. I don’t understand the appeal of 28.8 dialup with only five lines, but I guess if you don’t want to pay for Internet dialup, it must just be the greatest thing since Linux.
So he e-mailed me the configuration of the machine, told me the root password, and I was off. It seems to run some kind of embedded Unix, but the command set is extremely limited. Since people were having problems dialing in, I didn’t want to find it was a hardware problem. Using US Robotics Sportster modems, I wasn’t going to rule that out. The Sportster was the best consumer-grade modem out there, but the Courier was professional. Nothing compares to a Courier.
I knew of a couple of US Robotics Courier v.32 modems in the back room. So I plundered them, brought them back to my desk, and started configuring. Then I realized why those modems were in the back room. The v.32 standard was 14.4. It didn’t matter if those old Couriers connected every single time–nobody was going to be happy with 14.4 dialup. So I piled the Couriers–each about the size of a modern laptop, along with a good-sized external power brick–on a corner of my desk and started looking at what I had.
After playing around for an hour or so, I was able to figure out how to get the status and configuration of the modems. And I almost immediately found the problem. The first person to dial in always had problems. Well, the modem on port 0 wouldn’t hold its configuration. I plugged my laptop into an analog phone line. It connected, first try. My modem just didn’t seem to care. I disconnected, and went into the back room. I checked to make sure all the modems were identical and had identical DIP switch settings. Indeed they did. I traced the cables. Nothing looked bad. The modem lights looked fine too.
I played with it all day. It was a true misadventure. Eventually I figued out the modem on port 0 wasn’t responding because there was no modem on port 0. I dialed in and stayed dialed in for a couple of hours. Catching up on e-mail and going to random Web sites at 28.8 wasn’t exactly a delight. Eventually I figured out that we were using an init string for USR v.32 (14.4) and not v.34 (28.8/33.6) modems. The difference was slight: the 14.4 string set register S0 to 1. The 28.8 string didn’t. I had someone who’d been having problems dial in. No problems. And she got better speed than ever before. I couldn’t believe it. Over the S0 register? Why would that make a difference? But if anyone knows modems inside and out, it’s Lucent. Not only do they make tons and tons of modem chipsets, they also make the equipment that all of them have to use to communicate, so while no one’s seen everything, they’ve probably seen more than everyone else. And init strings have always been a black art.
So I left, satisfied. I played out of position, but I found the problem. At least I found a problem, and my solution sounded plausible. My first day troubleshooting a piece of networking infrastructure looked successful.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.
