On Sat, 24 Jul 1999, MAURICIO RODRIGUEZ wrote:
|file chap secrets was okay. I was just trying to avoid posting my login and
|password on the internet. This one is the file:
|
|/etc/ppp/chap-secrets
|
|login * "password" *
|
|where login: my name
|and password is my password
|
|As you suggested I also removed the kdebug25 from one of the scripts and put
|debug instead. I am also posting the messages written to ppp-log. This file,
|as you could see, has plenty of LCP's
|
|Note: I intentionally changed my password in the file chap-secrets and
|connection dropped inmediately (0.2 minutes later. I then checked the
|ppp-log file and there was a message saying that authentication had failed,
|so I "guess" this is not an authentication problem???? what do you think??)
It's an authentication problem but a strange one, one for which I don't
have any answer given that there was an authentication failure message when
the password was changed. The reasons I say this are made clear below.
| /usr/var/ppp-log
|
|Jul 24 01:06:10 localhost pppd[997]: pppd 2.3.7 started by root, uid 0
|Jul 24 01:06:26 localhost pppd[997]: Serial connection established.
|Jul 24 01:06:26 localhost pppd[997]: Using interface ppp0
|Jul 24 01:06:26 localhost pppd[997]: Connect: ppp0 <--> /dev/modem
|Jul 24 01:06:27 localhost pppd[997]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
|<magic 0xdb7b1f21> <pcomp> <accomp>]
|Jul 24 01:06:28 localhost pppd[997]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0>
|<magic 0xdb7b1f21> <pcomp> <accomp>]
|Jul 24 01:06:28 localhost pppd[997]: sent [LCP ConfNak id=0x1 <magic
|0x86411338>]
The first message is reflected and comes back to pppd as the second (rcvd)
message - notice that the messages are identical (except for sent and rcvd)
down to the magic number. The peer probably just wasn't ready.
The third message is pppd asking for a repeat with a new magic number, the
one you see in the ConfNak message above. This check to detect loopback is
what magic numbers are for.
|Jul 24 01:06:29 localhost pppd[997]: rcvd [LCP ConfReq id=0x1 <mru 1514>
|<asyncmap 0x0> <auth chap MD5> <magic 0x812822ff> <pcomp> <accomp> < 11 04
|05 ea> < 13 03 00>]
|Jul 24 01:06:29 localhost pppd[997]: sent [LCP ConfRej id=0x1 <auth chap
|MD5> < 11 04 05 ea> < 13 03 00>]
The peer wants to use CHAP and some other things pppd doesn't know about
and won't ever know about since they are proprietary.
Pppd rejects CHAP and the things it doesn't recognize. The only reasons I
know for pppd to reject a request for CHAP authentication are that the
chap-secrets file doesn't exist, the name option is omitted, the string
given to the pppd name option is not the same as the string in the first
field of the secrets file, or that the pppd option refuse-chap is being
used. Otherwise I would expect CHAP to be accepted and proceed to the
acutal authentication - as apparently happened when the password was
changed.
There are some more comments below but they are irrelevant to the problem.
I'm baffled by this one and hope to see it resolved on the list.
|Jul 24 01:06:29 localhost pppd[997]: rcvd [LCP ConfReq id=0x2 <mru 1514>
|<asyncmap 0x0> <auth 0xc227> <magic 0x86411338> <pcomp> <accomp>]
|Jul 24 01:06:29 localhost pppd[997]: sent [LCP ConfRej id=0x2 <auth 0xc227>]
Peer tries for SPAP authentication and pppd reject it. SPAP is not only
proprietary it's a close held secret. The magic number is now the one in
the previous ConfNak that pppd sent.
|Jul 24 01:06:29 localhost pppd[997]: rcvd [LCP ConfReq id=0x3 <mru 1514>
|<asyncmap 0x0> <auth chap m$oft> <magic 0x86411338> <pcomp> <accomp>]
|Jul 24 01:06:29 localhost pppd[997]: sent [LCP ConfRej id=0x3 <auth chap
|m$oft>]
Now the peer tries for MSCHAP v1 and again pppd rejects it although MSCHAP
can be compiled into pppd. This time the rejection is because pppd is not
configured to accept any version of CHAP.
|Jul 24 01:06:29 localhost pppd[997]: rcvd [LCP ConfReq id=0x4 <mru 1514>
|<asyncmap 0x0> <auth pap> <magic 0x86411338> <pcomp> <accomp>]
|Jul 24 01:06:29 localhost pppd[997]: sent [LCP ConfRej id=0x4 <auth pap>]
The peer tries PAP and pppd isn't configured for it either. Since this is
the lowest form of a PPP authentication protocol the connection is doomed.
The rest of the messages consist of restarts from the beginning of the LCP
negotiation with the same result. The peer finally (rudely) hangs up.
---
Clifford Kite Not a guru. (tm)
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
