Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!munnari.oz.au!metro!wolfen!wraith!david
From: david@cs.uow.edu.au (David E A Wilson)
Newsgroups: comp.unix.questions
Subject: Re: Modem
Message-ID: <929@wraith.cs.uow.edu.au>
Date: 16 Jun 90 10:48:21 GMT
References: <23608@adm.BRL.MIL> <3608@wb3ffv.ampr.org> <1990Jun15.224120.27813@virtech.uucp> <183@twg.UUCP>
Organization: Dept of Computer Science, University of Wollongong, Australia
Lines: 29

bill@twg.UUCP (Bill Irwin) writes:

>I've  always thought that it was the computer that asserted DTR when  the
>port  was  enabled and ready to spawn a getty, as soon as CD is  present.
>If  DTR isn't true, the modem's auto answer is disabled until the port is
>ready  (DTR  true).   Once the modem connects and asserts CD,  the  getty
>comes  up.   If the line is lost, CD goes, and any orphaned processes  on
>the port are killed if HUPCL is on.

I have seen two ways in which DTR is used to control a modem.

1)	With auto answer modems, computer asserts DTR and getty blocks
	waiting for DCD. When modem answers and detects carrier, it asserts
	DCD, getty unblocks and login message is displayed.  User logs in.
	Either user logs out, in which case on final close DTR is
	deasserted for a short time causing modem to hang up.
	OR connection is broken, DCD from modem drops, shell gets hangup
	signal and closes port which again deasserts DTR briefly.

	The procedure then repeats.

2)	With "dumb" modems the computer must monitor RI (ring indicate)
	After the appropriate number of rings are detected, DTR is asserted
	and the modem goes off hook and the connection is made with the
	remote modem.
	Again, the modem is hung up by deasserting DTR but this time until
	RI indicates another call is coming in.

David Wilson	david@wraith.cs.uow.edu.au