mdm@cocktrice.UUCP (Mike Mitchell) (01/22/89)
Does anyone have a fancy trick for lowering DTR going to a modem attached to tty0? I have my modem set up to auto answer, however there are times that I do not want the modem to answer the phone. I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill the getty, the DTR drops for a moment and then comes up again. The modem still answers the phone, but there is nothing running to accept logins. If I do not run a getty, the DTR behaves "properly" when making outgoing calls. UUCP will dial out and connect and when it is finished the DTR is dropped when /dev/tty0 is closed. -- Mike Mitchell BELL: (505) 471-7639 2020 Calle Lorca #43 ARPA: mdm@cocktrice.UUCP Santa Fe, NM 87505 UUCP: ...!uunet!dmk3b1!cocktrice!mdm
rick@pcrat.UUCP (Rick Richardson) (01/23/89)
In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes: >Does anyone have a fancy trick for lowering DTR going to a modem attached >to tty0? I have my modem set up to auto answer, however there are times >that I do not want the modem to answer the phone. I timeshare a line for voice (daytime) and data (nightime). What I do is to leave getty running all the time. But, twice a day, I have cron fire off a program which sends the turn on/off auto answer sequence to the modem. The program, of course, obeys the same locking protocol as UUCP, so that there won't be any conflicts. This works well, and since the modem has non-volatile memory I don't have to worry what state the modem is in should the power fail. Come to think of it, you could probably come up with a solution which involved only a special Dialer type and two phony System entries. The UUCP Poll file would fire off a "call" to the phony systems to turn on/off the autoanswer. No programming necessary. -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
bill@ssbn.WLK.COM (Bill Kennedy) (01/23/89)
I started to mail this but I thought that it might be useful since some might be sharing a voice line with a modem. In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes: >Does anyone have a fancy trick for lowering DTR going to a modem attached >to tty0? I have my modem set up to auto answer, however there are times >that I do not want the modem to answer the phone. The obvious things would be to unplug either the phone line or serial cable from the modem, but those leave you vulnerable to forgetting to plug them back in. You could also arm and disarm with echo "ATQ1S0=0" > /dev/ttyM0 to disarm it and the reverse to rearm it. If you're going to do it this way, make sure that you use the Q1 so that the modem doesn't torture the getty with result codes that the phone is ringing. >I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill >the getty, the DTR drops for a moment and then comes up again. The modem >still answers the phone, but there is nothing running to accept logins. That's odd. The first part is quite understandable because init spawns a new getty when the old one dies, but it should prompt for a login, i.e. it should be a shiny new getty ready to go. >If I do not run a getty, the DTR behaves "properly" when making outgoing >calls. UUCP will dial out and connect and when it is finished the DTR is >dropped when /dev/tty0 is closed. You need to alter the inittab to not respawn the getty and then you need to kill the getty itself, see below. >-- >Mike Mitchell BELL: (505) 471-7639 >2020 Calle Lorca #43 ARPA: mdm@cocktrice.UUCP >Santa Fe, NM 87505 UUCP: ...!uunet!dmk3b1!cocktrice!mdm I have the same problem from time to time when I need the voice line to do double duty, particularly at night. It's also rather handy to have the modem to answer late night calls when I don't want to be disturbed. I run a job with cron that arms and disarms a modem on the voice line. Using the following inittab line as an example - T0:23:respawn:/etc/getty ttyM0 2400 # # disarm ttyM0, runs from cron at 0630 each morning # # Start by changing the /etc/inittab line from respawn to off # TMP=/tmp/tty$$ chmod u+w /etc/inittab ed - /etc/inittab <<'EOF' /T0/s;respawn;off; w q EOF chmod u-w /etc/inittab # # Now find and kill the getty, this is modified from # what I use to kill all uugetty's that are active. # ps -e | grep getty > $TMP if [ -s $TMP ] then cat $TMP | while read pid tty time command do if [ "ttyM0" = "$tty" -a "getty" = "$command" ] then set - $pid; pid=$1; kill -9 $pid fi done fi rm -f $TMP chmod /etc/inittab u-w Now something similar to arm the port. # # arm ttyM0, run from cron at 2330 # # All we have to do is change off to respawn and # tell init to look at inittab again. # chmod u+w /etc/inittab ed - /etc/inittab <<'EOF' /T0/s;off;respawn; w q EOF chmod u-w /etc/inittab /etc/telinit q Since it requires root permissions to modify /etc/inittab I will leave the cron line up to the reader. I'm ASSuming that Mike's system is like mine, a small one where the owner can pretty much do as they please. There are probably some undesirable side effects to such brute force in a different environment but the technique has worked well on my systems. -- Bill Kennedy usenet {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill internet bill@ssbn.WLK.COM
vjs@calcite.UUCP (Vernon Schryver) (01/23/89)
In article <362@cocktrice.UUCP>, mdm@cocktrice.UUCP (Mike Mitchell) writes: > Does anyone have a fancy trick for lowering DTR going to a modem attached > to tty0? I have my modem set up to auto answer, however there are times > that I do not want the modem to answer the phone. > > I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill > the getty, the DTR drops for a moment and then comes up again. There seem to be bugs in the 3.0e driver. If you ever use tty[Mm][01], the driver decides that you want DTR high forever after. Other bugs include a failure to flush input buffers on the last close. Worse is a failure to forget about XOFF (^S) on the last close. The latter means that noise which looks like ^S during cu(1) (which follows the stupid SVR3 practice of absolutely insisting on setting IXON -IXANY IXOFF) can lock up a port permanently, until you reboot or until you run a program which does an ioctl(TCXONC). You can't fix it with ioctl(TCSETA), turning off IXON & IXOFF; the TCSETA will hang! The absense of RTS/CTS flow control should be considered a bug today, no matter what RS-232-C said 15(?) years ago. For the DTR bug, I found the enclosed hack/kludge/script works. It bangs on the port enough times to convince the driver. Not having seen the driver source, I can only guess why it works. All of its weirdness seem to be necessary in various cases. It seems to work on an Everex 386/20 and a no-name 16MHz. I've used it to run getty only at night. It is run by cron every 15 minutes at night (don't ask) and once in the morning. It could obviously stand some cleaning and generalizing, but it would be better to spend the time fixing the driver. If you use it as is, you'll want to create the extra inittab's. If you have something simpler (like a reasonable driver for 3.0e+DOSMerge), please let me know. Vernon Schryver {sgi,pyramid}!calcite!vjs #!/bin/sh #(wishing we had a real csh and/or the uts/*/os/exec.c hacks) # # turn modem off or on usage="usage: $0 {on | off}" set -e if test $# != 1; then echo "$usage" exit 1 fi trap "" 1 case $1 in 'on') cp /etc/inittab.on /etc/inittab /etc/telinit q ;; 'off') if cmp -s /etc/inittab.off /etc/inittab; then exit 0 fi cp /etc/inittab.off /etc/inittab set +e /etc/telinit q sleep 4 #reset DTR PORT=01 exec > /dev/null 2>&1 stty < /dev/ttyM$PORT & sleep 1; kill -9 $!; wait 2> /dev/null; sleep 2 stty < /dev/ttyM$PORT & sleep 1; kill -9 $!; wait 2> /dev/null; sleep 2 stty < /dev/tty$PORT stty < /dev/ttyM$PORT & sleep 1; kill -9 $! 2> /dev/null; wait 2> /dev/null; sleep 2 stty < /dev/tty$PORT ;; *) echo "$usage" exit 1 ;; esac
mdm@cocktrice.UUCP (Mike Mitchell) (01/23/89)
In article <916@ssbn.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes: >>Does anyone have a fancy trick for lowering DTR going to a modem attached >>to tty0? I have my modem set up to auto answer, however there are times >>that I do not want the modem to answer the phone. > >The obvious things would be to unplug either the phone line or serial cable >from the modem, but those leave you vulnerable to forgetting to plug them >back in. You could also arm and disarm with Not a good solution. I would forget. >>I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill >>the getty, the DTR drops for a moment and then comes up again. The modem >>still answers the phone, but there is nothing running to accept logins. > >That's odd. The first part is quite understandable because init spawns a >new getty when the old one dies, but it should prompt for a login, i.e. it >should be a shiny new getty ready to go. Init is not envolved yet at this stage. I was hand spawining the getty as an exercise from the console to insure that it works. >I have the same problem from time to time when I need the voice line to do >double duty, particularly at night. It's also rather handy to have the >modem to answer late night calls when I don't want to be disturbed. I run >a job with cron that arms and disarms a modem on the voice line. Using the >following inittab line as an example - A little more elegant way of doing this is to have the getty run at run state 3 only and just 'telinit 3' to fire it up, and 'telinit 2' to get rid of it. However this is not the mode I have been using (yet). The getty was spawned from the root login on the console. It behaved properly for a single login (to be expected) and when the login was terminated, the DTR only dropped for a moment. A new getty was not spawned, however the DTR came back up. This exercise is to allow me to share the single phone line for voice and data. I want my calls in the evening, however I would like to be able to dial in from work during the day. The brute force solution for this problem is in the works... Open /dev/mem and perform a couple of ioctls which would dump the magic modem bytes to the UART line control register to disable the DTR. Calls to this program would then be made from the 'gettyoff' shell script. This is not a real pretty solution though. I kind of feel like the kernel should do this for me. (And maybe it can--I am not sure how to massage it into happiness). -- Mike Mitchell BELL: (505) 471-7639 2020 Calle Lorca #43 ARPA: mdm@cocktrice.UUCP Santa Fe, NM 87505 UUCP: ...!uunet!dmk3b1!cocktrice!mdm
learn@igloo.UUCP (william vajk) (01/24/89)
> >In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes: > >>Does anyone have a fancy trick for lowering DTR going to a modem attached > >>to tty0? I have my modem set up to auto answer, however there are times > >>that I do not want the modem to answer the phone. It is an easy matter to reset most modems to ignore auto answer. I only buy modems which have S0 as a software settable function. If someone is on the line when cron strikes get_off, there is at least one PD pkill routine (kill process by name) that can be run as part of a script called by cron. If your modem has S0 writable, there's probably no good reason to use dropping DTR as a means of locking out the system from incoming calls. Bill Vajk | Eventually SOMEBODY's going to put SOMETHING learn@igloo | I SAY in a .sig. -Allen Gwinn
jiii@visdc.UUCP (John E Van Deusen III) (01/26/89)
Intelligent modems like the TB+ have a command mode, and you can write a supervisor program that is respawned by init and deals with the modem at the command level. You can allow the modem to answer a call and, upon establishing a connection, exec(2) getty(1M), and so on. If you don't want to answer the line, the program could sleep and periodically check a status file, (this assumes that there exists some method to prevent the modem from answering the line. With the TB+ the S0 register is assigned the value 0). The supervisor program can also be written to support the resource locking facilities of uucp. The line can be available for login and still used for outgoing calls. Since the supervisor program doesn't exec getty until a connection is made, you don't have the problem of getty trying to assert login. This also would work on serial ports that don't support DTR. -- John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii
jr@oglvee.UUCP (Jim Rosenberg) (01/28/89)
In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes: >I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill >the getty, the DTR drops for a moment and then comes up again. The modem >still answers the phone, but there is nothing running to accept logins. The "book" way of dropping DTR is supposed to be stty 0. On our Altos 2000 with Xenix System V I have to do this to zap DTR after a uucico dial-out. What happens when you try stty 0 </dev/ttyM0 ?? If this doesn't work then for my $.02-worth I'd say the driver's broke. -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>
chuck@laffu.UUCP (Chuck Sites) (01/28/89)
In article <362@cocktrice.UUCP>, mdm@cocktrice.UUCP (Mike Mitchell) writes: > Does anyone have a fancy trick for lowering DTR going to a modem attached > to tty0? I have my modem set up to auto answer, however there are times > that I do not want the modem to answer the phone. This is what I've been doing to toggle between an auto answer, and dial-in on Hayes type modems with uPORT. There is no Makefile with this program, but It should be pretty easy to set up. Look at the shell scripts dismdm & enamdm for the directories to place the programs modemctl, tty.on & tty.off. To compile modemctl.c a simple: cc -O modemctl.c -o modemctl will do. You may need to change some of the parameters in modemctl.c when setting up the ioctl call. Look at the program if you need baud rates other than 2400. The shell scripts I'm using here are pretty laim, so you may want to beef these up. At work, we are using the same modemctl.c program, but with some much improved shell scripts to control seven different modems. With the addition of a cron job or two, it's pretty easy to have one of these Hayes type modems doing all kinds of wierd things in the middle of the night :-) ----------------------- CUT HERE----------------------------- #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # dismdm # enamdm # modemctl.c # tty.off # tty.on # This archive created: Fri Jan 27 19:17:30 1989 export PATH; PATH=/bin:$PATH if test -f 'dismdm' then echo shar: will not over-write existing file "'dismdm'" else cat << \SHAR_EOF > 'dismdm' #Disable modem port from logins /etc/tty.off t0 /usr/lib/uucp/modemctl "AT,ATE1,ATS0=0" chown uucp /dev/tty0 chgrp bin /dev/tty0 echo "** Disable Modem at `date '+%r on %D'` **" >> /usr/spool/uucp/LOGFILE SHAR_EOF chmod +x 'dismdm' fi # end of overwriting check if test -f 'enamdm' then echo shar: will not over-write existing file "'enamdm'" else cat << \SHAR_EOF > 'enamdm' #Enable modem for logins /usr/lib/uucp/modemctl -c "ATE0,ATS0=1" /etc/tty.on t0 echo "** Enable Modem at `date '+%r on %D'` **" >> /usr/spool/uucp/LOGFILE SHAR_EOF chmod +x 'enamdm' fi # end of overwriting check if test -f 'modemctl.c' then echo shar: will not over-write existing file "'modemctl.c'" else cat << \SHAR_EOF > 'modemctl.c' #include <stdio.h> #include <errno.h> #include <fcntl.h> #include <termio.h> extern int errno; /* #define DEBUG /* envoke debug outbut */ #ifndef TRUE #define TRUE 1 #define FALSE 0 #endif typedef int bool; char device[40]="/dev/tty0"; char wakeup[]="\r\rAT\r\rAT\r\r"; char command[132]; char cm[40]; main(argc,argv) int argc; char *argv[]; { struct termio buf,obuf; int fd,argcnt; int i,j,issue; bool clocal; char c; if (argc<2) { fprintf(stderr,"USAGE: modemctl [-c] [-T/dev/tty##] \"Hayse AT command string\"\n"); exit(1); } argcnt=1; if(*(argv[1]+0)=='-' && *(argv[1]+1)=='c') { ++argcnt; clocal=TRUE; } else clocal=FALSE; if(*(argv[argcnt]+0)=='-' && *(argv[argcnt]+1)=='T') { strncpy(device,argv[argcnt]+2,40); ++argcnt; } #ifdef DEBUG printf("%s\n%s\n%s\n",argv[1],device,argv[2]); #endif fd=open(device,O_NDELAY); sleep(2); /* Toggle DTR line ON/OFF */ close(fd); /* to wakeup modem. */ sleep(1); if ((fd=open(device,O_NDELAY|O_RDWR))<0) { perror("Modemctl error"); exit(1); } ioctl(fd,TCGETA,&buf); ioctl(fd,TCGETA,&obuf); #ifdef DEBUG printf("iflag=%o\noflag=%o\ncflag=%o\nlflag=%o\n\n",buf.c_iflag,buf.c_oflag,buf.c_cflag,buf.c_lflag); #endif buf.c_iflag = (IGNBRK | IGNPAR | IXON | IXOFF); buf.c_oflag = 0; buf.c_cflag = (B2400 | CS8 | CREAD | CLOCAL | HUPCL); buf.c_lflag = 0; ioctl(fd,TCSETA,&buf); ioctl(fd,TCFLSH,2); close(fd); sleep(1); /* second pass at opening file */ if ((fd=open(device,O_NDELAY|O_RDWR))<0) { perror("Modemctl error"); exit(1); } ioctl(fd,TCGETA,&buf); ioctl(fd,TCGETA,&obuf); #ifdef DEBUG printf("iflag=%o\noflag=%o\ncflag=%o\nlflag=%o\n\n",buf.c_iflag,buf.c_oflag,buf.c_cflag,buf.c_lflag); #endif buf.c_iflag = (IGNBRK | IGNPAR | IXON | IXOFF); buf.c_oflag = 0; buf.c_cflag = (B2400 | CS8 | CREAD | CLOCAL | HUPCL); buf.c_lflag = 0; ioctl(fd,TCSETA,&buf); ioctl(fd,TCGETA,&buf); #ifdef DEBUG printf("iflag=%o\noflag=%o\ncflag=%o\nlflag=%o\n\n",buf.c_iflag,buf.c_oflag,buf.c_cflag,buf.c_lflag); #endif sleep(1); /* issue command to modem */ write(fd,wakeup,strlen(wakeup)); ioctl(fd,TCFLSH,0); sleep(3); strcpy(command,argv[argcnt]); #ifdef DEBUG printf("command=%s\n",command); #endif i=0,j=0; issue=0; while (command[i] != 0) { cm[j]=command[i]; if (cm[j]==',') { cm[j]='\r'; cm[++j]=0; write(fd,cm,j); sleep(2); ioctl(fd,TCFLSH,0); #ifdef DEBUG sleep(1); printf("issue(%d)=%s\n",++issue,cm); #endif j=0; } else ++j; ++i; } cm[j]='\r'; cm[++j] = 0; write(fd,cm,j); sleep(2); ioctl(fd,TCFLSH,0); #ifdef DEBUG printf("issue(%d)=%s\n",++issue,cm); #endif buf.c_iflag = ( BRKINT | IGNPAR | IXON | ICRNL | ISTRIP); /* make the tty sane */ buf.c_oflag = (OPOST | TAB3 | ONLCR ); buf.c_lflag = (ISIG | ICANON | ECHO | ECHOE | ECHOK ); if (clocal != TRUE) buf.c_cflag &= ~CLOCAL; ioctl(fd,TCSETA,&buf); sleep(1); close(fd); sleep(2); fd=open(device,O_NDELAY); sleep(2); /* Toggle DTR line ON/OFF */ close(fd); /* to wake up modem. */ sleep(1); } SHAR_EOF chmod +x 'modemctl.c' fi # end of overwriting check if test -f 'tty.off' then echo shar: will not over-write existing file "'tty.off'" else cat << \SHAR_EOF > 'tty.off' # TTY.OFF turns respawn of terminal line off. # 1.1(1987) Copper Electronics Inc. # if [ $# -eq 0 ] then echo "Usage: $0 tty#" echo "Example: 09=tty9, mo=modem, ect." exit 1 fi trap "" 1 2 3 15 /bin/sed /$1:/s/respawn/off/g /etc/inittab > /etc/inittab.old mv /etc/inittab.old /etc/inittab chmod +r /etc/inittab /bin/telinit q trap 1 2 3 15 SHAR_EOF chmod +x 'tty.off' fi # end of overwriting check if test -f 'tty.on' then echo shar: will not over-write existing file "'tty.on'" else cat << \SHAR_EOF > 'tty.on' # TTY.ON turns respawn of terminal line on. # 1.1(1987) Copper Electronics Inc. # if [ $# -eq 0 ] then echo "Usage: $0 tty#" echo "Example: 09=tty9, mo=modem, ect." exit 1 fi trap "" 1 2 3 15 /bin/sed /$1:/s/off/respawn/g /etc/inittab > /etc/inittab.old mv /etc/inittab.old /etc/inittab chmod +r /etc/inittab /bin/telinit q trap 1 2 3 15 SHAR_EOF chmod +x 'tty.on' fi # end of overwriting check # End of shell archive exit 0 -- "Nothing can be made fool proof because fools are just too damned clever" ______________________________________________________________________________ . . . . AUTHOR: Chuck Sites @ The Louisville Area Forum For Unix . . . . o o o o o UUCP: {mit-eddie}!bloom-beacon!coplex!chuck o o o o o O O O O O O ATT: (502)454-7218 \laffu!chuck O O O O O O ______________________________________________________________________________
mdm@cocktrice.UUCP (Mike Mitchell) (02/01/89)
In article <461@oglvee.UUCP> jr@.UUCP (Jim Rosenberg) writes: >In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes: >>I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill >>the getty, the DTR drops for a moment and then comes up again. The modem >>still answers the phone, but there is nothing running to accept logins. > >The "book" way of dropping DTR is supposed to be stty 0. On our Altos 2000 >with Xenix System V I have to do this to zap DTR after a uucico dial-out. What >happens when you try > >stty 0 </dev/ttyM0 > Tried this one second... Doesn't work. However, someone mailed me a script that they use to hammer on the port. It performs this quite a few times in order to bash the port into submission. I have not tried the script as I am looking for something less fiendish. Does anyone have an alternate device driver available? (If someone needs a alpha site for a driver to test 16550A's, I have one port equipped with one.) -- Mike Mitchell BELL: (505) 471-7639 2020 Calle Lorca #43 ARPA: mdm@cocktrice.UUCP Santa Fe, NM 87505 UUCP: ...!uunet!dmk3b1!cocktrice!mdm