Is it possible I have the same problem? I've just assumed that
the ISP was busy, or something?
Aug 7 05:13:19 localhost pppd[770]: pppd 2.3.7 started by rks, uid 500
Aug 7 05:13:20 localhost chat[772]: abort on (BUSY)
Aug 7 05:13:20 localhost chat[772]: send (ATZ^M)
Aug 7 05:13:20 localhost chat[772]: expect (OK)
Aug 7 05:13:20 localhost chat[772]: ^M
Aug 7 05:13:20 localhost chat[772]: NO CARRIER^M
Aug 7 05:13:20 localhost chat[772]: ATZ^M^M
Aug 7 05:13:20 localhost chat[772]: OK
Aug 7 05:13:20 localhost chat[772]: -- got it
Aug 7 05:13:20 localhost chat[772]: send (ATDT33552000^M)
Aug 7 05:13:20 localhost chat[772]: expect (CONNECT)
Aug 7 05:13:20 localhost chat[772]: ^M
Aug 7 05:13:41 localhost chat[772]: ATDT33552000^M^M
Aug 7 05:13:41 localhost chat[772]: CONNECT
Aug 7 05:13:41 localhost chat[772]: -- got it
Aug 7 05:13:41 localhost pppd[770]: Serial connection established.
Aug 7 05:13:41 localhost pppd[770]: Using interface ppp0
Aug 7 05:13:41 localhost pppd[770]: Connect: ppp0 <--> /dev/modem
Aug 7 05:13:42 localhost pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic
0x10c35812> <pcomp> <accomp>]
Aug 7 05:13:43 localhost pppd[770]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic
0xb9166414> <pcomp> <accomp> <auth pap>]
Aug 7 05:13:43 localhost pppd[770]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic
0xb9166414> <pcomp> <accomp> <auth pap>]
Aug 7 05:13:45 localhost pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic
0x10c35812> <pcomp> <accomp>]
Aug 7 05:13:45 localhost pppd[770]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic
0x10c35812> <pcomp> <accomp>]
Aug 7 05:13:45 localhost pppd[770]: sent [PAP AuthReq id=0x1 user="[EMAIL PROTECTED]"
password="secret"]
Aug 7 05:13:48 localhost pppd[770]: sent [PAP AuthReq id=0x2 user="[EMAIL PROTECTED]"
password="secret"]
Aug 7 05:13:51 localhost pppd[770]: sent [PAP AuthReq id=0x3 user="[EMAIL PROTECTED]"
password="secret"]
Aug 7 05:13:54 localhost pppd[770]: sent [PAP AuthReq id=0x4 user="[EMAIL PROTECTED]"
password="secret"]
Aug 7 05:13:57 localhost pppd[770]: sent [PAP AuthReq id=0x5 user="[EMAIL PROTECTED]"
password="secret"]
Aug 7 05:14:00 localhost pppd[770]: sent [PAP AuthReq id=0x6 user="[EMAIL PROTECTED]"
password="secret"]
Aug 7 05:14:03 localhost pppd[770]: sent [PAP AuthReq id=0x7 user="[EMAIL PROTECTED]"
password="secret"]
Aug 7 05:14:06 localhost pppd[770]: sent [PAP AuthReq id=0x8 user="[EMAIL PROTECTED]"
password="secret"]
Aug 7 05:14:09 localhost pppd[770]: sent [PAP AuthReq id=0x9 user="[EMAIL PROTECTED]"
password="secret"]
Aug 7 05:14:12 localhost pppd[770]: sent [PAP AuthReq id=0xa user="[EMAIL PROTECTED]"
password="secret"]
Aug 7 05:14:15 localhost pppd[770]: No response to PAP authenticate-requests
Aug 7 05:14:18 localhost pppd[770]: rcvd [PAP AuthNak id=0xa "Invalid Login"]
Aug 7 05:14:29 localhost pppd[770]: Terminating on signal 15.
Aug 7 05:14:29 localhost pppd[770]: sent [LCP TermReq id=0x2 "User request"]
Aug 7 05:14:30 localhost pppd[770]: Hangup (SIGHUP)
Aug 7 05:14:30 localhost pppd[770]: Modem hangup
Aug 7 05:14:30 localhost pppd[770]: Connection terminated.
Aug 7 05:14:30 localhost pppd[770]: Connect time 0.9 minutes.
Aug 7 05:14:31 localhost pppd[770]: Exit.
* Ray Olszewski <[EMAIL PROTECTED]> [000806 16:43]:
> At 01:25 PM 8/6/00 EDT, [EMAIL PROTECTED] wrote:
> ...
> >> Aug 6 11:25:29 debian pppd[274]: rcvd [LCP ConfRej id=0x1 <auth pap>]
> >
> >Looks like the remote pppd is satisfied with the shell login and doesn't
> >want to be bothered with PAP. Maybe you can try
> >
> >noauth
> >
> >in /etc/ppp/options.
>
> Good catch, Lawson. I'd missed that he had "auth" in that file AND didn't
> override it in the command-line options that invoke pppd (the usual
> workaround).
> But I wanted to follow up because the way you wrote your response, David
> (and others) might be misled about the meaning of "auth".
>
> >From the pppd man page:
>
> auth Require the peer to authenticate itself before
> allowing network packets to be sent or received.
> This option is the default if the system has a
> default route. If neither this option nor the
> noauth option is specified, pppd will only allow
> the peer to use IP addresses to which the system
> does not already have a route.
>
>
> In other (perhaps clearer?) words, the "auth" option requires the *other*
> end to authenticate itself to *you*. I've never found an ISP implementation
> of ppp that does this; it's normally used with the so-called "server" end of
> a ppp connection (the end that answers the phone), not the so-called
> "client" end (the end that makes the phone call).
>
> >From the frequency with which this comes up, I'd guess that "auth" is the
> most misunderstood option in pppd.
>
>
> --
> ------------------------------------"Never tell me the odds!"---
> Ray Olszewski -- Han Solo
> Palo Alto, CA [EMAIL PROTECTED]
> ----------------------------------------------------------------
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.linux-learn.org/faqs
---cut here---
--
Running Redhat 6.0 with some upgraded packages.
Richard Spencer "Why Not" is a slogan
Sao Paulo, Brazil for an interesting life.
[EMAIL PROTECTED] -- Mason Cooley
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.linux-learn.org/faqs
