Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!batcomputer!llenroc!cornell!uw-beaver!milton!sumax!nwnexus!l5comp!scotty From: scotty@l5comp.wa.com (Scott Turner) Newsgroups: comp.dcom.modems Subject: Re: PPI 9600SA & answering calls Summary: How to make 'em work with SYSV/386 R4V2 Message-ID: <1991Mar13.130049.7677@l5comp.wa.com> Date: 13 Mar 91 13:00:49 GMT References: <333@mixcom.COM> Sender: scotty@l5comp.wa.com (Scott Turner) Organization: L5 Computing Edmonds, WA Lines: 62 In article <333@mixcom.COM> xeee02@mixcom.COM (Dean A. Roth) writes: > >I have tried using a PPI 9600SA to answer calls >on a UNIX system using a Digiboard multiport >serial card. The 9600SA will usually connect with >the caller, then abruptly drop the call (hang up). Oh boy do I recognize this problem! First let me state that if Intel/AT&T knew how to write a Streams based serial device driver I'd be a happy camper right now with the 9600SA, so I don't really blame PPI for my troubles in setting up the 9600SA. Although PPI COULD have made my life easier... The problem: The Carrier Detect line goes high BEFORE the modem is ready for you to talk to it. It goes like this, modem raises CD and bang yer getty runs out and slaps a login on the modem and it hangs up. Under SYSV/386 R4V2 I fixed this problem by switching back to the stock serial driver and then using ttymon which can be told to wait a programmable number of 's before sending out the login prompt. But alas there is one more fix required, the modem sends out "RING" messages and the "CONNECT" message. Echoing these back to the modem anytime before the final on "CONNECT" causes the modem to hangup as well. So I had to turn off all the echo's in /etc/ttydef as well. On pre-SYSVR4 systems I'd suggest uugetty since it waits for one before sending out the login: prompt. Set the modem to only send "CONNECT" and no "RING"'s (X0???) and you may just slide under the wire. You'll still need to turn off all the echo's in /etc/gettydefs on the first half of all the speeds. Leave the echo's in on the second half of the gettydef entries or your user's won't be able to see their user id's as they type them in. I haven't bitched to PPI since switching back to the brain dead serial device driver from good ol' FAS 2.08 has had me up late hours. AT&T still won't let cu do anything but ASCII transfers, hey, we've got uucp for binary transfers right? (The best of BSD? Where's tip guys?) And nothing on this planet except cu and uucico seem to know how to open /dev/tty01h and talk to the modem (and it took 3 MONTHS to get Intel to tell me how to get cu and uucico to do THAT!) You can't just open( "/dev/tty01h", O_RDWR) and have a talk with a modem, sigh. Trying to cobble together a terminal program with incomplete dox (where oh where is termio(7)?) has me in no mood to talk to low-level tech weenies at PPI, I'm afraid they'd tell me they're terribly un-able to help me and I KNOW I'd flip out. Yep, just plain loose it all over that tech weenie. All Intel/AT&T's fault of course, but PPI wouldn't understand that. :) Please let me know if you have any luck trying to explain this CD thingy to PPI. But I can state that once ttymon is setup properly I get 100% reliable auto answer operation. So it isn't that the modem is in-capable of being used in this fashion on a unix box, but unless PPI fixes the CD problem your mileage under anything but SYSV/386 R4V2 may vary (and I wouldn't recommend switching to SYSV/386 R4V2 to my worst enemy, hell I don't think switching to SYSV/386 R4V3 would be all that swift either csh might not crash and log out remote users on the modem but the serial driver is still going to be B.D.O.A...) Scott Turner scotty@l5comp.wa.com