From owner-freebsd-questions Mon Dec 8 19:15:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA19438 for questions-outgoing; Mon, 8 Dec 1997 19:15:32 -0800 (PST) (envelope-from owner-freebsd-questions) Received: from tok.qiv.com (ZStr5QmlQ6JFoklx5i+i2FXy1MzoMdat@[204.214.141.211]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA19423 for ; Mon, 8 Dec 1997 19:15:27 -0800 (PST) (envelope-from jdn@qiv.com) Received: (from uucp@localhost) by tok.qiv.com (8.8.8/8.8.5) with UUCP id VAA02650; Mon, 8 Dec 1997 21:15:11 -0600 (CST) Received: from localhost (jdn@localhost) by acp.qiv.com (8.8.8/8.8.5) with SMTP id VAA00597; Mon, 8 Dec 1997 21:02:09 -0600 (CST) X-Authentication-Warning: acp.qiv.com: jdn owned process doing -bs Date: Mon, 8 Dec 1997 21:02:08 -0600 (CST) From: Jay Nelson To: hoopty@ptialaska.net cc: questions@freebsd.org Subject: Re: gettytab dialups In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 8 Dec 1997 hoopty@ptialaska.net wrote: > > good grief! ;) > > i've been up for days trying to get a dialup to a Practical Pereipheral > 28.8 V.FC going. i have no problems with Null Modems, and other > modems. are these PP modems know to have problems with FBSD? > they seem to work just fine with DOS stuff. > > i've tried every baud rate from > > std.9600:np:sp#9600:ic="" blah blah blah:ac=RING\r ATA\r Hmm... I didn't know the standard getty supported the "ic" capability yet. But even if it did --- you _really_ don't want to do it that way. If ic works (anyone?) then it is best used to send an "AT" to lock the modem's port speed. (IMHO) > > to 115200. [snip] > anyone used these modems before? Yes, I have used them. They're not much different than any other "Hayes compatible." > is the gettytab/chat stuff slightly broken? I set up my modems this way: Turn off echoing and error reporting. (E0Q1) Set hardware flow control. (&K3) Set the modem for _reset_ on carrier drop. (&D3 [check this]) Set DCD to follow carrier. (&C1) Set DSR active after answer & inactive on carrier drop. (&S1) And, of course S0=1, if you want dial-in. Store all of this in profile 0. The theory is this. "getty" gets confused when 'chatter' comes back from the modem. (You are looking at hardware lines, after all, if you want to go beyond 9600 baud.) So what you want to do is shut up the modem and let the hardware lines do their job. Turning of echoing and reporting keeps the modem from chattering with getty. The rest means that when you have a live connection, carrier detect goes high (or low -- I can't remember) getty knows someone is knocking at the door and spawns a login prompt. When the user hangs up, carrier drops and getty know they are gone and respawns. The _modem_ knows the carrier droped, hangs up and resets, loading profile 0 which makes it ready for the next connection. If you want to use something like UUCP or pppd, make the first command sent "ATE1Q0 OK" which will turn on the echoing you need for the chat. When carrier drops, you reload profile 0 (which is quite) and getty is happy as a pig in a mud hole. The drawback to this approach is: if you want echoing (for whatever reason) you have to turn it on yourself. However -- I've used this approach for years on a number of different Unices, and it works fine _all_ the time for shared use (dial-in and dial-out on the same port.) Even though some would disagree, and uugetty or mgetty let you do it the echo way, I like this the best. Try it. > > thanks. > > any advice on further debugging would be appreciated. > > -- Jay