Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!topaz!ll-xn!mit-amt!mit-eddie!genrad!decvax!bellcore!ulysses!burl!clyde!cbatt!cbosgd!wright!jsloan From: jsloan@wright.EDU (John Sloan) Newsgroups: net.unix Subject: Re: Getting Modems to work under Ultrix Version 1.2 Message-ID: <168@wright.EDU> Date: Sat, 20-Sep-86 21:17:40 EDT Article-I.D.: wright.168 Posted: Sat Sep 20 21:17:40 1986 Date-Received: Tue, 23-Sep-86 07:45:25 EDT References: <107@mit-prep.ARPA> Organization: Wright State University, Dayton OH, 45435 Lines: 48 > > I have a question, I am trying to open a modem for writting under > Ultrix V1.2, how ever when I try to do this the open hangs. DOes any > one know why it does this and how I can fix it? > Mike Shanzer DEC changed the way you handle modem control under Ultrix-32 V1.2. I messed with this for a long time before I realized I was debugging the CSNET PMDF code using the V1.1 manual set, which didn't jive with the online manuals. Ouch! Read the tty(4) pages in the _V1.2_ manuals. There is an option on the open you need to OR together with the read/write stuff to indicate that you don't want the open to hang waiting for carrier (useless, if you're trying to send a dialing sequence to a Hayes). I thinks its O_NDELAY but look it up. This is not enough, however: your first read/write will hang unless you issue the correct ioctl to indicate that I/Os w/o carrier are permissable. You end up using two new ioctls, I believe. There is an example in tty(4) that seems correct. On a related topic: Now I have the CSNET PMDF code handling it all okay, but tip and uucp, which uses DEC's new (argh!) /etc/acucap (actually a neat idea) for dialing modems, are causing me no end of grief. I have the Hayes on a line with modem control (both in the kernel via the config flags and in the /etc/ttys file). The dialing goes fine, and carrier detection is fine, but if the other end DOES NOT answer the phone and the Hayes timesout, the system absolutely will not send the ATZ abort sequence to the modem until I turn the modem off and back on. uucp and tip just hang (presumably its the acucap drivers hanging in each case) in the idle state until then. /etc/pstat indicates they are waiting on the tty line for an event to complete. I scoped the line with a protocol analyzer and the only thing that changes is that when the Hayes' power is cycled, carrier detect is asserted briefly. This apparently makes the software happy. It appears that although the dialing portion of the software works without carrier present, the error recovery/timeout code will not. Pretty poor. Putting the modems on non-modem-control lines works after a fashion, but then of course they cannot detect loss of carrier if the other end drops the line, which causes a lot of other problems, not to mention assuming that the other end is online before they have even answered the phone. Any ideas? -- ---------------------------------------------------------------------- John Sloan jsloan@wright.{CSNET,UUCP} ...!cbosgd!wright!jsloan Computer Science Department, Wright State University, Dayton OH, 45435 +1 513 873 {2987,2491,2622}, +1 513 426 8082 belong(opinons,jsloan). belong(opinions,_) :- !, fail.