Date: Tue, 25 Jul 95 14:08:01 MDT From: terry@cs.weber.edu (Terry Lambert) To: harry@hgac.com (Harry Goldschmitt) Cc: bde@zeta.org.au, hackers@freebsd.org, ache@astral.msk.su, jkh@violet.berkeley.edu, pas@tonesoft.com Subject: Re: dial up at > 9600 baud Message-ID: <9507252008.AA16947@cs.weber.edu> In-Reply-To: <v01530508ac3a2146b865@[199.107.69.186]> from "Harry Goldschmitt" at Jul 24, 95 10:06:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I hate to butt in, most modern modems can be configured to a specific modem > to modem connect speed (which we did), but I haven't seen one yet that can > be configured for the modem to serial port speed! If you know of one, and > can prove it works (not just theory), let me know. We tried three different > modems, a 14.4 internal, a 28.8 internal and a 14.4 external, all from > different companies. Telebit Trailblazer Telebit NetBlazer Multitech Multimodem Microcomm US Robotics Sportster FaxModem (beware when talking to Rockwell chipsets!) > >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. > > See above, and try it! This was just a list of alternatives for port locking. Actually, port locking is a bogus thing to do. You get "peristalsis" from varying pool retention requirements. The cannonically correct thing to do would be to use a modem that set it's baud rate based on the RS232C external clock. Other than AT&T DataSets (modems which are generally low baud rate) and Racal-Vadic (which compromise between US and European carrier frequencies, resulting in mostly poor connections except with other Raval-Vadic modems), I really don't know of a modem which implements this according to the standard (well, I know one, but it's internal and it floats its DCD incorrectly instead of using a 150 Ohm pulldown). > >> 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. > > No no no. That's not what's happening in our case. We boot up, use slattach > at a speed of 38400, or whatever. It works at 38400. We kill slattach, Which causes DTR drop which a correctly configured modem will consider as a command to reset as if powered off then on. > configure etc/ttys so that the port is on, and do a kill -HUP 1. Which causes getty to attempt an open, wherein DTR is raised and the open blocks pending DCD going high (and the port sends *nothing* to the modem). > Guess what, dials to the port connect at 9600. Because either the default modem settings are wrong, the training order doesn't go the same direction on both modems, or the lin quality on the incoming connection is of lower quality, and that the highest rate that can be supported. Is this a long distance call? If it is, I recommned only AT&T or Telamerica, since the voice band compression and time division multiplexing that Sprint and MCI use are bad for digital bandwidth (they are using ATM backbones which implement "leaky bucket", so you can not get what you need -- a comitted rate. The only way to get a comitted rate is to go digital only. Even then, Sprint routes most if its traffic through the DC hub which has been flakey for two years now. > Somewhere in the driver, characters like AT are being sent at 9600, > which happens to be the ttydefaults.h setting. Wrong. Dead wrong. I have attached a serial line analyzer, and no such output is taking place from the getty or the standard serial driver. You are either running a non-standard serial driver, a non-standard getty, or both. Or the problem is not what you believe the problem to be (I think this last one is the correct one). > Not believing our eyes, we tried three different brands of modems, > two internal and one external. Same symptoms. We then modified > /etc/ttys back to turn the port off and kill init, yet again. We > then restart slattach at 38400, everything is fine. We also tried the > experiment with cu and tip. Every thing works but getty. Sounds to me like > the getty-killer is getty! No. In one case you are running an *outgoing* call, using your RBOC, LATA, whatever inter-LATA lines, and your LD carrier (if applicable). In the other case you are running a getty which implies an incoming connection. Using whatever alternate virtual circuit route is being taken by the caller. In one case, your modem is the passive party in the speed training; this is the case that works. In the other, your modem is the active party ; this is the case that fails, and probably has to do with train order on the callers modem -- the callers modem settings are the issue in this case. > Does anyone have a 14.4 or 28.8 modem? Can you beg, borrow or steal one. > If you don't think I'm telling the truth, try the above experiments! Two people in our office run 14.4 connections on a daily basis to get Internet connectivity -- without problems. > >> 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. > > > How about a Hayes compatible driver to set the modem. The modem can't > possibly know the modem to serial port speed until it can autobaud via an > AT command for Hayes. It is not *supposed* to "know the modem to serial port speed". It is supposed to be at a locked baud rate or it is supposed to *dictate* the speed by sending a connect message, either at a known or locked speed (subsequently resetting the port speed on the modem in the second case) OR it is supposed to send it at the speed it wants. Because the DCD isn't present, the port will ignore all input. The connect message is *suppoed* to be sent prior to the modem raising DCD. The *correct* "UNIX" way of baud rate training the port is to have a rotor list in the gettytab, and the caller is to send breaks (done in the "chat" script so the user doesn't have to deal with it) until they can recognize a "login:" prompt. The lazy way around having a "chat" script front end for you is to lock the modem-to-port baud rate (register S53 in Telebit modems, available in the command set otherwise on most other modern modems) and put one baud rate (the locked one) in the gettytab rotor list. > There is nothing in the RS-232 lines that can cause > the modem to do much until some data is transmitted - Tx. I agree that the > settings should be taken from the sio driver first, especiallly the lock > device. But someone, somewhere will want to reset the speed for a > particuar getty. On close, the port settings should probably be set back > to the initial driver settings. They are. This is called templating. This is the default rates Bruce has been on about (in /etc/rc.serial). > Like I said, every application we tried worked properly, except getty. And > it reset the port to ttydefaults. Yes it did. But there is no way in hell your modem could have possibly known about this unless it opened a race condition window by being incorrectly configured to ignore DTR, not have DCD follow remote carrier, the cable was wired to disable the correct operation of these signals, it's using the RS232C external clock signal, or you personally modified getty. 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?9507252008.AA16947>