Date: Wed, 26 Apr 1995 13:43:22 +0200 (MET DST) From: Wolfgang Jung <wong@cs.tu-berlin.de> To: gert@greenie.muc.de (Gert Doering) Cc: terry@cs.weber.edu, timb@thud.cdrom.com, freebsd-questions@FreeBSD.org, neko@greenie.muc.de, knarf@nasim.cube.net, mgetty@muc.de Subject: Re: Discussion about mgetty... Message-ID: <199504261143.NAA09936@caramba.cs.tu-berlin.de> In-Reply-To: <m0s3sQM-00003KC@greenie.muc.de> from "Gert Doering" at Apr 25, 95 11:45:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Gert Doering
[...]
> > 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.
I did had similar Problems, with turned of CRTSCTS :-(
I checked the follwing situations:
a) while mgetty is waiting
b) after mgetty has written ....ogin:
c) afeter mgetty has started ..bin/login
d) when the shell was running.
Result: a,b,c where OK with CRTSCTS on
d the CRTSCTS setting was off
I looked in some other places and found: thw shadow PW Suite login
is doing some ugly things here (keep) after it has been satisfied with a
matching PW. (I have not fixed this for me, but it will be done some time
:-( )
But sure you cannot blame MGETTY :-)
> > 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?
he probably didn' check logins behavior :-(
> > 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.
This is OK for most cases, there is just drawback:
doing dialout on /dev/tty?* will set a lockfile. when the lockfile is
cleared (Dialouts won't last forever :-) it takes some 10-15 s for the mgetty to
take over the Modem again... This is a Problem with vgetty, since people
have to use either Datacallingtones (Not all Medems are capable of this ) or
a DTMF Tone (ie for the 9) to change from Voice to DATA. But this makes
the need for a strikt dialtiming, which is not exact possible ..
(This is almost impossible to solve, but I can live with it)
> > 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...
There is one Example for a machine doing this without crashes. while
starting up system services and stuff DTR is asserted and S0!=0 setted modems
do pick up get a carrier and thats it...
(This System is called NeXT , at least the black Version does this stupid stuff)
[..]
>
> 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.
Sometimes he is lucky and is successful after hitting Return , but
I never saw a getty working stabil with that :-(
> > 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).
:-) Since Modems are nice and will respond with NO CARRIER :-)
> > ... 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.
It works very well & stabil ..
ther is some Problem when you are using different lockstyles for UUCP & Mgetty
Mgetty wil honour Binary & ASCII , but Taylor UUCP won't. Taaylor would just
see a STALE Lockfile and removes it and finaly hangs competing with the shell
(BOTH will hang)
> > 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.
>
:-)
Gruss
Wolfgang
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504261143.NAA09936>