shanzer@mit-prep.ARPA (Mike Shanzer) (09/17/86)
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 -- Mike Shanzer UUCP: mit-eddie!mit-prep!shanzer ARPA: shanzer@prep.ai.mit.edu AT&T: (617) 443-9498 US-MAIL: 47 Chanticleer Road, Sudbury Ma. 01776 DISCLAIMER: "Hi, I am a disclaimer." "Unix, Live free() or malloc()."
jsloan@wright.EDU (John Sloan) (09/21/86)
> > 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.
stuart@BMS-AT.UUCP (Stuart D. Gathman) (09/28/86)
In article <107@mit-prep.ARPA>, shanzer@mit-prep.ARPA (Mike Shanzer) writes: > 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? The open is waiting for the modem to connect (i.e. for CD to turn on). If this is a Hayes type auto-dial modem, you need to open it in a mode which does not wait for 'CD'. On some systems, this is a special device file which has no modem control (this emulates older autodialers which required two ports: one for dialing and one for communications). On others, (and this *should* work on all systems, but alas there are always bugs) you should give the O_NDELAY parameter on your open. This will ignore the CD lead while you give dialing commands. Ideally, another process should be waiting on an open without O_NDELAY, i.e. fork() to do the dialing. -- Stuart D. Gathman <..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>