Date: Wed, 26 Apr 1995 10:26:12 +0200 From: gert@greenie.muc.de (Gert Doering) To: terry@cs.weber.edu (Terry Lambert) Cc: 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: <m0s42QG-0004xaC@greenie.muc.de> In-Reply-To: <9504260048.AA03107@cs.weber.edu> from "Terry Lambert" at Apr 26, 95 02:48:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
Terry Lambert wrote:
> It wasn't intended as an attack,
Good (since that usually leads to bad blood and no more).
> it's just that there seems to be a
> trade between dialout capability and mgetty capabilities.
I don't think so. Dialout has to be done a little bit differently, but
(usually) isn't harmed by mgetty.
> I'm more than willing to discuss any of this; the problems I see in
> mgetty and which I reported in the posting are primarily the result
> of mgetty trying to solve a problem for which OS support should exist
> but doesn't. The problems aren't directly attributable to mgetty itself,
> although it suffers from them as a result of the OS deficiencies.
Agreed.
> > [ &D2 vs. &D3 ]
> I screwed this one up. It was retracted in a followup posting; I was
> looking at a multimodem 224E manual when quoting this, and it wasn't
> quite hayes compatible.
Which is only a minor issue anyway (at least for those people that can
read modem manuals).
> > > 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.
>
> Most drivers do templating, and the templating in BSD modem control
> drivers in a traditional (ie: Sun) implementation sets these flags. Most
> of the gettytab definitions don't permit these settings to be changed.
Doesn't BSD getty modify the defaults anyway to something "sane", and then
modifies *this* according to the gettytab? I have to admit I didn't look
into the BSD getty sources ever, I just know SysV and some free getties,
and they all do.
[..]
> Traditionally, the CLOCAL and HUPCL flags are not settable nor are set
> by the getty program because of adverse effects; specifically, the
> setting of CLOCAL to -CLOCAL without carrier present will (is suppose
> to) result in the same effect on the device as if there had been A DCD
> loss on a line where DCD was present.
Yes, agreed. This does happen on a number of platforms, and for that
reason, mgetty takes care to make sure DCD is present before clearing
CLOCAL.
> The setting of -HUPCL to HUPCL can result in the deivce acting as if it
> had been closed and dropping DTR to the modem, potentiall severing the
> active connection. In general, it is not permissable to change these
> "meta" flags while the modem is on line.
Hmmm. I just checked mgetty's sources, it doesn't change the HUPCL
settings at all. On port initialization, HUPCL is set, and it's never
modified before calling /bin/login.
I haven't seen a system lowering DTR when modifying the HUPCL state yet,
but I don't take any riscs there either.
[..]
> This is acceptable for dialout because dialout programs are not the
> process for the dialout line is the controlling tty. This is because
> correct operation requires that a call-in caller calling out on a
> seperate modem from the one dialed in on *must* correctly lose his
> session when the connection between his modem and the machine is lost,
> and resetting the controlling tty would preclude SIGHUP delivery, since
> each process mah have only one controlling tty.
I *have* seen a few processes (namely a pppd) that insists on taking the
dial-out tty as controlling tty (to get a SIGHUP if that line gets lost),
but besides that, I agree.
> Similarly, it is typical in a hard-writed terminal connection to wire
> terminal DTR to serial port DCD so that if the terminal is powered off
> (as a typical end user might do at the end of the day), security is
> maintained by destroying the user's connection to the machine by
> allowing the session for a direct connected terminal to honor -CLOCAL
> seperately from HUPCL.
Sure.
> > > 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?
>
> Yes, I did.
Well, ok, but how can you make statements like this? All the flags are set
properly according to your definition (if not locked in the serial driver).
> The problem I have is in the opening of the port prior to
> a connection being present, thereby precluding use of the port for
^^^^^^^^^^^^^^^^
> bidirectional (both incoming and outbound) use.
No, that's not true. I use mgetty for dial-in and uucico/sendfax/kermit
for parallel dialout on the same line on a large number of systems
(FreeBSD 1.1.5 among them), and it *works*.
[..]
> > 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 an advantage for non-bidirectional use. However, in bidirectional
> prot implementation, when an incomming port open has succeeded, then an
> outgoing open will be blocked until the connection goes away (or if it
> is opened with O_NDELAY, the open will return EWOULDBLOCK).
Yes, I know that. To handle this properly requires additional work in
mgetty, which is quite simple after all:
1. mgetty open()s the port and uucp-locks it.
2. mgetty initializes the modem
3. the uucp-lock is removed
4. mgetty select()s on the tty, to wait for "something to happen".
5. mgetty tries to uucp-lock the port. Success -> 6a, Failure ->6b.
6a. locking succeeded. mgetty waits for RING, sends ATA, waits for
CONNECT, prints /etc/issue, waits for the user login name, calls
/bin/login.
6b. locking failed. *DIALOUT* in process.
7b. mgetty closes all filedescriptors to the serial tty (which won't
cause a DTR drop, since the dialout process has the line open)
8b. mgetty patiently waits for the UUCP Lock file to go away
9b. mgetty exits, and init restarts it.
This is somewhat simplified, but should give you a good idea, why it
*does* work, as long as all programs honour the UUCP locking conventions.
> > > The ability to open without DCD present is a real
> > > problem, in that it defeats the purpose of a calling unit device
[..]
> And then make the "uugetty" (or in this case the "mgetty') wait for
> a carriage return following DCD before emitting a login, and allowing
> [some complaining about uugetty removed]
> This is clearly much more of a kludge than having device synonyms with
> implied (and therefore more reliable) locking in the kernel.
Your description of uugetty's inner workings are (mostly) correct.
Nevertheless I (and others) think device locking belongs into usermode,
not into kernel mode, because of the greater flexibility gained by this.
The benefits of direct modem control *are* there, and since they do not
harm dial-out (well, the cost a few cpu milliseconds checking for the
dialout process), why not use it?
(One of the major difference between mgetty and uugetty is that mgetty
doesn't "wait for CR" but select()s, which doesn't steal characters from
dial-out processes).
> > > and thereby thwarts the normal modem login sequence.
> > It doesn't. Ever heard the term "uugetty"?
> Yes. See above why it is a kludge.
Anyway, what I meant was, this *is* part of the "normal" modem login
sequence, as invented by the powers that invented uugetty...
[..]
> > > 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...
>
> You fix the hardware.
You're right, that approach is even better. Nevertheless, having some
additional conceptional(!) protection against faults somewhere is a
GoodThing.
> > > 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).
>
> I disagree. The Tandy DT400 does this, but it's ^N escape character
> makes it useless for binary file transmission anyway. The AT&T 4024
> series of modems also do this by default, but it is programmable and
> thus you can get rid of the behaviour.
You disagree? I haven't looked into it recently, but there's so many
ill-behaving modem junk around that it's very likely some cheap
mass-product (shall I say "Rockwell"?) will get this wrong. And what will
you do then?
Better modems, e.g. the ZyXEL series, have flags to control the DCD
behaviour. Nevertheless this is an additional source for mistakes when
setting up the modem, so why bother caring for the DCD timing at all?
> Reporting connect AFTER connect but before DCD has been raised to the
> computer is mandated by the Hayes standard.
Hmmm. I'd like to see that in written form somewhere. Besides, I know how
many modem manufacturers feel about "standards"...
> Other than the examples above, I think you'd be hard pressed to find
> modems which do this that can not be reconfigured to *NOT* do it.
You have a point here -- I can't name any one either. But I'm fairly sure
there are. I've seen *that* many broken modems...
> > 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.
>
> I understand that. Again, that's the unidirectional soloution. The
> correct way to handle it would be to not allow the open to complete in
> the kernel until a RI is seen, and set the modem for 2 rings to ensure
> that one is sent to the computer before the modem answers. This is a
> kernel driver problem in that there is not (currently) a flag to open
> to cause this behaviour.
Well, what's the gain if you have the modem auto-answer? One could combine
your and my solution to this:
* the open() sleeps until RI is seen.
* RI is seen, the open() completes, x-getty takes control of the modem,
waiting for desired number of RING messages
* x-getty sends ATA, handles CONNECT/+FCON properly
-- you don't lose anything by not doing auto-answer, but you gain a lot.
Now that would be really nice... if it wasn't too late to get this done.
> On the other hand, if the open has competed prior to an attempt to
> connect to the machine, the only alternative for an outbound connection
> program is to open the port itself and *manually* kill off the mgetty
^^^^^^^^^^^^^^^^^^^
> (requiring the acquisition of apropriate priveledges to make this a
^^^^^^^^^^
> realistic alternative). This is worse than just a kludge, it's a blatant
> security hole.
What??? You are talking complete nonsense here (sorry). Mgetty will give
up the port peacefully when a dialout is detected. No need for and special
privileges (except rw-access to the device and the UUCP lock directory).
You are right insofar as this *is* a (minor) problem, since all the programs
have to agree to use the same device and the same lock file name and format.
[..]
> > *If* it has to be done, then, by all means, read the CONNECT string and
> > handle it the way it is meant to be.
> Sure, as long as that read is not pending except during the connection
> attempt itself so I don't have to buy a second modem and phone line to
> be able to dial out.
You don't have to. I have three modem lines, and use all of them happily
for dial-in and dial-out.
[..]
> The only other alternative, as you pointed out, is locking the DTE
> baud rate and accepting the problems that come with doing that instead.
Or parse the CONNECT message for the connection speed (but I do not like
*that* because it isn't 100 per cent reliable for different reasons either).
> [ dislike for cryptic configuration files ]
> We agree here. 8-).
Good :)
> > > [Modem connection failing immediately after CONNECT]
> > [ not echoing RING / CONNECT back ]
> I agree that it should not be echoed; how you arrive at not echoing it
> is another thing altogether. Whether it's because the computer is not
> in a state that it can echo things back because it is watching for wire
> signals or it's because there's a read posted without the line being in
> a cannonical processing mode to not echo it is irrelevant.
Agreed.
> What *is*
> relevant is whether the approach you chose screws with your ability to
> use the hardware the way you want to use it (ie: for dialout).
It doesn't :)
You may have to change a few applications to honour the uucp locking
protocol, but besides that, you won't have to undergo any efforts.
> > > 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).
>
> Agreed -- on the other hand, it relies on the driver not acting quirky
> on port settings changes (many older drivers do).
Hmmm. I've seen a lot "quirky" things in serial drivers, but the only
thing that happens regularily on changing serial flags is flushing of
the input or output buffers -- which doesn't harm me, since I there isn't
anything in either buffer when I change settings (unless the user has
fallen on his keyboard, in which case it won't matter either).
Quirks like SunOS' broken hardware handshake and such won't hurt me here.
Do you have an example of such a broken driver with its "quirks" for me?
I'd like to know whether there are machines where my approach won't work.
[..]
> > > ... this will prevent normal operation.
> > Normal operation isn't touched by this in any way.
>
> Normal dialout operation when a connection is not present, but while
> mgetty has a non-echoing read posted that will prevent a dialout program
> from communicating with the modem.
Not true, since mgetty doesn't read(). It does select(), which won't
"steal" any characters.
> > > 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.
>
> I'd argue this for the CLOCAL and hUPCL flags (but *only* for those -- for
> all other flags, you are in fact correct). I'd also put forth Sun and
> SVR4 serial drivers as arguments on my behalf.
I never doubted that you are right concerning the default settings of
HUPCL and CLOCAL, and maybe the ignorance of their state on some BSD
getty. I *do* say that mgetty does set the flags properly, regardless of
the defaults the port set to at open().
(mgetty didn't do that all the time, but has matured quite a lot...)
[..]
> > > 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.
> How do you prevent the mgetty read from reading the responses from the
> modem to the dialout program when you must post the read after the open
> and before the appearance of the lockfile?
I use select() or poll() where it is available and working. If neither is,
I have to fall back to read(), which will eat away a few characters from
the dialout process (which *is* bad). Nevertheless, even with read(), by
using something like
AT OK-AT-OK-AT-OK
in the dialout programs chat script, you can easily work around this.
[..]
> Again, I'll admit that it's the only option you have with the brain dead
> serial drivers you are working with to get the functionality you want to
> provide.
Ok. I think we agree that quite a lot in the serial drivers could have
been better thought out.
I think your main point of criticism boils down to your assumption that
mgetty will prevent parallel dial-outs, unless "killed away" with some
"ungetty" method, which isn't true under normal circumstances.
> > > 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.
>
> I was describing the partial open hack, which was first introduced in
> SVR3.2 with HDB UUCP (the same time kill 0 was introduced).
Ummm, I understood this as "this is the proper way, and mgetty doesn't do
it that way!" -- that's why I reacted that way.
> > 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.
>
> Not true. All SVRx drivers and All Xenix drivers (except for an early
> release of Xenix 2.3.0, and Intel 320 serial drivers on a rev B serial
> board when accessed over Intel OpenNet) are succeptable to the partial
> open hack.
Uh? Ah. Reading on, I see that you're mainly talking about O_EXCL, which
doesn't apply here (since mgetty doesn't use it at all).
I still don't see why the partial open hack should be needed anymore, as
long as O_EXCL isn't used.
> > > ...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!
>
> Early Xenix (whose I/O was based on V7), Microport, and Cubix (a modified
> Microport) was not succeptable to this. Neither was SVR3.1.
Hmmm. I have to admit I didn't try it on those systems yet (does anybody
know what kind of unix the AT&T 3B1 UnixPC is? Is it 3.1 or 3.2? fcntl()
works definitely that way there).
> The Altos
> 2000 "multidrop" serial boards, which used a single event queue for reads,
> writes, and ioctl()'s (requiring that you use multiple processes as reader
> and writer -- startlingly similar to pre 5.2 VMS serial I/O) would block
> the fcntl() indefinitely, although it worked fine on internal serial ports.
> The fcntl(0 was totally unsupported on Intel OpenNet both on the Intel
> 310 and 320, and was also not supported via Touch communications OpenNet
> implementation for PrimeOS.
What are all those systems? I've never heard about anyone still using
them. (That is, noone ever asked me whether mgetty will run there, and I
haven't seen one of them myself yet)
> > > 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
[..]
> > Well.... one could do this on systems where fcntl() isn't able to reset
> > O_NDELAY, but I've never seen one.
> I'll introduce you some day, if you are anywhere nealy as interested in
> hardware antiquities as I am. 8-).
Well, I am, maybe not that much, but nevertheless (I still have + use my
old Commodore 64 :) ). Anyway, I don't really think that problems with
this old systems should be used to consider nowaday's programming
techniques.
[..]
> > > 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.
> Yeah, I never claimed it wa my original idea. 8-).
Why *hasn't* it been implemented somewhere?
> > 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?
>
> The portability sacrafice buys directed dialout capability
Ummm... we disagree here, I have the dialout capability already :)
It will make things cleaner, though.
[..]
> The only real difference in the BSD approach is the calling unit device,
> and that's just a cosmetic niceity to avoid all of the lockfile compatability
> grap that even Pete Honeyman got wron on one occasion...
Lots of other people did so as well, and this *is* quite annoying :(
Anyway, tell me when the *BSD driver supports a RI flag, and I'll try to
adapt mgetty accordingly.
[..]
> A lot of serial drivers, especially SCO, even the most recent ones, have
> bad code handling of the RTS/CTS flow control, such that if it is enabled
> but isn't present (for instance, an older Microcomm modem, to name one of
> several), it will hang the driver. SunOS pre 4.1.3 has this problem in
> a big way, and it was quite easy to get it into a wierd state where you
> need to reboot to fix it.
Agreed. Having an additional timeout is definitely a GoodThing.
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?m0s42QG-0004xaC>