Date: Wed, 26 Apr 95 12:34:48 MDT From: terry@cs.weber.edu (Terry Lambert) To: gert@greenie.muc.de (Gert Doering) 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: <9504261834.AA07857@cs.weber.edu> In-Reply-To: <m0s42QG-0004xaC@greenie.muc.de> from "Gert Doering" at Apr 26, 95 10:26:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. This is (slightly) objectionable from a commercial software standpoint, although all of the commercial comms software I've worked on (TERM from Century Software being the most notable) can work around the problem. It *is* a problem if cu doesn't pre-assert the lock file. > > 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. Well, here's a small bone of contention for me. The FreeBSD driver does in fact do this, but Ultrix, SunOS, and Reno do templating, and do it right. > 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. Well, this particular example makes sense. 8-). > > 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*. Ok, this is a different issue from select() vs. a posted read(), which is a special case problem only when there isn't a select or poll. My problem is that the HDB uucico has the O_EXCL flag set on opens to ensure it is the only opener -- and it will fail its open otherwise. It's the previous use and the lack of properly functioning templating that leave this flag set on an O_NDELAY open, even if you fcntl() it out of there (this is specifically for SVR3.2 and later, not using the port monitor code). This is also why the alarmed-out open as part of the partial open hack. The previously existing open blows the ability of the uucico to succeed in its open with O_EXCL set. You could probably argue that this was an unacceptable use of O_EXCL by uucico. The workaround prior to having the software do the alarmed open to unset the bit was to binary-patch the uucico to not set the flag on open. It's funny that HDB would use a slightly broken lockfile implementation and require the kill(0) change, and at the same time use an almost-working port access arbitration with O_EXCL that almost solved the problem as well instead of just mandating a change to the tty driver treatment of O_EXCL they way they mandated the addition of kill( 0). > > 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: [ ... mgetty dialout procedure ... ] I can see why you hate the implied locking in the calling unit devices in the traditional BSD drivers. 8-). I guess this is mostly because the CLOCAL and HUPCL state change peculiarities are mostly on BSD systems, and they're mostly the result of BSD not having to worry about this type of use because the modem controls in BSD have traditionally been wired in the calling units or (in the case of Sun) in the port flags (now *that's* an abomination). > 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 problem that still remains here is the UUCP 90 minute timeout on lock files, even if the process is still there. 8-(. > 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. I understand this from the use of select(); however, this assumes the non-O_EXCL opens by uucico aren't there. I suppose replacing the AT&T code with the Taylor code would be as acceptable a workaround as doing a binary patch on uucico. Otherwise the open() for the select() that won't eat the characters that the posted read() would eat will still prevent interoperability. 8-(. > > > 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. OK, I'll buy off on the ATA -- and an ATA with no carrier present *should* result in a "NO CARRIER" message (I'd give this the same probability as DCD being raised *after* the "CONNECT" message. 8-) 8-)). [ ... DCD raised before "CONNECT" message ... ] > 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? Well, what UNIX has traditionally done is spit a "login:" prompt at the modem before it sends the "CONNECT" message, and what modem's have traditionally done is mistake this for an attempt to hang up a dial out in progress, and then what users have traditionally done is return the modems. 8-). > > 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"... Well, overlooking intentionally badly designed hardware (or we'd have the modem providing external sync and not have to set our baud rate at all) the Hayes standards are available from Hayes, and modem behaviour is also described by the Bell 103C and 212 standards (and these are reproduced in "Technical Aspects of Data Communications" by McNeely from Digital Press). And don't tell me DEC doesn't know how to make serial ports; I know that already (as a proud former DEC Rainbow owner). 8-). > 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. Oh, yeah... I agree! That's the magic incantation I was thinking of in the first place; the main caveat I was placing was not interfering with software that already depended on the O_EXCL bit. > > 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). This was supposed to be "uugetty". 8-). > > 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). Yeah... Avatek modems, especially, which were dumped in large numbers when they first came out won't retrain unless reset. They stick at the baud rate (300/1200/2400) of the first caller after the reset. 8-(. And then there is aways misconfiguration and heinously wired cables. 8-(. > > 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. Or change uucico to not assert O_EXCL. OK, I grant this point. 8-). > > Agreed -- on the other hand, it relies on the driver not acting quirky > > on port settings changes (many older drivers do). [ ... ] > 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. Well, you don't mess with HUPCL, so that's half the battle right there. 8-). I believe that Altos UNIX (not Xenix) systems will get you on a CLOCAL change. I also think Xenix 2.1 and below will too. The Tandy 6000 will definitely bite. The 68k Xenix on Sun 3 hardware will do it too, although that's strictly a Microsoft internal product. Cubix and Microport prior to their SVR4 will also blow (but they're wierd anyway, with those tty1/tty1m/tty1M devices, they've got BSD calling units taken to a whole new level). I think the 3B2 SVR3.2 and below have the problem (I reported it to them and they actually fixed it after 3.2). The 3B1 *never* had the problem, but they have their own wierd things with whether the line is tagged as an audio line or not determines if you can use the internal modem dialer or not. > > 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. My age showing again. I rememeber when select() on a serial port meant two processes reading, one from the serial port and one from the other fd with a vmin of 1 or cbreak set, the same for the other fd being "selected", and a pipe in common between the two being written with tag tokens to identify the input source. 8-). Not that long ago, actually, that SCO didn't support select() on tty's, and even shorter time since it supported them, but only if you had TCP/IP installed. > > 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...) I'm probably making an out of date point there, then. That's good, since it means it's fixed, which is arguably more important then me being right. 8-). > > 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. Yeah, this was the point I was making here. And the bitch is that there is nothing you can do about it; at this point it becomes a trade-off if your dialer can't handle it correctly. 8-(. > 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. Nope; typo on my part -- the main point was preexisting programs that sdidn't play by the expected rules -- either lockfile or open flags. > I still don't see why the partial open hack should be needed anymore, as > long as O_EXCL isn't used. Interoperability with older HDB uucico, really. Replace it with Taylor and the problem goes away. You could argue it is a minor nit. > > 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). It's a 3.1 with a lot of extensions, only some of which showed up in 3.2 and most of the phone/port handling didn't show up at all. There's a lot to be admired about the 3B1 (in case people don't recognize the model number, it's the AT&T 7300 PC), like the first commercial use of shared libraries and the bitmapped console interface. It's a bad reference point because in many, many ways it was way ahead of its time. [ ... Altos 2000, Intel 310, Intel 320, PrimeOS ... ] The Altos 2000 was the first major system revision after the one where Altos moved from the 286 to the 386 processer (that resulted in the even numbered system revisions 686/886/1086, etc.). The Altos Xenix systems were unique in that they were the universal developement platform. Code from an Altos developement environment would run on Altos Xenix and UNIX, Cubix UNIX, Microport UNIX, SCO Xenix (and later SCO UNIX), Intel Xenix, Microsoft Xenix, Interactive UNIX (in an ABI mode) and several other platforms. If you could only afford one machine and did multiplatform coding, it was probably an Altos. 8-). The Intel 310 and Intel 320 were Intel motherboard based boxes that were OEM'ed by everyone. Every military installation that bought a machine on the Desktop III contract bought an Intel 310 or 320. The relevence here is that they were heavily used in the Defense Data Network in the US. The PrimeOS box was the Prime 386 box running their rev of UNIX SVR3 that was also a contender on Desktop III; I think that they were what really put Touch Communications "on the map". It's the fastes 386 box I have ever used. Suffice it to say that there were a grundle of these boxes out there at one time. > 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. Commodore PET with chicklet keyboard and integral tape drive, on which I can still load and run "Space Invaders". Once did a "Defender" game in 8k on the thing. 8-). Unfortunately my SWTP 6800 doesn't boot any more. 8~(. I think the argument against old systems is well taken, but I think by the same token, you could throw out "standard practice" and ask that the serial drivers be revamped to be more convenient for you. 8-). Terry Lambert terry@cs.weber.edu --- 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?9504261834.AA07857>