> |Jan 18 01:10:22 madras pppd[25041]: rcvd [CCP ConfReq id=0x2 < 12 06 00 00
> |00 71>]
> |Jan 18 01:10:22 madras pppd[25041]: sent [CCP ConfRej id=0x2 < 12 06 00 00
> |00 71>]
>
> This is very likely the problem. It's yet another Microsoft-STAC hook,
> Microsoft Point-to-Point Compression (MPPC) CCP using Microsoft Point-to-
> Point Encryption (MPPE). Successful MPPC negotiation can be mandatory when
> when MPPE is requested. The draft says "should" but you can bet that
> becomes "must" in the eyes of the NT PPP implementator. :(
>
> Since MPPC must be licensed by STAC Electronics there is no code for it in
> pppd. AFAIK the only way it could be used in Linux is by a binary module
> that was generated under the STAC license.
thanks much for your response.
i poked around and discovered that there is an mppe/rc4 patch to pppd
(2.3.8 and 2.3.10) that reportedly was successful in negotiating with
microsoft pptp (and maybe even ppp) "servers". i downloaded it, patched my
pppd, and tried again. to no success. i dont have the logs handy to
include it here, but effectively : both my ISP and my pppd keep sending
CCP packages requesting mppe. only it looks like they're requesting
"different kinds of mppe" ? if that makes any sense? and when both peers
discover they're making no forward progress, CCP termreq gets sent from
the nt end, and my machine gives up.
is this because there really is no mppe support for pppd/linux and the one
i downloaded is not quite applicable (for some reason), or is it true that
i am quite close to the truth and a little more pushing will yield fruit?
if you'd like me to include the logs, i will do so later, when i get back
home...
thanks
shashi
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
