Setting up a seemingly simple Slip connection turns into a trial by TCP/IP.
by Joel Snyder
If at first you don't succeed, try, try, again. Then quit. There's no use being a damn fool about it. --W. C. Fields
I am very lucky my neighbor Fred is a patient man. If he weren't, I might have to move. A few months ago, Fred called me up and said, "I hear you do Internet." Yes, I suppose I do. I also do dishes and windows, but I'm better at Internet. Fred is no slouch with computers (I counted four in his house), but he wanted a leg up on this Internet thing.
Fred told me that shell access via someone else's computers wasn't what he was looking for. He wanted to be on the Internet, really on, via TCP/IP and SLIP. Fred had figured out that all he really needed was a TCP/IP stack. He had his Web browsers, Netscape and Mosaic, and he had an e-mail package, Eudora. All we needed to do was find a TCP/IP protocol stack that could support SLIP, write a little script to log him on, and we'd be done--in 20 minutes, maybe 30 if we chatted a lot.
So, bright eyed, bushy tailed, and armed with a pile of Windows Internet software, I trucked over to his study to help him set up a SLIP connection and get on the Net. I don't use SLIP myself because I've got a T1 connection. But because all this software worked great on my LAN, I figured it would work great over a SLIP connection as well. It would be a piece of cake. We had phone numbers, user names, and passwords. We had magic beans and we knew the special arcane incantations. We were ready to go.
Fred wanted to start with Internet in a Box. OK. I respect Spry (which developed IBox and is now owned by CompuServe) a lot. It was the first company to really understand the difference between TCP/IP stacks and TCP/IP applications, between corporate users and home users. Most TCP/IP packages are designed for the corporate market, with all kinds of bells and whistles that the mass Internet access market doesn't need. Spry packaged things differently, specifically for the home market. This looked like the perfect approach for Fred.
Unfortunately, we did not fare well with Spry's customer service department. I configured Spry's software to dial up the Internet provider, started SLIP and discovered. . . it didn't work! The software went off into la-la land. I called Spry. They never heard of the problem. I gave them the specifics: user names, passwords, and so on. They promised to try it and call me back. Two months later, I'm still waiting. Fred and I moved on.
NetManage's Chameleon got great reviews and comes in a sample version with many Internet books, so we tried that next. Unfortunately, Chameleon's scripting language couldn't handle the Internet provider's way of showing IP addresses--too many characters or something. I called NetManage. They didn't even want to try to duplicate the problem. They never heard of it, so it must not exist. Maybe if I wrote a letter or something . . .
OK, on to WRQ Reflection. This was a really speedy package when I tried it on Ethernet, plus the terminal emulation was top notch. Unfortunately, as I discovered after a call to WRQ technical support, Reflection doesn't support dynamic IP addresses. If your provider changes SLIP addresses on you every time you call (which many, including mine, do), you have to manually reconfigure Reflection each time for the new address. WRQ was nice about it, but firm. Reflection doesn't do that. It's not a bug, and it's definitely not a feature.
Next up, Wollongong's Pathway Access. Same problem. We press forward.
Superhighway Access from Frontier Technologies is called forth from my floppy to Fred's disk. It was a breeze to set up, worked with dynamic IP addresses, and was easy to configure. Seeing a good thing, I left Fred downloading the newest version of Netscape and slipped (no pun intended) away to my house.
Not So Fast
It had taken five packages and four hours, but he was up and running. All in a day's work. I was beginning to understand why companies like AOL and CompuServe still had a couple of million customers. Who would want to dive from easy-to-use software and no-headaches configuration into this? And I was an "expert!"
Two weeks later I got another call from Fred, who, you remember, is a very patient man. When he told me his machine "locked up once in a while," I knew he was understating the case--a lot, as it turned out. We managed to get his machine limping along for a while as we cruised Frontier's Web site in search of patches. No luck. Locking up once in a while wasn't a symptom for which they had a fix.
In desperation, we turned to Trumpet Winsock. A shareware TCP/IP stack from Tasmanian Peter Tattam, Trumpet has a lot of happy users--and a lot of unhappy ex-users. Trumpet is extremely popular with bargain-basement Internet providers who don't want to pay for one of the commercial TCP/IP stacks. (A side note: If you're one of Trumpet's happy users and haven't paid your shareware fee, do so now. If your provider gave you Trumpet and didn't pay for it, you must ante up or suffer the bad karma of an odious software greedhead.)
I'm always suspicious of shareware, but was willing to give Trumpet a go. After all, we were running out of things to try. Writing a SLIP script for Trumpet took about an hour, and Fred was soon up and surfing away. Last time I looked, his Netscape bookmark list was longer than mine. Case not exactly closed, but at least put to rest for a while.
Trumpet Winsock isn't the perfect answer. Fred reports that it also locks up occasionally, and I had my own bad experiences trying to make it work on our LAN. But I had to be impressed: Trumpet certainly wasn't any worse than the other packages we tried. It didn't have many nifty features or diagnostics and there's no 800-number to put you on hold. On the other hand, Trumpet gave Fred what he needed--something that could support his Web browser and e-mail reader.
OK, software vendors, listen up. There's something wrong with this picture. I tell the story of Fred's patience to people I meet, and everyone has a story about the TCP/IP stack that wouldn't. We know these packages work for some folks, otherwise you'd be out of business. So what's the problem here? Is it the operating system? Is it SLIP or PPP? Is it Netscape or Mosaic or Eudora? Will it go away if I upgrade to NT or buy more memory? I don't know the answer. What I do know is that we're going to have to do better.
You need to have more responsible customer service departments. You need to test with more end-users talking to more service providers in more configurations. You need to make it easier for providers to work with you to build working scripts. New Internet users shouldn't have to go through an initiation ritual just to get their machines working. The Internet is complex enough. Let's make it easier--not harder--to get going.
Joel Snyder is a senior partner at Opus One in Tucson, Ariz.