Date: Wed, 26 Apr 1995 01:49:01 +0200 (MET DST) From: knarf@nasim.cube.net (Frank Bartels) To: gert@greenie.muc.de (Gert Doering) Cc: terry@cs.weber.edu, timb@thud.cdrom.com, freebsd-questions@FreeBSD.org, neko@greenie.muc.de, mgetty@muc.de, nox@jelal.nasim.cube.net (Juergen Lock) Subject: Re: Discussion about mgetty... Message-ID: <m0s3uLm-000OJKC@nasim.nasim.cube.net> 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 wrote:
> 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.
True. I really don't want to miss this feature of mgetty.
> > 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...
True. A machine either crashes and reboots immediateley or the machine
just `hangs' (usually when the admin is not present). With mgetty both
cases are never a problem, the machine will only pick up the phone if
the machine is really ready to accept a call.
> 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).
Nasty? Switching off modem responses to behave like a directly
connected terminal is totally braindead in my eyes. Checking the modem
in regular intervals (AT->OK) would be nearly impossible.
> 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.
Do not forget the voice capabilities of vgetty (which is part of the
mgetty distribution).
> 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.
No comment needed here, I hope.
> > 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).
I also never missed any of those files.
> Who cares for default settings? It's getty's *JOB* to set the termios
> settings to something specific, not to rely on the defaults.
Under FreeBSD you are able to lock a device in a predefined state (for
example via the cual0n device). This is usually done in /etc/rc.serial
and it's always a bad idea to to this (really cannot imagine where
this could be really needed). *This* could be the problem of the
original poster. Since I use mgetty I *never* noticed a process
hanging on one of the serial ports (except for pppd, which ignores
all signals under FreeBSD if you use proxyarp, but that's another
story and not mgetty related).
> > The "mgetty" program is bad.
>
> I tend to have quite a different opinion here :)
Me, too. mgetty is great! I use it with a couple of modems under
SunOS4 and FreeBSD here, and it also works fine unter *beep* and some
other really bad systems like SINIX (no controlling tty on the serial
port!) or Interactive.
> > 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.
No problems here. FreeBSD is not *beep* where every program is
precompiled with different lockfile-paths and -styles. If you compile
a new program using a serial device, all you have to do is to make
sure it uses the same lockfile-path and style as all the others do.
This is not too hard and it's a good idea even if not using mgetty.
> 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.
Yes, with the current behaviour of mgetty dialin-/dialout-collisions
usually do not happen. Sure, there is a race condition, when the
dialout process sends ATD and someone tries to dial in and the modem
cannot send RING fast enough to cause an abort of the
dialout-chat-script. But this will also happen if you monitor RI.
Bye,
Knarf
--
Frank Bartels | UUCP/ZModem/Fax: + 49 89 5469593 | MiNT is
knarf@nasim.cube.net | Login: nuucp Index: /pub/ls-lR.nasim.gz | Now TOS!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0s3uLm-000OJKC>