On Sat, 16 Mar 2002, Ian P. Thomas wrote:

> # Require the peer to authenticate before allowing packets to be sent or
> received.
> auth

That's wrong, as it's unlikely that the isp's off-the-shelf terminal
server will be configured to supply a password to your system, and even
less likely that it would know what that password should be! "auth" is
the default, anyway. Use "noauth", instead.

> Mar 15 21:21:56 solo chat[5510]: ATDT*70,,5155603^M^M
> Mar 15 21:21:56 solo chat[5510]: CONNECT
> Mar 15 21:21:56 solo chat[5510]:  -- got it
> Mar 15 21:21:56 solo pppd[5501]: Serial connection established.
> Mar 15 21:21:56 solo pppd[5501]: Connect: ppp0 <--> /dev/tty00
> Mar 15 21:21:56 solo pppd[5501]: Modem hangup
> Mar 15 21:21:56 solo pppd[5501]: Connection terminated.

It doesn't seem like there's enough time for the auth option (or any
options) to "pppd" to come into play, but it might still make sense to
start pppd with "debug", just to see what's what. You might need to add
"daemon.debug\t/var/log/messages" to "/etc/syslog.conf", and send a
SIGHUP to syslogd, to see the messages.

> 	I have ipfilter and ipnat working flawlessly as far as I can tell.

That can't make any difference.

> I'm not sure what is making the modem hang up immediately after
> connecting.  I can bring up a link manually without any problems.  Any
> suggestions would be welcomed.

My guess -- it's hanging up on "auth". If so, it'll be (sort of) obvious
from the debug log: your machine will send a request for authorization,
then the remote will hang up, just like that, every time.

If it gets a little farther, but not in the same place every time, that
would likely be because either the local or the remote is retraining
almost immediately after connecting. The solution for that is to try
ratcheting down the maximum connection speed in your modem setup string.

Frederick