keithl@vice.ICO.TEK.COM (Keith Lofstrom) (01/19/89)
Yes, I have an Autodialer from Hell. Due to a single digit error in my L.sys file, my modem has been harrassing some poor fellow for months. I'm not the first to make this mistake, though perhaps the first to admit it over the net. In any case, more can be done than just "being more careful next time", such as improving the data logging capabilities of uucico, so that it is easier to tell when the wrong kind of thing is happening. Specifically, all I see in the log file (with a "hayestone" dialer) is "HSM no carrier" when the connect isn't made. That happens if the phone is busy, if there is no answer, or if it answers but gets no carrier. Even for my simple minded modem, these states can be distinguished, and some modems will respond "VOICE", immediately indicating that SOMEBODY IS VERY ANGRY. If the response doesn't make it into the log file, though, I never hear about it; I just assume that the number I am dialing is busy. But how to improve the dialer? Most of us don't have uucp sources, and many have odd machines. I can fix my problem, but I would like to see it fixed for the world (my megalomaniac 60's upbringing, I guess). I suppose what is needed is a public domain version of uucico, so it can be distributed and hacked on. In time, the user community could develop improved error logging capabilities and perhaps a way of turning off phone numbers that never answer with a carrier. One obvious approach is a Unix version of UUPC (?!). Perhaps there are better ways to accomplish the same results (fewer false numbers dialed). Global solutions, applicable to all of us brand-X desktop Unix types, are desirable. Any suggestions? What would it take to get such an effort under way? A contest with prizes? A small donation to a university? Kidnapping a Unix guru? -- Keith Lofstrom ...!tektronix!vice!keithl keithl@vice.TEK.COM MS 59-316, Tektronix, PO 500, Beaverton OR 97077 (503)-627-4052
mdm@cocktrice.UUCP (Mike Mitchell) (01/20/89)
In article <3221@vice.ICO.TEK.COM> keithl@vice.ICO.TEK.COM (Keith Lofstrom) writes: >Yes, I have an Autodialer from Hell. > >Due to a single digit error in my L.sys file, my modem has been harrassing >some poor fellow for months. I'm not the first to make this mistake, though >perhaps the first to admit it over the net. Well, since someone else has admitted it... :-) Actually, I find that when I am adding a new entry to L.sys that it is very prudent to turn up the modem speaker and moniter a couple of connections with the command: /usr/lib/uucp/uucico -r1 -ssystemname -x5 If I get a voice, then it is time to check the entry again. Usually after a couple of successful connections, it is possible to let the machine take it from there. If on the other hand, you are dialing a shared voice/data line, then you will have to arrange the times you can call this number and expect to get a modem to answer. This information should go into the L.sys file too. -- Mike Mitchell BELL: (505) 471-7639 2020 Calle Lorca #43 ARPA: mdm@cocktrice.UUCP Santa Fe, NM 87505 UUCP: ...!uunet!dmk3b1!cocktrice!mdm
dg@lakart.UUCP (David Goodenough) (01/21/89)
keithl@vice.ICO.TEK.COM (Keith Lofstrom) sez: > Due to a single digit error in my L.sys file, my modem has been harrassing > some poor fellow for months. I'm not the first to make this mistake, though > perhaps the first to admit it over the net. > > In any case, more can be done than just "being more careful next time", > such as improving the data logging capabilities of uucico, so that it is > easier to tell when the wrong kind of thing is happening. Since you care about the fact that you may have a bogus phone number, try doing the following (by hand, from a root shell): lakart# usr/lib/uucp/uucico -sxait -x9 -r1 If there is a bad number for xait you will see it, because during the dialing phase you get to see the whole conversation. I did this step with all three of my outgoing links, to make sure that I wasn't going to be whistling dixie up some innocent's phone at 1:25 in the morning. Yours, -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
frankel@corona.megatek.uucp (Allan Frankel) (01/21/89)
We had an L-sys entry with two phone numbers -- if the first didn't answer,
it would try the second. Confirming that connection was made on demand
did not uncover the fact that the second number had been mistyped and was
a private residence. The problem occured much later when the modem on the
first line went out for repair.
Allan Frankel, frankel@megatek or: (619) 455-5590 x2541
ucsd! Megatek Corp.
hplabs!hp-sdd!megatek!frankel 9645 Scranton Rd.
ames|scubed! San Diego, CA 92121ncoverby@ndsuvax.UUCP (Glen Overby) (01/22/89)
In article <3221@vice.ICO.TEK.COM> keithl@vice.ICO.TEK.COM (Keith Lofstrom) writes: >Yes, I have an Autodialer from Hell. Must be a uucp demon :-) >Due to a single digit error in my L.sys file, my modem has been harrassing >some poor fellow for months. I'm not the first to make this mistake, though >perhaps the first to admit it over the net. Jerry Pournelle wrote about doing this several years ago (back when I read BYTE). >But how to improve the dialer? Most of us don't have uucp sources, and >many have odd machines. [ ... ] >I suppose what is needed is a public domain version of uucico, so it can >be distributed and hacked on. I recently helped a friend bring up uucp on his SCO XENIX system. They had a rather elegant solution to the dialer jungle: uucico calls another program to dial the phone. They do give out the source to this dialer program, but since it's an external program with a rather simple set of command line parameters, wouldn't be much to reverse-engineer anyway. So you put all of your nice error trapping in there and thus call your dialer back from hell. I can't recall if there were any "standard" ways of writing to the uucp LOGFILE, but they did pass the debug (-x) level along. GNU UUCP does exist in a rather primitive form. I got a copy from a friend who "found" it when he moved systems (no, I won't send a copy out to anybody). The copy I have hasn't evolved much beyond the "uuslave" program posted a year or so ago. The latest "interim" release of uupc does work quite well, but I think the code in GNUUCP is much cleaner. Ideally the way to FIX the dialer problem once and for all is to create a script language which has rules for operation, and allow the smarts to do all the nice things you want your uucp to do, such as being persistant about a busy line, calm about another system not answering, or go away if a human voice is detected (by the modem, of course). It would also be nice if the entire file transfer protocol could have the smarts to hang up and try again if the error rate was rather high (like on a noisy phone line; even dialing back right away can get you a better line). How can all of this be done you ask? One answer is an expert system. Glen Overby ncoverby@plains.nodak.edu uunet!ndsuvax!ncoverby ncoverby@ndsuvax (Bitnet)