Date: Fri, 16 Feb 1996 11:23:11 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: uhclem@nemesis.lonestar.org (Frank Durda IV) Cc: freebsd-hackers@freebsd.org Subject: Re: An ISP's Wishlist... Message-ID: <199602161823.LAA05077@phaeton.artisoft.com> In-Reply-To: <m0tnFFp-000CqQC@nemesis.lonestar.org> from "Frank Durda IV" at Feb 15, 96 07:46:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [2]Most modems allow you to interrogate them AFTER the call has completed > [2]to find out the cause of the failure. Nearly all modems based on > [2]Rockwell chipsets do this, so do most AT&T, and Sierra chipset designs. > > [3]A correctly configured modem will reset on the last close because of > [3]the on-to-off DTR transition. > > But that is not what he wanted in this situation. Doesn't matter; barring observation of DTR drop, there's no way to cause a modem to reset under software control,short of external circuitry to power-cycle it. > [2]The simplest thing would be to have something other than getty reacquire > [2]the port after a disconnect, query the modem, then reset the modem and > [2]exec the real getty. > > [3]What you propose would require significantly rearchitecting the tty > [3]revocation model (specifically, to exempt init but not its children) > [3]so that the DTR would not drop until the query is complete. > [3]This could not be done while maintaining compliance with POSIX termios. > > Uh, I was trying to solve the problem for an ISP who really doesn't > care about POSIX-anything. If it does what he wants and he is happy, > it is compliant in a more important way. > > He can already do his completion polling easily with UUCP connections. > For other calls, there are other ways to hold DTR (including a dummy process > that holds it open) until the information is recovered. We use to do this > with Apple Laserwriters so that the printer response messages would not > disappear or get truncated when a file being printed ended (serial printer). > There is a solution to this problem, that's all. Agreed. But the cure is worse than the disease. It's important for an ISP to be able to soft reset modems. To allow DTR drop to continue to function correctly, you need a program to get control of the modem after the DCD drop causes the SIGHUP and revocation of the tty. The port ownership is chained, not wrappered, in both POSIX and in the tty driver implementation in BSD. What you suggest is that the last close not drop DTR, and have getty, or a program other than getty that later exec's getty, query the modem for the reason for the disconnect (assuming the modem supports it), and then forcibly drops the DTR so the modem resets (as expected). This would require a mod to the tty driver and a modification to getty, in the simplest possible case. Such a mod would be unlikely to make it into release, unless it was as a replacement getty and #ifdef's, since it would require losing standards compliance to make it work. That's a lot of work to support more-expensive-than-average modems that most-people-including-ISP's don't have. Never said it couldn't be solved. Only that he will probably have to do the solving himself. Terry Lambert terry@lambert.org --- 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?199602161823.LAA05077>