Date: Mon, 24 Jul 95 20:50:08 MDT From: terry@cs.weber.edu (Terry Lambert) To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka) Cc: bde@zeta.org.au, hackers@freebsd.org, harry@hgac.com, jkh@violet.berkeley.edu Subject: Re: dial up at > 9600 baud Message-ID: <9507250250.AA12919@cs.weber.edu> In-Reply-To: <nVSs-4mSP1@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka" at Jul 24, 95 10:59:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Terry, you seems to miss a bit of discussion: situation is > pretty clear: modem inherits speed of previous access, if > it isn't configured to reset by DTR drop. That's easy. The modem is bogus and is incorrectly configured to work around the bogosity. Sounds like an Avatek modem. Jumper it/configure it to reset as if powered off then on on an on-to-off DTR transition. Problem solved. If the modem can't be correctly configured, get a new modem, or build a curcuit that will actually power cycle the modem on DTR on-to-off transition (a relatively trivial circuit). If the modem can't be correctly configgured, I *STRONGLY* urge replacing the modem. A Tandy DT1200 modem won't pass ^N characters, and I would hardly suggest hacking all comm software to avoid ^N to make the bogus modem happy. > It means that any dialout application which change speed > becomes getty-killer. > There is no error in the driver or in getty. > Solution for it already exists: > 1) Configure modem to gettytab speed and issue AT&W. > 2) Configure modem to do ATZ on DTR drop. Yes yes yes. > If we allow modem to not do ATZ on DTR drop, more complex > things will be involved in driver and getty, namely: > 1) Driver must issue "AT" command at first open > to give modem chance to sense speed. No no no. The Modem is idiotically "sensing" the speed. This is the problem in the first place. The driver should not "set" the modem, especially when these commands aren't going to work on non-AT command set modems that are otherwise non-bogus. > 2) driver must restore dialin speed in close and issue "AT" > command to give modem chance to sense speed. No, the driver must drop the DTR and lett the modem set the speed based on the negotiation is arrives at with the remote modem. > 3) getty must setup initial device with gettytab speed > for #1 & #2 will be successful. Yes. After the open has completed, since we do not want an intervening bidirectional use of the modem by a program doing a callout (ie: uucp) to screw the getty settings. The calling out program will cause an on-to-off DTR transition on final close of the calling unit device. Then the device will time the period of DTR down to > 250ms (the RS323C standard maximum drop time before a DTR must be acted upon) and after the time period has elapsed, it will raise DTR because of the pending open on the non-calling unit device. > Doing "AT" commands in the driver not nice thing, of course. Nor is it an allowable modification to getty. What is the purpose of sending these cmmands to set the port speed for the modem prior to dialing (this is what a locked port baud rate setting on a modem is for, BTW)? Is it to avoid having to do one of: o Lock the port baud rate between the computer and the modem o Have the user use the break character to cause the getty to rotor through its baud rate list o Use an mgetty type program to interpret the baud string following the connect message the three standard ways of setting the getty/modem communications rate? If so... why? 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?9507250250.AA12919>