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

[Frank Cusack]

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.  In line (1), ppp_mppe is Nak'ing with
multiple enc options (40+128), it's supposed to Nak with one choice.
Also, it's Nak includes an option not in the original ConfReq.
The client seems to handle this fine, but then ppp_mppe decides for
some reason it doesn't like the clients new ConfReq (line (2), where
the client requests a subset of what the server said it would support).

Maybe since the Nak went out bad, the server wants the next request to
be the same as it's Nak.

The client disconnects after ppp_mppe rejects MPPE.

Since the client support 128, you can probably workaround this by disabling
40-bit support in ppp_mppe.

/fc