Why_unix_rocks

23 Jul 2002

---

title: Why Unix Rocks date: 23 July 2002 7:58pm

(Original entry here.)

I work on the helpdesk at a small ISP, and we just started selling ADSL. I volunteered to be in charge; I thought it would be lots of geeky fun -- you know, cables and programming modems and ATM cels and stuff. It's turned out to be a huge amount of paperwork instead, but that's another story.

Anyway, we've got these external 3Com 3CP3647 modems that we program with a serial cable and Minicom/Hyperterminal -- basically set up with a password and SNMP so we can track traffic (metered service, I'm afraid). The 3Coms are great, but they're expensive, so we looked at the (also external) GNet BB030 to see how they would work. Everything seemed fine, so we ordered one. It was my job to figure out how to program them.

It came with a pretty explicit manual, which was nice, but it didn't cover everything -- it was a reference, not a tutorial. Eventually I hit a wall and couldn't go any further, so I decided to call tech support. I got as far as "So I wanna figure out how to configure the IP address on the bridge interface --" when the guy on the phone said, "Why not just use the configuration program on the CD?" Well, good point. So I did.

Now, this config program only runs on windows, of course. I use Linux on my desktop at work (the only thing I really need from Windows is the billing software we use; I've got pretty much everything else I need from Windows memorized [ie, about 6 tabs in the control panel], and most of our other work is done on our various FreeBSD servers), and while I can boot into Windows it takes a while, it's a pain in the ass, and I don't like it on general principles. Didn't seem like I had much choice though, so away I went.

The configuration program worked perfectly; it set up everything I wanted. It even kept the commands in a text configuration file -- but when I looked at it, it seemed like it had commands for every possible situation (bridge, routing, NAT; G.Lite, Multi-Mode; SNMP, no SNMP) and it would have taken a lot of head-scratching to figure out which were applicable. "If only," I wailed, "there were some way to just eavesdrop on what's going out over that serial cable!" And then I had a flash.

We've got a FreeBSD box (Pentium, few gigs of HD, I think 48 MB of ram) that we have on ADSL for testing & diagnosing purposes. I took a male-to-male serial cable and ran it from Com 1 on a Windows box w/the config tool to Com 1 on the FreeBSD box. I took a male-to-female serial cable and hooked up Com 2 on the FreeBSD box to the modem. And on the FreeBSD box I typed:

# cat /dev/cuaa0 > /dev/cuaa1 # cat /dev/cuaa1 | tee /dev/cuaa0 > script

And then I ran the configuration tool. FreeBSD handily forwarded Com 1 to Com 2 and Com 2 to Com 1 (forgive my Windows terms and non-zero counting), and kept a copy of what got forwarded in a text file. I was able to see the commands sent by the config tool, and all the responses the modem made.

Now, I have to admit I was pretty damn impressed with how clever I was. It was a hell of a lot easier to do this, and let the configuration tool do its work, than to try and figure it out from the manual. Lookin at the script, I was able to see both that the manual didn't document everything, and that it would be simple to change what we needed to in the script to make it suit our purposes.

But as clever as I was (I bought myself the King-sized Hero Biscuit as a reward), it was really Unix (as represented by its daughter, FreeBSD) that deserved the credit. Such simple ideas:

• Treat devices as a file.
• Don't hide things from a user.
• Let the output from one program be available to be the input to another, or to be written to a file.

And yet these ideas allowed me to save myself so much effort.

I wasn't able to fire up HyperTerminal on the Windows box, and tell it to eavesdrop on what was going out of Com 1; it just said the port was busy. I can't imagine what would be involved in programming something to eavesdrop on Com 1, on the Windows box; I know only enough programming for sysadmin and CGI purposes, and only on Unix -- I've never programmed using the Windows API. But all I had to know to make it work in Unix was a few simple concepts, and a few simple commands, and I was able to fit them together to do what I wanted. I was enraptured by the power it gave me; I still am.

(If I was more ambitious, I'd compare Unix with the plain Lego blocks that you can make anything with, and Windows with the special Lego kits you use to make one thing by following the directions. But I've got to go to work shortly, and anyway even my hubris has limits.)