RES: [pptp-server] Is PoPToP dead?

[Frank Cusack]

On Mon, Mar 18, 2002 at 10:41:51PM -0500, Charlie Brady wrote:
> All you need kernel wise is an mppe module, and a ppp/ppp_generic module 
> which allows 64byte parameter blocks (which requires a recompile).

Even that's not needed; that's one of the ways the existing mppe mechanism
is broken.  (not broken as in nonfunctional, broken as in not "correct")

> You could remove the ppp/ppp_generic module from the mix if either the
> standard kernel allowed 64byte parameter blocks, or the mppe module
> interface passed a pointer to NT hash rather than the NT hash to the
> kernel. The module could then do a copy from user to kernel space to get
> hold of the hash, which is used as to initialise the encryption key. So 
> all you'd need is an mppe module.

userland does not pass the hash, it passes the keys.

I expect to make mppe support for 2.2 publically available in ~ 2 weeks
(it's mostly done, need to do integration and testing).  2.4 -- dunno, but
I expect 1-2 weeks after that.  That's based on whether the pppd guys
accept my mppe changes (I think they will -- the userland side has no
questionable bits).

BTW Charlie, hi. :-)  While doing some research on stateful mode I saw
your post about tolerating out of order packets (from nearly a year ago).
It's a good idea, except that RFC 1661 sec. 1, RFC 3078 sec. 3, and
RFC 2637 sec. 4.3 all agree that PPP MUST receive packets in order.  Any
patch to tolerate out-of-order packets MUST go into pptpd (either queue
or drop).  I understand that pptpd 1.1.2 (?) does queue them.  If 1.0.x
sends them to PPP, it's broken.

/fc