Dial-in+Dial-out on same physical TTY with ISC 386/ix V3.2.0.2 X6

John B. Milton jbm at celebr.uucp
Wed Jun 27 11:39:24 AEST 1990

In article <852 at mutad.UUCP> arjen at 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

We need an UNmoderated group comp.sources.unix.i386

John Bly Milton IV, jbm at uncle.UUCP, n8emr!uncle!jbm at osu-cis.cis.ohio-state.edu
(614) h:252-8544, w:469-1990; N8KSN, AMPR:; Don't FLAME, inform!

More information about the Comp.unix.i386 mailing list