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