[pptp-server] FIXED one-way encryption
Tim Wilson
timwilson at mediaone.net
Fri Apr 20 12:47:13 CDT 2001
I FIXED IT!! via many printks. See if you agree:
There's a logic bug in ppp_generic.c. Right around line 1985, it reads:
case CCP_CONFREQ:
case CCP_TERMREQ:
case CCP_TERMACK:
/*
* CCP is going down - disable compression
*/
if (inbound)
ppp->rstate &= ~SC_DECOMP_RUN;
else
ppp->xstate &= ~SC_COMP_RUN;
break;
This is wrong. If I *receive* a confreq then that means the other end wants
me to send a confack stating what compression I am willing to send. In other
words, a received confreq proposes contains proposals on what the peer
willing to receive, and therefore what I compressions I can use on transmit.
Therefore, an inbound confreq should kill off my transmit compressor, not my
receive compressor. And the converse is true.
I changed the if() as follows
if (!inbound)
ppp->rstate &= ~SC_DECOMP_RUN;
else
ppp->xstate &= ~SC_COMP_RUN;
break;
And it works.
But upon thinking about it, I'm not sure that's right...does it handle the
Term-req and Term-ack correctly? Maybe it should really be:
case CCP_TERMACK:
/* Sending or receive term-ack kills CCP both ways */
ppp->rstate &= ~SC_DECOMP_RUN;
ppp->xstate &= ~SC_COMP_RUN;
break;
case CCP_CONFREQ:
if (!inbound)
ppp->rstate &= ~SC_DECOMP_RUN;
else
ppp->xstate &= ~SC_COMP_RUN;
break;
Comments anybody??
-----------------------------------------------------------
Tim Wilson * Systems Engineer
Cambia Networks * 5600 N. River Road, Rosemont IL 60018
Phone 847.885.3090 * Fax 847.993.3097 * Mobile 847.207.4177
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Tim Wilson.vcf
Type: text/x-vcard
Size: 420 bytes
Desc: not available
URL: <http://lists.schulte.org/mailman/private/pptp-server/attachments/20010420/3e6eda6f/attachment.vcf>
More information about the pptp-server
mailing list