pozar@hoptoad.uucp (Tim Pozar) (10/19/87)
In article <1548@bloom-beacon.MIT.EDU> xev@hstbme.mit.edu (Xev Gittler) writes: >I have a hayes compat modem on a tty line, that I use for outgoing >calls. My problem is that I am setting up an automated calling script >using kermit, and I need to make sure that after the call is >supposedly over, the line is definitely hung up. What can I do to >accomplish this? > Drop DTR. -- Tim Pozar UUCP pozar@hoptoad.UUCP Fido 1:125/406 USNail KKSF 77 Maiden Lane San Francisco CA 94108 PaBell (415) 788-3904
wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (10/19/87)
In article <3234@hoptoad.uucp> pozar@hoptoad.UUCP (Tim Pozar) writes: >In article <1548@bloom-beacon.MIT.EDU> xev@hstbme.mit.edu (Xev Gittler) writes: >>I have a hayes compat modem on a tty line, that I use for outgoing >>calls. My problem is that I am setting up an automated calling script >>using kermit, and I need to make sure that after the call is >>supposedly over, the line is definitely hung up. What can I do to >>accomplish this? > Drop DTR. Given well designed modems, this would be the right answer. Unfortunatley Hayes 1200 modems *won't* hang up if you are in command mode and and drop DTR. You first have to frob the modem to insure it is on line (eg. send the hayes the "AT <go-online-command>", do a suitably long sleep to allow the modem to get this and act upon it, and finally turn off the DTR.) This problem is actually likely to occur if users use tip(1) or kermit to get a connection to the raw hayes modem, and dial the phone number themselves with the hayes "AT" commands. -wolfgang Wolfgang Rupprecht UUCP: mirror!mit-mgm!wolfgang ARPA: wolfgang@mgm.mit.edu (IP addr 18.82.0.114)
rjd@tiger.UUCP (10/20/87)
> >I have a hayes compat modem on a tty line, that I use for outgoing > >calls. My problem is that I am setting up an automated calling script > >using kermit, and I need to make sure that after the call is > >supposedly over, the line is definitely hung up. What can I do to > >accomplish this? > > > > Drop DTR. > ...Then kick it around the room a few times.... If that does not work, then unplug the thing.... :-) :-) (could not resist) Randy
rwhite@nusdhub.UUCP (Robert C. White Jr.) (10/20/87)
In article <3234@hoptoad.uucp>, pozar@hoptoad.uucp (Tim Pozar) writes: > In article <1548@bloom-beacon.MIT.EDU> xev@hstbme.mit.edu (Xev Gittler) writes: > >I have a hayes compat modem on a tty line, that I use for outgoing > >calls. My problem is that I am setting up an automated calling script > >using kermit, and I need to make sure that after the call is > >supposedly over, the line is definitely hung up. What can I do to > >accomplish this? > Drop DTR. Here is a little niftyness from the people who tried to bring you the UNIX-PC [and failed for the most part] In SVR3.1.1 for our system they have added two switch codes to the possibilities for a Dialers script. \M Set CLOCAL \m unset CLOCAL you take you auto-dialing modem and set it to only pass CD when there is carrier. you then dial by: set CLOCAL dial the number when you get the answered unset CLOCAL this effectively makes 2-way hayes compatible modems possible. Rob.
jc@minya.UUCP (John Chambers) (10/22/87)
> > > ... and I need to make sure that after the call is > > >supposedly over, the line is definitely hung up. What can I do to > > >accomplish this? > > > > Drop DTR. > > ...Then kick it around the room a few times.... If that does not > work, then unplug the thing.... :-) :-) (could not resist) > Good suggestion. Much better than the "Drop DTR" suggestion. True, this is what the modem expects (if it isn't in command mode) But does anyone know the Unix call (for Sys/V and BSD and Xenix and ...) that does this? Presumably the guy wasn't talking about how to hack the kernel to make it twiddle the DTR line; he was asking how his user-mode program does it. I've spent a lot of time on a lot of systems trying to figure out how the *#&$@^ you get the DTR line to drop, and to my knowledge, there is no way to do it that works on all serial ports on all systems. It's often very hard to figure out how to do it on one specific system. Oh, sure, I know about hupcl; who doesn't; but that's not the answer. Would you like a list of the systems I've seen where the line stasy connected despite the closing of the file by all processes? Furthermore, how does a program hunt down and kill all processes that may have the file open? And do you really want to do it that way? If anyone has a C function that will reliably cause any model of modem to hang up on any serial port on any Unix system, I sure would like to see it. I could have used it years ago. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
ron@topaz.rutgers.edu (Ron Natalie) (10/22/87)
There is no absolute way to do this on ALL unixes. This is especially complicated by people who want DTR to work only part of the time (they use the same line for dial in/out). Generally, if you have modem control enabled on a UNIX line there are two ways to get the DTR to drop. One is to stty a speed of 0, and the other is to set the stty field HUPCL and then makesure everyone who has the tty open closes it. -Ron
jfh@killer.UUCP (The Beach Bum) (10/23/87)
In article <292@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: > If anyone has a C function that will reliably cause any model of modem > to hang up on any serial port on any Unix system, I sure would like to > see it. I could have used it years ago. > > -- > John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) No, I have a collection o functions that do just about anything you want to with a modem. It has a termcap-like collection of routines for accessing a file /etc/modemcap to get the capabilities, and code to access /etc/modemtype to get the modem, and a whole dial(3) package to do the rest. But then I thought the net already had all this stuff. Am I wrong again? Send mail request, if I get enough I'll post, otherwise I'll just mail the stuff to you. Please note my return address in the .signature and send as direct as possible. - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
craig@ncrcpx.UUCP (R. Craig Peterson) (10/23/87)
In article <292@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >> > > ... and I need to make sure that after the call is >> > >supposedly over, the line is definitely hung up. What can I do to >> > >accomplish this? >> > Drop DTR. >does anyone know the Unix call (for Sys/V and BSD and Xenix and ...) >that does this? I've worked with quite a few different UNIX systems over the years including some V7, BSD, and SYSIII/V varients and have found that they are fairly consistent in dropping DTR if you set the baud rate on the line to 0. I have found some exceptions to this where it wouldn't drop untill all processes had closed the line first, but I guess I've been lucky... BTW setting the baud rate to zero would be done differently (somewhat) on each system... -- R. Craig Peterson "Next time someone asks you if you're a god ncrlnk!ncrcam!ncrcpx!craig say YES!!" N8INO Ghost Busters E Pluribus Unum (NSA stuff - terrorist, DES, cipher, secret, NRO, CIA)
allbery@ncoast.UUCP (10/28/87)
As quoted from <292@minya.UUCP> by jc@minya.UUCP (John Chambers): +--------------- | Good suggestion. Much better than the "Drop DTR" suggestion. True, | this is what the modem expects (if it isn't in command mode) But | does anyone know the Unix call (for Sys/V and BSD and Xenix and ...) | that does this? Presumably the guy wasn't talking about how to hack | the kernel to make it twiddle the DTR line; he was asking how his | user-mode program does it. +--------------- On every Unix and Unix-like system I've used (except Minix, which as yet does not have a tty driver) you can drop DTR absolutely by setting the baud rate to 0. This is nonportable in its lowest-level incarnation, but a portable version follows: int hupfd(fd) int fd; { int status; switch (fork()) { case -1: return -1; case 0: close(0); dup(fd); close(1); dup(fd); close(fd); execlp("stty", "stty", "0", (char *) 0); _exit(-1); default: wait(&status); return status; } } Pass it a file descriptor of a modem, and it will drop DTR on the modem, forcing a hangup. Less portable versions follow: V7/BSD/Xenix 2.x: #include <sgtty.h> hupfd(fd) { struct sgttyb b; if (ioctl(fd, TIOCGETP, &b) == -1) return -1; b.sg_ispeed = b.sg_ospeed = B0; return ioctl(fd, TIOCSETP, &b); } System III/System V/Xenix 3/Xenix V: #include <termio.h> #include <sys/ioctl.h> hupfd(fd) { struct termio b; if (ioctl(fd, TCGETA, &b) == -1) return -1; b.c_cflag = (b.c_cflag & ~CBAUD) | B0; return ioctl(fd, TCSETAF, &b); } V6 (does anyone still use this?!): #include <sgtty.h> hupfd(fd) { struct sgttyb b; if (gtty(fd, &b) == -1) return -1; b.sg_ispeed = b.sg_ospeed = B0; return stty(fd, &b); } Note that, thanks to "compatibility" routines in both BSD and AT&T Unixes, the V6 version should work on almost any Unix or lookalike thereof. -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery "Uncle _who_?" -- Lt. Worf
dave@murphy.UUCP (Dave Cornutt) (11/03/87)
In article <4947@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes: > Less portable versions follow: > > V7/BSD/Xenix 2.x: > #include <sgtty.h> > > hupfd(fd) { > struct sgttyb b; > > if (ioctl(fd, TIOCGETP, &b) == -1) > return -1; > b.sg_ispeed = b.sg_ospeed = B0; > return ioctl(fd, TIOCSETP, &b); > } Also, in BSD there's an ioctl, TIOCCDTR, that allegedly drops DTR without you having to close the fd (also TIOCSDTR, which raises it). I haven't tried these; I just saw them in the manual. --- "I dare you to play this record" -- Ebn-Ozn Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL [Ignore header, mail to these addresses] UUCP: ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt ARPA: dcornutt@gswd-vms.arpa "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."