Date: Wed, 14 Feb 96 22:10 WET From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: freebsd-hackers@freebsd.org Subject: Re: An ISP's Wishlist... Message-ID: <m0tmv1B-000CU9C@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[0]Getty should track modem disconnect codes, reset the modem, and [0]notice incoming faxes. I've already modified the default getty [0]to notice PPP connects, but that's needed here too. [1]Modem disconnect coeds are as good as impossible to catch; some modems [1]emit then before dropping DCD, so there's no way of knowing that they [1]_are_ disconnect codes. To do this properly would require major [1]modifications to the serial driver(s). Most modems allow you to interrogate them AFTER the call has completed to find out the cause of the failure. Nearly all modems based on Rockwell chipsets do this, so do most AT&T, and Sierra chipset designs. The simplest thing would be to have something other than getty reacquire the port after a disconnect, query the modem, then reset the modem and exec the real getty. Personally, I always run dialup/dialout modems in ATW2 mode, so that the modem sends NO information back to the host on incoming calls. It is far to easy for the modem and getty to get into a war. Once the call has ended, then an AT command can find out the final word on the call. Don't be too hopeful about getting useful information; unless both modems honor tear-down negotiations, you might see a lot of "loss of carrier" on calls that completed successfully, and the other party forced their modem on-hook by dropping DTR and the modem simply went on-hook rather than performing the tear-down first. Some modem makers do it right, some don't. [0]Better support for CDROM changers: it would be nice if it figured [0]out a mount point by looking at the disk the way that Solaris does. [1]Not enough disks have meaningful identifiers; still, this could be [1]done with a shellscript. Good point, but we have done similar things in CD-audio player applications. In those applications, we attempted to read the UPC to ID the disc. If there was none, (or in addition), we used the toc entries (starting minute, second and frame of each track) to construct a hash. The hash would then be used to search a table to get the preferred play order for that disc. The same technique could be used to ID discs and mount the where you desire based on a table stored somewhere. Since not all drives are able to provide the UPC field, using the TOC entries is pretty idiot-proof. Frank Durda IV <uhclem@nemesis.lonestar.org>|"Look, he has two cents." or uhclem%nemesis@rwsystr.nkn.net |"What, all of them?" ^------(this is the fastest route)| or ...letni!rwsys!nemesis!uhclem |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tmv1B-000CU9C>