> Thanks for your answer. According to your reply, it seems to be a pppd
> bug (pppd logs "rcvd [LCP ConfNak id=0x9 <auth chap MS>]")...
> This posting provides 3 example logs of the previously described
> problem:
> 1. A FAILED chap MS connection (with all protocols enabled in
> /etc/ppp/options)
> 2. A successful chap MS connection (with all protocols enabled in
> /etc/ppp/options)
> 3. A successful chap MS-v2 connection (with "require-mschap" set in
> /etc/ppp/options)
> --------------------------------------
> 1. A FAILED chap MS connection (with all protocols enabled in
> /etc/ppp/options)
> --------------------------------------
...
Quote:> Dec 18 09:40:37 curhsi02 pppd[2342]: Using interface ppp0
> Dec 18 09:40:37 curhsi02 pppd[2342]: Connect: ppp0 <--> /dev/pts/3
> Dec 18 09:40:38 curhsi02 pppd[2342]: sent [LCP ConfReq id=0x1
> <asyncmap 0x0> <auth eap> <magic 0x4585b54f> <pcomp> <accomp>]
The "eap" is a new one on me. It's in this log and the last log but
not in the second log, curious.
Quote:> Dec 18 09:40:41 curhsi02 pppd[2342]: rcvd [LCP ConfNak id=0x1 <auth
> chap MS>]
> Dec 18 09:40:41 curhsi02 pppd[2342]: sent [LCP ConfReq id=0x2
> <asyncmap 0x0> <auth chap MS-v2> <magic 0x4585b54f>
> <pcomp> <accomp>]
> Dec 18 09:40:41 curhsi02 pppd[2342]: rcvd [LCP ConfNak id=0x2 <auth
> chap MS>]
This is repeated many times and then pppd terminates the negotiations.
The peer is configured to request only MSCHAP-v1 and pppd either has
a bug, or the pppd MSCHAP-v1 implementation is incomplete and pppd
currently simply refuses to use it.
Quote:> --------------------------------------
> 2. A successful chap MS connection (with all protocols enabled in
> /etc/ppp/options)
> --------------------------------------
...
Quote:> Dec 18 09:55:50 curhsi02 pppd[2407]: Connect: ppp0 <--> /dev/pts/3
> Dec 18 09:55:50 curhsi02 pppd[2407]: sent [LCP ConfReq id=0x1
> <asyncmap 0x0> <auth chap MS> <magic 0x9ef6cc4> <pcomp> <ac> comp>]
No "eap" but instead the initial pppd request is for MSCHAP. If the
configuration is the same ("all protocols enabled") for pppd here
as in the first instance then why is this happening? The initial
authentication option, which is the very first LCP message by either
side, requested by pppd should not have changed.
Quote:> Dec 18 09:55:53 curhsi02 pptpd[2406]: CTRL: Ignored a SET LINK INFO
> packet with real ACCMs!
> Dec 18 09:55:53 curhsi02 pppd[2407]: rcvd [LCP ConfAck id=0x1
> <asyncmap 0x0> <auth chap MS> <magic 0x9ef6cc4> <pcomp> <ac
> comp>]
The peer is now configured to accept MSCHAP-v1, pppd ACKs the request,
and the PPP link is then successful - so this pppd *is* capable of
using MSCHAP-v1. This could be connected with the absence of "eap"
in this instance. Something *had* to change in the pppd configuration
to make "eap" go away. It's too much to believe that pppd randomly
changes the initial authentication option in the LCP negotiations.
...
Quote:> --------------------------------------
> 3. A successful chap MS-v2 connection (with "require-mschap" set in
> /etc/ppp/options)
> --------------------------------------
...
Quote:> Dec 18 09:40:10 curhsi02 pppd[2337]: Connect: ppp0 <--> /dev/pts/3
> Dec 18 09:40:10 curhsi02 pppd[2337]: sent [LCP ConfReq id=0x1
> <asyncmap 0x0> <auth eap> <magic 0xeccb49ea> <pcomp
>> <accomp>]
Here "eap" is back as the initial authentication option pppd requests. :/
...
Quote:> Dec 18 09:40:13 curhsi02 pppd[2337]: rcvd [LCP ConfNak id=0x1 <auth
> chap MS-v2>]
> Dec 18 09:40:13 curhsi02 pppd[2337]: sent [LCP ConfReq id=0x2
> <asyncmap 0x0> <auth chap MS-v2> <magic 0xeccb49ea>
> <pcomp> <accomp>]
No mystery here, this version of pppd can do MSCHAP-v2 and that's what
the peer requested.
Something's not in Kansas anymore and I'm not entirely sure that
it's pppd. :)
PPP-Q&A links, downloads: http://users3.ev1.net/~ckite/public_html/
by