jbm@uncle.UUCP (John B. Milton) (06/14/88)
Well, I got tired of the phone junk crashing my system all the time, so
I took drastic measures:
I removed (deinstalled): phone manager, ate (async_main)
Lo and behold there was a problem: After all this I could only use line
two pulse. Grrrr
Part of the deinstall of ph change /etc/.phinit from "ph" to ".phclr"
The program .phclr is a stupid piece of trash. It is supposed to read the
.lineone and .linetwo files and use this info to tell /etc/phupd how to set
the phone lines. .phclr then sits there like a nice little doggie and makes
the phone manager window blank instead of grey.
Ahh yes, the trouble. Apparently .phclr only processes the first .linexxx
files it runs into and ignores the second. I have two phone lines, voice
on ph0 and data on ph1. Both are touch tone lines. When .phclr finds and
does .lineone, it quits. To get around this bug, I replaced phupd with a
program that prints it's parameters, then used the info to change
/etc/.phinit
-> from:
/etc/.phclr
-> to:
# /etc/.phclr HA HA HA
/etc/phupd ph0 VOICE YES NO NO
/etc/phupd ph1 DATA YES NO NO
Anybody else been through all this and came up with a better idea?
As many of you who are scratching your heads about why this doesn't
match your system, it's because I am running 3.51
I think its about time for us to write a replacement phone manager.
John
--
John Bly Milton IV, jbm@uncle.UUCP, {ihnp4|osu-cis}!n8emr!uncle!jbm
home: (614) 294-4823, work: (614) 459-7641; talk to me about fractalsgil@limbic.UUCP (Gil Kloepfer Jr.) (06/16/88)
In article <293@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: |>Well, I got tired of the phone junk crashing my system all the time, so |>I took drastic measures: |> |>I removed (deinstalled): phone manager, ate (async_main) |> Me too... see below... |>I think its about time for us to write a replacement phone manager. |> |>John Bly Milton IV, jbm@uncle.UUCP, {ihnp4|osu-cis}!n8emr!uncle!jbm |>home: (614) 294-4823, work: (614) 459-7641; talk to me about fractals Yes...but even more important -- examine the operation of the /dev/ph* phone DRIVERS. In the middle of an OS already stranger than many of the unices out there is a piece of bug-laden code which can and should be fixed once and for all. So far, the bugs I have experienced simply because either the driver or the phone management/uucp software (I believe it is the driver) is brain- damaged is: 1. sometimes the line that the handset becomes connected to misteriously becomes line2 (my data line) and reaks havoc with incoming calls, 2. my internal speaker will somehow remain (become) connected to my data line (line 2) and incoming modem signals will be heard (loudly) through the internal speaker. This usually happens when I am not at home, and annoys the folks in the apartment below, 3. processes associated with phone management die or become confused. I'm sure that there are more problems from various folks out there. One more point of clarification -- a lot of folks have been beating the OBM (on-board modem) to death on the net, as well as port tty000. Please folks, the hardware is not at fault. In fact, the hardware as I've seen it (through schematics, of course) is very flexible and has the capability to do what you want without problems. The problem as I see it is the SOFTWARE (ie. the OS). My belief (perhaps incorrect, anyone care to modify/add to this?) is that the /dev/ph* and the i8274 driver bugs need to be collected and fixed. Fixed means that they are debugged, no bugs. After these are fixed, I think that many folks would see a marked improvement in the performance of the phone management software. Of course, let's not stop here -- the net has been a good source of bugs which need to be fixed. If nobody else wants-to/is-able-to fix these bugs, I'd be the first volunteer. Send me the source code to unix :-). Can you believe that the OS in this machine is really written to act as a "safe" interface between user and hardware? +------------------------------------+----------------------------------------+ | Gil Kloepfer, Jr. | Net-Address: | | ICUS Software Systems | {boulder,talcott}!icus!limbic!gil | | P.O. Box 1 | Voice-net: (516) 968-6860 | | Islip Terrace, New York 11752 | Othernet: gil@limbic.UUCP | +------------------------------------+----------------------------------------+
rjg@sialis.mn.org (Robert J. Granvin) (06/18/88)
>One more point of clarification -- a lot of folks have been beating the >OBM (on-board modem) to death on the net, as well as port tty000. Please >folks, the hardware is not at fault. In fact, the hardware as I've seen >it (through schematics, of course) is very flexible and has the capability >to do what you want without problems. The problem as I see it is the >SOFTWARE (ie. the OS). tty000 problems are purely software. The driver(s) were brain damaged, but for the most part have been repaired. Expansion boards, if they have problems are predominantly hardware problems. Although the fix is incredibly trivial. Replace a chip. Of course, if you still have brain damaged drivers, then you'll still not be able to use the ports to full capabilities, even though your machine won't crash quite as seriously. The OBM is another issue altogether, though. Sure. The OBM has had its problems as well because of software. A lot of it was attributed it to a brain damaged (that term is getting used a lot :-) uucico. While not much more intelligent, the uucico fixes have made a marked improvement. But let's take it a step further... A lot of modems out there recognize the OBM as an 1200 baud MNP modem. Believe me. It's not. A lot of modems out there are also fully capable of connecting with any brand of modem providing any "legal" carrier tone. But wait a moment... Then there is the 3b1 and the OBM. All of a sudden you might have discovered a modem that you cannot connect to. This is not OS related, but is hardware related (of course, depending what you consider firmware, that point is debatable :-) Many modems will connect fine, but many will not. Even Telebit Trailblazers under one type of configuration will connect to every available modem (apparently :-) but will always fail on a 3b1 OBM. A different configuration which isn't necessarily as optimum or efficient, works in all cases. While the OBM may not be completely the guilty party, it is certainly at least an accomplice. Even the best hardware is only as good as how well it operates. In many ways the OBM works better than a lot of commercial modems, but in other ways, it leaves a lot to be desired. Anyways, that's all subtopics. There are a lot of software items that should be fixed or at least notably enhanced, but don't expect anything from it. ATT isn't going to put a lot of effort to fixing something that works (even if it doesn't work well, it still works), and source is practically impossible to obtain (even certain sections of ATT's 3b1 support groups weren't able to get the source for a long time...) (Although, not to be unfair - for the past several weeks, I've been keeping in touch with a very small subset of technicians, keeping tabs on the current state of some repairs and reporting new problems as they are made known. While not everything may be repaired, these techs are handling the items very well (surprisingly, at times. And no, these are not the "phone techs" which I have had some very frustrating experiences with). These people are taking serious issues with the seriousness it deserves, plus they perform what is normally considered a reasonable test period. The advantage is that the updates or fixes released are more than likely solid and complete. The disadvantage is that you have to wait, and normally can't find out what's being repaired...) -- "I've been trying for some time to Robert J. Granvin develop a life-style that doesn't National Information Systems, Inc. require my presence." rjg@sialis.mn.org -Garry Trudeau ...{{amdahl,hpda}!bungia,rosevax}!sialis!rjg
wtm@neoucom.UUCP (Bill Mayhew) (06/19/88)
As far as I know, the chipset used in the On Board Modem is the same chipset that is used in several of the AT&T 22xx series modems. On the machine here, OBM doesn't seem any better or worse than any other 1200 buad modem (we have terrible fone lines, and noise is copious on anything without error correction and baud rates above 300). The Reason MNP modems get goofed-up calling the OBM is the same reason that MNP modems get goofed-up calling a Hayes Smartmodem on a Vax. (Yes, they do.) Apparently, getty politely echoes back the querry string from the originate modem as it tries to establish MNP handshake. The querry string being echoed back seems to be enough to trick the originate end into thinking that the answerer is MNP when, in fact, it is not. You can probably duplicate this experiment yourself by calling a Hayes Smartmodem or clone thereof on onther extension in your office with nothing plugged into the RS232. The Hayes should be set to autoanswer. Call it with your favorite MNP device (Trailbalzer, or whatever). The origninate modem should negotiate a non-MNP connection. Now, connect pin 2 to pin 3 on the Hayes by sticking a piece of wire in the Holes. This should simulate getty-babble. Call the Hayes again. Sha-zam!, it should look to the originate modem like it just established a valid MNP link. I guess you could say that if anything, getty is to blame. More correctly, perhaps, the MNP protocol is to blame. One way to fix the problem would be to hack the getty source (outta luck about this idea on the 3b1!) so that getty keeps its mouth shut until it gets a character from the originate side that is not part of the MNP handshake sequence. The other solution is to get a real MNP modem and stick it on tty000, and use that instead of OBM. With the idigienous icky UUCP software on the 3b1, tty000 works much better than OBM anyway. As far as poor OBM support goes, people that I know who are using the Honey DAN BER UUCP kit report that many of their problems with OBM seem to disappear with HDB. Too bad AT&T is sitting on it. I'd really love to know what the politics of not letting us have HDB are. I for one would pay $$ for it, as long as it didn't cost as much as the whole O/S or something. (Re: $495 for the EIA board! I bought a 2-port EIA board for my P.C for $39. Economy of scale I guess.) It suppose putting HDB on ths store (for free) conflicts with policy, since HDB is for sale as part of BNU for some of the other sytems. People paying for HDB as part of BNU might be offended. C'est la vie. --Bill for this week: impulse!wtm@neoucom.UUCP
nic@dworld.UUCP (Nic Bernstein) (06/22/88)
In article <1259@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: >The Reason MNP modems get goofed-up calling the OBM is the same >reason that MNP modems get goofed-up calling a Hayes Smartmodem on >a Vax. (Yes, they do.) Apparently, getty politely echoes back the >querry string from the originate modem as it tries to establish MNP >handshake. The querry string being echoed back seems to be enough >to trick the originate end into thinking that the answerer is MNP when, >in fact, it is not. > >One way to fix the problem would be to hack the getty source (outta >luck about this idea on the 3b1!) so that getty keeps its mouth >shut until it gets a character from the originate side that is not >part of the MNP handshake sequence. > >--Bill > for this week: impulse!wtm@neoucom.UUCP Not too terribly long ago, maybe 5 or 6 months, someone posted a program called `uutty' to comp.sources.unix, which was able to deal with verbose modems like this. As a matter of fact I seem to remember that the author even provided instructions for some of the more common ones. Let's just see here... which disk was that on... ...Here it is, this is the `note-from-net' from the original posting. *************************************************************************** /* Written 4:44 pm Feb 19, 1987 by mirror.TMC.COM!sources-request in bradley:comp.sources.unix */ /* ---------- "v08i072: Bidirectional getty/login" ---------- */ Submitted by: cdx39!jc@EDDIE.MIT.EDU (John Chambers) Mod.sources: Volume 8, Issue 72 Archive-name: uutty/Part01 [ I have not tried this. --r$ ] Hello. Enclosed is a program which I've been using for some time as a replacement for getty; I call it "uutty" as a hint that it cooperates with uucp/uux/mail/cu/etc. Several friends have suggested I broadcast it, so here it is.... Uutty's primary function is to make it easy to use a port in both directions with little grief. On a port with an ACU-type modem, it allows both outgoing and incoming calls without any need to fiddle with inittab. On a direct link, it allows the use of commands like uucp or cu in either direction at any time. Uutty's secondary function is to try to recognize input from overly-intelligent modems or other login daemons, and avoid getting into a cycle-eating conversation with them. There is also a tertiary function: optionally producing an audit (debug) trail of traffic on the port at times when no program (such as uucico or cu) is using it. This is mostly useful when you have a talkative modem or LAN connection. This version should be classified as a "beta test" version; it has been tested on only a few varieties of Unix, and it will probably have to be modified for others. The two parts that may not be very portable are the code to put a port into raw mode (makeraw.c), and the code to log in a user (*.utmp.c). Another major reason for wanting the source code close at hand is that you will likely have to twiddle with the code that handles talkative modems, in order to respond correctly to your modems' own variety of bizarreness. An especially common problem is being overly sensitive to speed. Many modems won't accept commands at the full line speed (1200 baud or whatever); they assume that commands come from a person typing at a keyboard, and lose characters when it comes from a program in a burst. This program writes the "init" strings byte-at-a-time, which may be slow enough, but you may have to slow these writes down even more to make the modem understand. ********************************************************************* I have used this myself for bi-directional uucp connections, and found it to work great on a pair of 3b1/7300's. You can get it from the archives, or if necessary I can mail it to anyone who may need it. it comes in two compressed shars which weigh in at 30K each, or about 100K total if uncompressed. -- Careful with that axiom, Euclid Nic Bernstein Discovery World Museum Discovery World denies my existance 818 W. Wisconsin av. without further proof. Milwaukee, WI 53233 ____________________________________________________________________________ {uunet|uwmcsd1|gryphon}!marque{!introl}!dworld!nic ____________________________________________________________________________
dca@kesmai.COM (David C. Albrecht) (06/22/88)
> > One way to fix the problem would be to hack the getty source (outta > luck about this idea on the 3b1!) so that getty keeps its mouth > shut until it gets a character from the originate side that is not > part of the MNP handshake sequence. Why out of luck? I got my hands on a PD getty login driver and replaced the default one on the tty000 line. The one I put in doesn't echo either the login or the password characters and takes pains to recognise if its talking to another login request. This way I was able to hook two unix pc's by their serial ports and both in HOST_ONLY mode and yet able to use the phone manager to log on from one machine to the other and/or transfer info via uucp. If echoing the input characters is the problem with the MNP line I would expect that it might world with the phone line as well. David Albrecht