[pptp-server] Encryption is getting NAKed by e-smith ppp-2.4. 0-15

[Frank Cusack]

On Thu, Mar 21, 2002 at 03:14:16PM -0500, Charlie Brady wrote:
> 
> On Wed, 20 Mar 2002, Frank Cusack wrote:
> 
> > On Wed, Mar 20, 2002 at 03:51:37PM -0800, Michael St. Laurent wrote:
> > > sentinel pppd[20521]: sent [CCP ConfReq id=0x1 <mppe 1 0 0 60>]
> > > sentinel pppd[20521]: rcvd [CCP ConfReq id=0x4 <mppe 1 0 0 e1>]
> > > sentinel pppd[20521]: sent [CCP ConfNak id=0x4 <mppe 1 0 0 60>] << (1)
> > > sentinel pppd[20521]: rcvd [CCP ConfNak id=0x1 <mppe 1 0 0 40>]
> > > sentinel pppd[20521]: rcvd [CCP ConfReq id=0x6 <mppe 1 0 0 40>] << (2)
> > > sentinel pppd[20521]: sent [CCP ConfRej id=0x6 <mppe 1 0 0 40>]
> > > sentinel pppd[20521]: LCP terminated by peer (El^G3^@<M-Mt^@^@^BM-f)
> > 
> > Looks like a bug in ppp_mppe.
> 
> The CCP negotiation is done by pppd, not the ppp_mpppe module.

Yup, that's what I meant. :-)  Thanks for the clarification.

> > In line (1), ppp_mppe is Nak'ing with
> > multiple enc options (40+128), it's supposed to Nak with one choice.
> 
> Are you sure? Should it not Nak with anything that it can do which the 
> peer has requested.

No, the standard PPP ack/nak sequence is to Nak with only *one* option,
the one you will do based on what the peer suggests.  Although I really
hate to quote such a poor document as RFC 3078, in sec 2.1 it says
"the responder SHOULD NAK with a single encryption option".

> > Also, it's Nak includes an option not in the original ConfReq.
> 
> Which one?

Damn, sorry I misread that one.  (I thought e1 wasn't including 40 bit.)

It's puzzling why pppd would fail here.

/fc