Date: Tue, 9 Sep 1997 09:10:30 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: grog@lemis.com (Greg Lehey) Cc: mrcpu@cdsnet.net, hackers@FreeBSD.ORG Subject: Re: How the heck do you drop DTR? Message-ID: <199709090910.CAA27827@usr09.primenet.com> In-Reply-To: <19970909170354.43104@lemis.com> from "Greg Lehey" at Sep 9, 97 05:03:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > However, for the life of me, I can't figure out how to actually drop
> > DTR.
> >
> > Looking at the source for ppp, there's something in a HangupModem()
> > function about setting the baud rate to 0. It looks like this
> > does the trick, but I'm not sure it's the "right" way to do it.
>
> I suppose it's a matter for discussion (are you listening, Terry?) as
> to whether it's the "right" way to do it, but that's the way it's
> done.
Setting the baud rate to 0 is the traditionally correct way to drop
DTR. In System V. And we all know how much like System V we want
BSD to be... even when System V has good ideas (unlike that one).
Closing the port will work too, since DTR is asserted by the open
on non-CLOCAL devices (and on CLOCAL devices because we have to
accommodate incompetence in hardware design). You have to do that
anyway, because stupid drivers can't talk to a port without being
reopened after an on-to-off DCD transition has occured. But this
is justifiable, because of the oft-cited and never questioned
reference: "no good reason".
Depending on the DTR to be dropped "long enough" to reset the modem
and have it be done resetting is another matter. Traditionally, you
would "sleep(2);" before setting the baud back or reopening the
port, to get >1 - <3 seconds of DTR drop.
According to Bell 103C and Bell 212A ("Technical Aspects of Data
Communications", McNeely, Digital Press, ISBN: i_forgot_it), the
"signal break" time is supposed to be sufficient: 250ms. But many
cheap modems are in violation of the standards, and take more than
250ms to fully reset as if powered of-then-on on DTR drop, like
they are supposed to... so "sleep(2);" should probably not be
replaced with the shorter delay of a "usleep()" call, for fear of
allowing those of us who buy good hardware to run at a reasonably
responsive speed.
FreeBSD supposedly tries to do the responsive delay for you,
but you probably need the "sleep()" call anyway, since you
are probably in on the "make the good hardware run as badly as
the bad hardware so the people who bought it don't cry" conspiracy.
If you look at /usr/include/sys/ttycom.h, you will see TIOCCDTR
and TIOCSDTR. BSD would traditionally allow you to toggle DTR
this way. But now "POSIX knows best" says we should all use
the kludge of setting the baud to 0 (back in the "BerkNet"
days, this meant "use the external RS232 clock that Intel was
too stupid to implement for their supposedly RS232C standards
compliant UARTS"). God knows how POSIX wants you to get a signal
vs. a non-signal "BREAK" (103C defines 250ms of break as a line
disconnect request, and less than that as a signal break. The
difference is, one hangs up the line and the other sends a break
to the remote machine. VT100's get this right: the break is
asserted for as long as you hold the break key -- all hail DEC!).
Most modern modems ignore long breaks, in violation of 103C and
212A, because modem designers are idiots.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709090910.CAA27827>