Date: Mon, 8 Dec 1997 21:02:08 -0600 (CST) From: Jay Nelson <jdn@qiv.com> To: hoopty@ptialaska.net Cc: questions@freebsd.org Subject: Re: gettytab dialups Message-ID: <Pine.BSF.3.96.971208202455.501A-100000@acp.qiv.com> In-Reply-To: <Pine.BSF.3.95q.971208101706.593A-100000@hoopty.ptinet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971208202455.501A-100000>