Subject: Re:Debugging my modem (was Ameritrade v NetBSD1.6.0)
To: Todd Gruhn <tgruhn2@mail.com>
From: Frederick Bruckman <fredb@immanent.net>
List: netbsd-users
Date: 02/09/2003 11:04:02
On Sun, 9 Feb 2003, Todd Gruhn wrote:

> Here is the entire script -- I dont wish to keep sending it, because
> it contains an account and password, and I will eventually forget
> to edit them out GRRR! <<-() The output from syslogd is below that.

That might be your whole problem. Many of the big network services
(with which the ISP's contract with to provide dial-ups) require you
to use PAP or CHAP. All you need to do, is to create an
"/etc/ppp/pap-secrets" file which contains one line:

<ISP username> * <ISP password> *

substituting <ISP username> an <ISP password> for you ISP username and
password, of course. As long as that file exists, "pppd" uses PAP by
default. If the ISP username is not your machine name (like it ever
would be), add a "user <ISP username>" option, and also a "noauth"
option (so the remote end is allowed to not supply credentials, since
it won't).

> # I put most of the common options on this command. Please, don't
> # forget the 'lock' option or some programs such as mgetty will not
> # work. The asyncmap and escape will permit the PPP link to work with
> # a telnet or rlogin connection. You are welcome to make any changes
> # as desired. Don't use the 'defaultroute' option if you currently
> # have a default route to an ethernet gateway.
> #
> exec /usr/sbin/pppd debug lock modem crtscts /dev/tty00 57600 \
>         asyncmap 0xa0000 noccp nomagic kdebug 0 $LOCAL_IP:$REMOTE_IP \
>         noipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT
> # asyncmap 20A0000; delete 'escape FF'

Maybe you need "asyncmap 0xa0000" if you ppp *over* telnet or rlogin,
but for a direct connection to a modem, "asyncmap 0" is fine, really.

> Feb  9 10:31:01 gandalf pppd[2231]: sent [IPCP ConfReq id=0x2 <addr 208.244.242.247> <compress VJ 0f 01>]
> Feb  9 10:31:01 gandalf pppd[2231]: rcvd [IPCP ConfAck id=0x2 <addr 208.244.242.247> <compress VJ 0f 01>]
> Feb  9 10:31:01 gandalf gated[175]: EVENT Add ppp0 208.244.242.247 -> 208.244.242.5 <PointToPoint Multicast>
> Feb  9 10:31:01 gandalf pppd[2231]: local  IP address 208.244.242.247
> Feb  9 10:31:01 gandalf gated[175]: EVENT <UpDown> ppp0 index 3 <Up PointToPoint Multicast>
> Feb  9 10:31:01 gandalf pppd[2231]: remote IP address 208.244.242.5
> Feb  9 10:31:01 gandalf gated[175]: EVENT UpDown MTU ppp0 208.244.242.247 -> 208.244.242.5 <Up PointToPoint Multicast>

By the way... I hate to ask, but why are you running "gated", when the
dial-up service has the default route?

> Feb  9 10:31:01 gandalf pppd[2231]: rcvd [CCP ConfReq id=0x1 < 11 05 00 01 04>]
> Feb  9 10:31:01 gandalf pppd[2231]: Unsupported protocol 'Compression Control Protocol' (0x80fd) received
> Feb  9 10:31:01 gandalf pppd[2231]: sent [LCP ProtRej id=0x2 80 fd 01 01 00 09 11 05 00 01 04]

?? ...and then what?

I just remembered something... If the other side is doing the
disconnecting (after negotiating an IP and everything), the messages
just before the disconnect don't necessarily have anything to do with
the "why". One of my favorite ISP's contractor's server, which
coincidently chokes on "ccp" the same way as yours, dumps you
unceremoniously if you fail to configure PAP or CHAP, even after
you've supplied a login and password the "old-fashioned" way.

By the way, these days, many quality ISP's have a Linux/Unix support
person. That's how they compete with the well-known national services,
which seem to have the clueless newbie/Windows market locked up.
Someone on the ISP end would at least be able to tell you why you were
disconnected.

Frederick