Last night, my mother called to ask her computer son some questions. It seems that her cable modem wasn't working, she'd been on hold for half an hour without hearing anytheing resembling a human, and she hoped that I might know what the problem was.

Now, first of all, I don't mind doing things like that. Anyone who works with computers in any capacity gets used to family members asking questions; I was used to it before I left high school.

Second, this cable modem is a USB-connected modem. Say it with me folks - "serial devices should not be used as network devices". That's not what they're for. Granted, a bad precedent was set with modems; people got used to connecting to the 'Net through serial devices. That doesn't make it a good idea. But, the cable company wants to squeeze a few more cents out of each customer, so they insist on making the modem as cheap and easy to use as possible; so by making it a USB plug & pray device, they hope to cut down on support calls and make it cheaper by not requiring a nasty ol' network card - which makes installation easier, too.

Anyway, I did the usual - are the modem lights on, are they flashing, are the drivers installed, unplug the modem and plug it back in, etc. Nada. Since I couldn't be there to actually look at the modem, that was about the limit of what I could do; I sent her on to talk to tech support again. I know, it's a cruel thing to do to one's own mother, but I didn't have many options in this case.

A while later, the phone rings again. Mom tells me that the helpdesk person has decided the USB ports were zapped by a lightning bolt. Excuse me? Yes, they'd had a storm the night before (no big deal for early June) and a lightning bolt had struck close to the house; the power had flickered, and the TV and computer had both shut down, but they hadn't noticed any other problems. Now, however, they'd discovered that in addition to the cable modem, the USB webcam was also dead - or at any rate, it wasn't working. The technician had decided that the lightning bolt had sent a power surge through the cable line, through the modem, and to the PC.

Now, if true, this angers me. The computer is on a surge supressor for the power line, a quite good one. The modem, if they had a modem, would also be. But nobody makes a surge suppressor for coax. (Don't bother sending me catalog pages... you know what I mean. Consumer-level.) Why does the cable company not protect their customers' equipment from these power surges? The USB ports on the computer are integrated with the motherboard; to replace them, I'm going to have to replace the system board. (Yes, I could install an add-on USB card, but I'm also concerned about collateral damage to other systems on the board.) Would it be that hard to include a simple surge supressor in the cable modem? No, it wouldn't. But it would increase the unit cost. And, hell, we can't have that.

Anyway. Enough of that.

Fido. Fido is the name of my Downtime-derivative. Why Fido? Because Watchdog was taken. <G> I've made more progress; my version of the installation script is about complete, and I've defined all the subroutines for the main script. I have decided to add one bit of functionality for 1.0; the original version simply accepted a list of IPs to ping for connectivity. I've changed it to monitor two separate lists of IPs; one, a list for connectivity. Those IPs are intended to be the "other side" of gateway links; stored in a hash of the IPs will be the X10 device code for that IP. So if you have a T1 link and a DSL backup link, you can ping them separately and use separate X10 devices to turn them off and on without affecting the other (unless, of course, you use the same router for both links.) The second IP list is for *hosts*; Fido will ping a list of boxes and log any downtime. No X10 device storage for those; there're better methods of dealing with a down network link than rebooting the box, don't you agree? Later versions will do more than just ping, they'll keep a list of services to check for on each box.

And, last but not least, I finally found my AutoCAD cd tonight. Never having found a satisfactory CAD solution for Linux (yes, I've looked at qCad, and yes, my opinion remains unchanged) I was happy about this. Except, of course, that I no longer run Windows on my workstation. Hmmm.

As we speak, Minerva is setting up a VMware workstation 2.04 installation with Windows 2000. AutoCAD goes on first, but I may add a few other things as well; I haven't had a good game of CivII in far too long... <G>

Well, it's time to install the VMware tools. See you later.

Tuesday, June 5 - Return of the Camel

No, I'm not taking up smoking again - in fact, in order to take up smoking "again" I'd have to start, stop, and then start again. No, this camel is the Perl camel. I've had a couple of projects percolating in my head, and I finally sat down and started on them last night.

The first is my old modification to the Downtime script. I've not been able to find the maintainer of the original version, and the script was GPL'd... and then, not too long ago, someone asked me if I was the new maintainer.

Uh.

Well, no, I can't say that I am. I mean, I'd really kind of need to talk to the original maintainer before I could become the new one, right? So instead, I pulled the code out to see what it would take to clean it up a bit. Well... apparently I've grown as a Perl hacker since the original modification. I started thinking about it, and I've decided that I like the basic layout - the installation script and the running script, the log file system and the basic options that the script offers. But I can clean it up considerably, and there are some other features I'd like to add. For example, the original script simply monitored a network connection, and alerted you when it died. I modified that to use an X10 controller program to disconnect and restart the modem/router when that happened. This was a good thing. Well, I want to add a couple of routines to watch for services on the local machine or on remote servers. Specifically, I want it to check ports 25 and 110 for email services, 53 for DNS, 22 for SSH, and so on. That way I can run the script on one system, and let it monitor the whole network - notifying me in the event of a problem, and taking rudimentary steps to fix the problem (such as restarting daemons, using X10 on the router, things like that.)

On top of that, I can replace the whole "use an external program for X10" thing with a couple of Perl modules - ControlX10::CM17 and ControlX10::CM11, specifically, depending on the controller in use. I can also clean up the notification system, I think, and move things around a little bit. I'm hoping my new version will be 25% shorter with no lost functionality, and later versions will add in the services-monitoring modules.

When 1.0 is finished, I'll post the program here; since it's a derivative work of Downtime, I'll have to release it under the GPL. Shouldn't take all that long to finish, I think. More tonight, until then, have a good one.

Monday, June 4 - Didn't We Just have a Monday??

Column's up, on How To Design a Network - the short & not-much-detail version. I'd like to write up a full, detailed HOWTO - several people have asked - but there's just no way that I can think of. It would be longer than The Linux Book that Tom & Brian Wrote. On the other hand, it's something that enjoy doing, do fairly well, and don't do much at work anymore. The solution, of course, is to offer my services to those who could profitably use them. So I will. As I said at the end of the column; if it's a question of some sort, or a relatively small problem, I'll answer it for free. If it's not, I'll take on the job for a fee - negotiated on a case-by-case basis. Catch me in a good mood, I may do it cheaper. <G> If you don't want to pay for the work, then I'll just do my best to point you at a good source of information, nd wish you good luck.