[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