Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!n8emr!uncle!celebr!jbm From: jbm@celebr.uucp (John B. Milton) Newsgroups: comp.unix.i386 Subject: Re: Dial-in+Dial-out on same physical TTY with ISC 386/ix V3.2.0.2 X6 Message-ID: <1990Jun27.013924.683@celebr.uucp> Date: 27 Jun 90 01:39:24 GMT References: <1990Jun14.151703.18918@persoft.com> <609@ke4zv.UUCP> <852@mutad.UUCP> Organization: Celebrezze Committee Lines: 65 In article <852@mutad.UUCP> arjen@mutad.UUCP (Arjen Duursma) writes: > >+Check your modem setup. Your modem should assert CTS and DSR always and >+should assert DCD only when a carrier is present. getty monitors DCD and >+will release the line when it is false. If your modem is toggling CTS or >+DSR when carrier is lost, you will get the behavior you describe. Your >+modem should honor DTR and reset itself to stored parameters when DTR >+is dropped. This way you can store your modem parameters for incoming >+calls and then use your Dialers entry to set any >+parameters you need different for making outgoing calls. When the >+call terminates your modem will be reset to incoming state. getty >+can get into a pathological state if you have your modem set to >+echo in command mode. You will get a getty respawning too rapidly >+message if this happens. So make sure your stored parameters say >+echo off. You can turn it back on in your Dialers script for call >+progress monitoring if you like. > >Great, thats what I thought. But what to do when your >modem refuses to reset itself when DTR drops. >Switches are correct and the TR light does go out, but no reset. >Can there be some RS-232 signal crosslinks or whatever which prevents >the reset? And then there are those modems that can't (or won't) save setup parameters or can't do DTR reset/reload. I use a program I call "prtty", which is a hacked up version of a program called "modem-ctl" in the archives. This program is run by init (prtty instead of getty in /etc/inittab). You only put this program on lines that have modems. When spawned by init, it opens the port NDELAY, talks to the modem: ATZ\d\dATX1V1Q0E1L3, etc. It then sends ATS0=0 to put the modem in no-auto-answer. It then sits there waiting for the string "RING" to come in from the modem. When it does, it sends "ATA", which answers the phone. It the waits for "CONNECT", looks at the text following that and kicks off a "getty -h" at the correct baud rate. The tty line always gets set to the correct rate. If the modem does not answer, the machine is crashed or VERY VERY heavily loaded. After reading each character, prtty does an access("/usr/spool/locks/ttyxxx,0) to see if a lock file has been created. If there is a lock file, prtty immediately exits, gets respawned by init and waits for the lock file to go away. Every five tests of the lock file, it opens the lock file, reads the PID, does a kill(PID,0) to see if the process is still running. If it is, it keeps waiting. If not, it removes the lock file and starts initializing the modem. The are more details, of course. Prtty keeps a log file for each port, the verbosity determined by a startup -x switch from inittab. You can check this lock file to see if you are getting a lot of connects but no logins and also to check at what rate those connects are. I have had prtty running on a wide variety of SYSV boxes (heavy SYSV termio), with little modification (mostly lock files). The part that is constantly changed is the chat script for the particular modem. A rewrite of this beasty is somewhere on my "to-do" list, but not very high at the moment. I don't think prtty is on any of the archive sites, but I could be wrong. I've sent out a lot of copies in the mail. One of the users of prtty is using it with a Telebit Trailblazer 2500. It handles all of the incoming and outgoing modes. We need an UNmoderated group comp.sources.unix.i386 John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!