Date: Thu, 31 Jul 1997 17:46:07 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: gabor@acm.org (Gabor Kincses) Cc: grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: PPP chap problem Message-ID: <199708010046.RAA00665@bubba.whistle.com> In-Reply-To: <33E121A1.7432@acm.org> from Gabor Kincses at "Jul 31, 97 06:37:05 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > >>> I have tried to make chap work, but no go. I have used pap and no > > >>> authentication for over 6 months now, but chap doesn't seem to work. > > >>> > > >>> I always get > > >>> LCP: SendConfigRej(Req-Sent) > > >>> AUTHPROTO proto = c223 > > >>> > > >>> which means that my side rejects chap authentication. > > >>> Even though I added enable chap, accept chap. > > >> > > >> Enable chap means "i want the peer to authenticate to me using chap", > > >> so you don't want to do that. > > >> > > >>> I also tried to disable chap and only accept chap, but that didn't work > > >> > > >> Hmm, should have. > > > > > > I understood what enable chap meant after reading someone's post on the > > > newgroup and tried out disable chap and accept chap, which didn't work > > > either. The really interesting part is that if I say accept pap, then > > > the SendConfigRej becomes SendConfigNak AUTHPROTO proto = c023, so it > > > seems there might be something wrong with the chap state in the > > > code. > > > > No. PAP is 0xc023, CHAP is 0xc223 (see net/ppp_defs.h). > > I know. I looked (actually also defined in /usr/src/usr.sbin/ppp). > What I meant here is that with accept or deny pap, my side refuses to > accept chap. When pap is allowed (accept pap) my side suggests the use > of pap instead of chap (since maybe it thinks chap is not allowed, which > would be the hypothesized bug, since I DID accept chap), hence the > SendConfigNak AUTHPROTO proto = c023 message. When pap is not allowed > (deny pap) it sends a SendConfigRej AUTHPROTO proto = c223, attesting > that it (ppp) thinks that chap is in fact disallowed. Whether pap is > denied or accepted should really be irrelevant to the chap discussion, > except in both cases I see indication that ppp thinks chap is not > allowed on my side, in spite of the explicit 'accept chap'. > > I haven't read the RFC, but it seems logical that it would try to use > pap as a fallback, if chap is denied. Yes, the logic should be "prefer CHAP" but accept anything that's marked "accept". > > > Again I'm getting this after I escape out of term into packet mode. Is > > > there anything different here from executing a script? > > > > Well, yes. I don't understand the question. > > I meant that people have gotten chap working a zillion times fine. The > only thing that seems non-standard in my case is that I need to enter > term to answer the SNK challenge number and then enter packet mode from > there. I felt that most people use the scripting method to dial up > their providers. Yep... > > > I only have the 2.1.5 source code, but haven't been able to dig through > > > the relevant portions. All I can tell that the code never really gets > > > into the chap.c stuff... > > > > That seems unlikely. Have you done a complete trace? There's nothing > > you've shown here which disproves Archie's suggestion, which I think > > is correct. > > > > Greg > > I looked at the code where the log messages are written to the log file > (based on what I have found in the log file itself) and concluded that > ppp thinks that chap is not allowed, so it never goes into trying to > perform chap. Ie. when a SendConfigRej AUTHPROTO = c223 message is > written to the log file, you have not yet done chap and you never will. > Is this last assumption wrong? No, that sounds right. Guess there's just a gremlin in there somewhere. I'm not familiar enough with that code to speculate with any more detail :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708010046.RAA00665>