kls@ditka.UUCP (Karl Swartz) (01/03/89)
In article <453@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: >>When HDB places a ACU call, why the *&^^% doesn't it open the port >>with O_NDELAY? I have to tell my modem to keep carrier high, which >>is certainly not correct, and screws up detection of remote hangups. > >Here are the lines from my Dialers file for the Telebit I'm using ... I tried what you had but ran into a couple of problems. First, when trying to talk to the modem directly, I got what looked like a getty war. Sure enough, disabling getty before invoking cu fixed it; a bit of head scratching and I guessed you're probably running your TB with ATE0 as default. That worked, but I don't understand why it's needed for S53=4 but not for S53=0. Unfortunately, even with ATE0, I ran into a babbling getty, this time when uucico called a remote system and the remote sent out its login prompt. Couldn't figure out how to get around this one. Also, where are all these hidden sub-fields documented? I know of a few of them, with the ",M" in Devices and "\M" and "\m" in Dialers being the latest additions, but it's all come from word-of-mouth (or is it word-of-fingers in this case?). -- Karl Swartz |UUCP {ames!hc!rt1,decuac!netsys}!ditka!kls 1-505/667-7777 (work) |ARPA rt1!ditka!kls@hc.dspo.gov 1-505/672-3113 (home) |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
rjg@sialis.mn.org (Robert J. Granvin) (01/04/89)
>>>When HDB places a ACU call, why the *&^^% doesn't it open the port >>>with O_NDELAY? I have to tell my modem to keep carrier high, which >>>is certainly not correct, and screws up detection of remote hangups. >> >>Here are the lines from my Dialers file for the Telebit I'm using ... Well, this is semi-related, and there's been a few people asking for it anyways, so... Posted to unix-pc.sources is a shar file that is a Trailblazer+ configuration for HDB UUCP on a 3b1. This configuration has been in use on several HDB sites without any problems. While it may not be exactly what you need, it can probably at least be used as a starting point. If anyone discovers any problems or makes any enhancements, I'd be interested in seeing them, since I haven't paid any attention to this stuff for a while now... :-) Note: This configuration does not make any attempt to circumvent any bugs or problems in the TB+ or HDB itself (of which there are some). -- "A cowboy should know his horse, but it Robert J. Granvin seemed to the podners at the Triple Q National Information Systems Ranch that Vernon McChew had gotten rjg@sialis.mn.org TOO close." ...{amdahl,hpda}!bungia!sialis!rjg
jbm@uncle.UUCP (John B. Milton) (01/04/89)
In article <575@ditka.UUCP> kls@ditka.UUCP (Karl Swartz) writes: >In article <453@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: [see others] Yes, I am using E0, here are my regs as of now: E0 F1 M1 Q0 T V1 X1 Version BA4.00 S00=000 S01=000 S02=035 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=070 S12=050 S45=255 S47=004 S48=000 S49=000 S50=000 S51=254 S52=002 S53=004 S54=003 S55=000 S56=017 S57=019 S58=002 S59=000 S60=003 S61=045 S62=003 S63=001 S64=000 S65=000 S66=000 S67=000 S68=255 S90=000 S91=000 S92=001 S95=000 S100=000 S101=000 S102=000 S104=000 S110=001 S111=030 S112=001 S121=000 I have compression turned off for now, for testing. I am not running getty or uugetty, but a very hacked up version of modem-ctl that was posted a while back. This program knows Hayes and talks to the modem (O_NDELAY). When you cu out, it dies (seing the lock file). On incoming, it sees the CONNECT xxx, and forks off the right flavor of /etc/getty. It is run by init. It will not grab the modem back until the lock file has been gone for a while, so when polling is done, the ,M /M /m stuff is needed. The first time around it is sitting there with the tty open O_NDELAY, so the M stuff is not needed. This information came from a friend of a friend of a friend who hacked on the port for the UNIXpc that was put on THE STORE! John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:764-2933; Got any good 74LS503 circuits?