Date: Tue, 25 Apr 1995 23:45:37 +0200 From: gert@greenie.muc.de (Gert Doering) To: terry@cs.weber.edu, timb@thud.cdrom.com, freebsd-questions@FreeBSD.org Cc: neko@greenie.muc.de (Simone Demmel), knarf@nasim.cube.net, mgetty@muc.de Subject: Discussion about mgetty... Message-ID: <m0s3sQM-00003KC@greenie.muc.de>
next in thread | raw e-mail | index | archive | help
Hi,
some kind soul forwarded this to me, and I feel I simply have to react,
because some statements in this mail concerning mgetty where blatantly
wrong, and I feel somewhat attacked by statements like "mgetty is bad", if
in the same mail the author shows that he doesn't know much about mgetty's
inner workings.
I'll comment only on places that are wrong (or that I happen to have a
different opinion on). Much of this stuff is perfectly allright, e.g the
modem setup issues (&C1, &D2, CLOCAL and SIGHUP, ...) or the state diagram
(only the mgetty issues aren't).
> From: terry@cs.weber.edu (Terry Lambert)
> To: timb@thud.cdrom.com (Tim Bach)
> Date: Tue, 4 Apr 1995 20:04:36 +0200
> Cc: freebsd-questions@freebsd.org
[..]
> The modem should "reset as if powered of and turned on on an on-to-off
> transition of DTR from the computer".
>
> On modern Hayes modems, this is AT&D2.
Ummm... not really. Reset-as-if-power-cycle is usually &D3. &D2 is usually
only "hang up and return to command mode".
[..]
> The practical effect of the /dev/cua0/cua1 device will be the setting
> of the terminal modes HUPCL and -CLOCAL; you should log in through the
> modem and type "stty -a" to make sure these settings are present.
Well, many (that is, *all I know of*) getty programs set the termio(s)
values to something sane anyway. It's getty's purpose to set them, not to
rely on some driver defaults.
> In incorrectly configured program (ie: mgetty) could result in the
> flags being set incorrectly after login.
What do you mean by that? mgetty does definitely set HUPCL and -CLOCAL
(I'm not *that* dumb). It did from the very first release.
Did you ever try it?
> The use of "mgetty" is a problem. The "mgetty" program differs from
> the "getty" program in that it opens the port and hangs on a read
> waiting for the modem to announce a baud rate so that it can set
> line speed.
Partial true. Mgetty *can* do it (since some modems insist on switching
baud rates), but the default is to read the CONNECT message only for
informational and logging purposes. One of mgetty's big advantages is that
the user can always exactly see in the log files which state the modem
was/is in, and what did exactly happen when.
> The ability to open without DCD present is a real
> problem, in that it defeats the purpose of a calling unit device
Well... we had a longish discussion about the "calling unit devices" in
the Linux kernel mailing lists two months or so ago, and finally, nearly
everyone (including the serial driver's author) agreed that the tty/cua
distinction is a hack to get ill-behaving applications to work.
The "classic" approach is to use one device for one physical device...
> and thereby thwarts the normal modem login sequence.
It doesn't. Ever heard the term "uugetty"?
> A normal UNIX login sequence operates as follows:
[..]
> 1) The modem comes on; the computer is not in multiuser
> mode, so DTR is not asserted. The mode will not
> answer the phone until DTR is asserted.
What do you do if your machine crashes, leaving DTR asserted? It *does*
happen occasionally. If you have a modem that auto-answers, your modem
will pick up the phone, and the callers will have to pay to the Telco...
[..]
> 11) The modem answers the phone. Its first act is to report
> its "CONNECT <baud rate>" message to the computer.
>
> 12) Like other input prior to DCD being present, this data
> is ignored.
And now, we come to a far more important problem: to have the maximum
flexibility, you have to be able to cope with modems that raise DCD
*before* sending the CONNECT string. There are *many* of them around,
and with a "classic" approach, you can only handle them if you switch
off modem responses (which is nasty for parallel dial-outs).
So, what do you do? You use a getty program (mgetty, that is, or getty_ps,
or others) that does know about CONNECT strings.
BTW: in this step, you can as well do the distinction whether the incoming
call was a FAX or DATA call, and handle both accordingly. Major plus for
mgetty and FlexFax.
> 16) If the user does not see this, they send "break" signals;
> the "getty" changes the baud rate and reissues the prompt
> for each break signal received.
Now this is something I call severely dumb. We're talking about smart
modems, remember? All of them can be set to a fixed DTE baud rate, so
there isn't any need for baud rate switching anymore.
*If* it has to be done, then, by all means, read the CONNECT string and
handle it the way it is meant to be.
Having the callers send <break> signals is something that will work for
Unix experts, but the average Joe User doesn't want (or should) to know
about it. He wants to see a CONNECT and then a "welcome" banner, no break
signal fiddling.
> particular line, as well as the default line settings for
> each are stored in the /etc/gettytab file.
Well, mgetty can't read gettytab, but it can read gettydefs (SYSV-ism),
which is - IMHO - far more powerful, though I detest it as well (personal
dislike for cryptic formats).
[..]
> [Modem connection failing immediately after CONNECT]
> This is exactly the situation if the computer has an input present
> before DCD is raised and echos the "RING" or "CONNECT" messages
> back to the modem.
This is exactly the reason why it is a GoodThing to have a getty process
that knows about RING and CONNECT and *doesn't* echo it back to the modem.
Don't we all agree here?
> If the mgetty incorrectly sets CLOCAL or -HUPCL in its effort to
> open the port without DCD being present, ...
It doesn't. Well, it does, but as soon as carrier is present, the CLOCAL
flag is reset, and the -HUPCL flag is set. There *is* a small time window
(about 50-100 ms or so) where the DCD line is high, but CLOCAL is still
set, but if the connection is lost in that place, mgetty will notice as
well (doesn't have to rely on SIGHUP here).
> ... this will prevent normal operation.
Normal operation isn't touched by this in any way.
[..]
> If the mgetty/getty is started on a tty device instead of a cua device,
> the default port settings will not include -CLOCAL and HUPCL, and
> the connection will not behave as expected.
Who cares for default settings? It's getty's *JOB* to set the termios
settings to something specific, not to rely on the defaults.
Mgetty very well knows about possibly-wrong defaults and sets the flags
properly.
[...]
> The "mgetty" program is bad.
I tend to have quite a different opinion here :)
> It should not succeed in the open
> without DCD present; this prevents the port for being used for
> dialout without killing the "mgetty".
This is *WRONG* (dammit). If the programs create proper UUCP lock files,
they can dial out while mgetty is running without any difficulties.
Admitted, they must not use a different device in the tty/cua device pair,
but as long as the same device is used, shared dial-in/dial-out is very
easy.
> The correct way to open the port without DCD present is to use the
> O_NDELAY flag; this has the side effect of setting no delay on reads,
> when you probably do not want this,...
Huh?? Now I am really puzzled. Did you *EVER* *LOOK* at mgetty? mgetty
*does* open the port with O_NDELAY. Did from the very first release.
Naturally, CLOCAL has to be set as well, because many serial drivers won't
read from the device, even if the open() has succeeded, if CLOCAL is unset
and DCD hasn't been raised yet.
> ...with no way to unset them.
Nonsense. Ever read the manpage of fcntl() in recent Unixoid systems?
You *can* reset O_NDELAY (or O_NONBLOCK, definitions differ) with
fcntl(), and it works very well on Linux, Free/NetBSD, BSDI, SVR3/4,
SunOS, Solaris, you-name-it-all. Even on the AT&T 3B1 UnixPC!
Let me cite from the source code:
----------
if ( ! blocking )
{
fd = open(devname, O_RDWR | O_NDELAY | O_NOCTTY );
if ( fd < 0 )
{
lprintf( L_FATAL, "cannot open line" );
return ERROR;
}
/* unset O_NDELAY (otherwise waiting for characters */
/* would be "busy waiting", eating up all cpu) */
fcntl( fd, F_SETFL, O_RDWR);
}
----------
> The correct procedure is to: open with O_NDELAY, open a second time
> without O_NDELAY (the second open will not block because there is
> already an open on the port), and close the first open. This is
> called "the partial open hack", but in reality it is not a hack
> (unless you consider the overloading of O_NDELAY in the first place
> a hack).
Well.... one could do this on systems where fcntl() isn't able to reset
O_NDELAY, but I've never seen one.
Very old SCO Unix variants are rumored to have a bug in open() that will
make this necessary as well, but I have compiled and run mgetty on a SCO
Unix 3.2v2.0 machine (about five years old), and never seen any problem.
> The "mgetty" program should be rewritten to use an open flag that
> causes the open to hang until a "ring indicate" signal is seen
> instead od waiting for DCD. The driver should be rewritten to
> accomodate this.
That is an interesting (and very reasonable!) approach. It has been
suggested by other very competent persons before.
Unfortunately, de-facto standards make this impossible. Many multiport
cards don't even wire the RI line anywhere. No commercial unix vendor will
support this. So, are you really willing to sacrifice portability here?
> Then the "mgetty" should do it's reads normally;
> an alarm should be set so that if DCD (a "CONNECT" message) does
> not occur within a set period of time, the mgetty closes the port
> and reissues the open.
This approach won't work too good. It's better to monitor the port for
"good" (CONNECT) and "bad" (NO CARRIER) strings. Reason: if you want to
do a timeout, it has to be quite long, to accomodate the time until the
desired number of RINGs (S0) and the maximum no-connect time (S7) has
passed. This gives a large time frame to collide with outgoing processes.
gert
--
Final exams... second half... limited time... bad mood... stop... :)
//www.muc.de/~gert
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-3244814 gert.doering@physik.tu-muenchen.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0s3sQM-00003KC>