final repost - MPPE incorrect REJECT/NAK behaviour (was Re: Windows

final repost - MPPE incorrect REJECT/NAK behaviour (was Re: Windows

[Phil Mayers]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

Phil Mayers wrote:
>>
>> I've discovered that the problem is the WM2005 PPTP client PPP layer
>> sets none of the 40, 56 or 128 bit MPPE flags, and pppd instantly
>> terminates the connection when this happens. A win2k VPN server NAKs
>> with the preferred keysize.
>>
>> sent [CHAP Challenge id=0x3e <CHAL>, name = "pptpd"]
>> rcvd [CHAP Response id=0x3e <RESP>, name = "user"]
>> sent [CHAP Success id=0x3e "S=BYTES"]
>> sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]
>> rcvd [CCP ConfReq id=0x0 <mppe -H -M -S -L -D +C>]
>> sent [LCP TermReq id=0x2 "MPPE required but peer negotiation failed"]
>> sent [CCP ConfRej id=0x0 <mppe -H -M -S -L -D +C>]
> 
> I have also seen this yesterday with a windows ME client. In this 
> instance the patch fixed the connection completely, so I'm inclined to 
> think it's correct.
> 
> Does anyone have any comments on the pppd patch?
> 

I am assuming no-one has an opinion on this? If not I'll bung it into 
our local SVN vendor repo and leave it at that, though obviously I'd far 
rather not maintain it locally.

To summarise - some PPP clients (windows mobile 2005, windows ME) send 
the 40, 56 and 128 bits as zero. Win2k servers NAK with the preferred 
bit set, linux pppd REJECTS with "MPPE required".

This message and the reply refer to the problem some time ago:

http://marc.theaimsgroup.com/?l=linux-ppp&m=107533972806878&w=2
http://marc.theaimsgroup.com/?l=linux-ppp&m=107534084207793&w=2

...and the OP indicates the "forked" ppp 2.4.1 did the right thing. 
Attached is a patch to fix the behaviour, which I have confirmed as 
working here.

Cheers,
Phil

[-- Attachment #2: mppe_nak_fix.patch --]
[-- Type: text/x-patch, Size: 562 bytes --]

--- ppp-2.4.3/pppd/ccp.c	2006-02-08 14:28:03.000000000 +0000
+++ ppp-2.4.3/pppd/ccp.c	2006-02-08 14:30:45.000000000 +0000
@@ -1157,9 +1157,16 @@
 			break;
 		    }
 		} else {
-		    /* Neither are set. */
-		    newret = CONFREJ;
-		    break;
+		    /* Neither are set. NAK with the best we support */
+		    if (ao->mppe & MPPE_OPT_128)
+		    	ho->mppe |= MPPE_OPT_128;
+		    else if (ao->mppe & MPPE_OPT_40)
+		    	ho->mppe |= MPPE_OPT_40;
+		    else {
+			newret = CONFREJ;
+			break;
+		    }
+		    newret = CONFNAK;
 		}
 
 		/* rebuild the opts */

Re: final repost - MPPE incorrect REJECT/NAK behaviour (was Re: Windows mobile 2005 clients)

[James Cameron]

Looked fine to me, and so I began to test it, but it would not apply to
PPP CVS, which appears to contain code that does something similar.

Is it already fixed in CVS?  Could you try CVS?  Or adapt your change to
what is already there?

ccp.c 1.50

		} else {
		    /* Neither are set. */
		    /* We cannot accept this.  */
		    newret = CONFNAK;
		    /* Give the peer our idea of what can be used,
		       so it can choose and confirm */
		    ho->mppe = ao->mppe;
		}

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

Re: final repost - MPPE incorrect REJECT/NAK behaviour (was Re: Windows

[Phil Mayers]

James Cameron wrote:
> Looked fine to me, and so I began to test it, but it would not apply to
> PPP CVS, which appears to contain code that does something similar.
> 
> Is it already fixed in CVS?  Could you try CVS?  Or adapt your change to
> what is already there?

Oops. How embarrassing! Apologies for not checking CVS and for the noise.

I'll test it, but I guess that should resolve the issue - though the 
patch I wrote only NAKs with the preferred crypto bit which is what I 
observed win2k to do, and at a glance that code will NAK with all bits 
we support (i.e. 40 and 128 set, if you permit that)? For reference:

client sends:

Generic Routing Encapsulation (PPP)
  Protocol Type: PPP (0x880b)
Point-to-Point Protocol
  Protocol: Compression Control Protocol (0x80fd)
PPP Compression Control Protocol
  Code: Configuration Request (0x01)
  Identifier: 0x00
  Length: 10
  Options: (6 bytes)
   Microsoft PPC: Supported Bits: 0x00000001
    .... .... .... .... .... .... .... ...1 = Desire to negotiate MPPC
    .... .... .... .... .... .... ...0 .... = Obsolete
    .... .... .... .... .... .... ..0. .... = 40-bit encryption OFF
    .... .... .... .... .... .... .0.. .... = 128-bit encryption OFF
    .... .... .... .... .... .... 0... .... = 56-bit encryption OFF
    .... ...0 .... .... .... .... .... .... = Stateless mode OFF

server replies (server does permit 40 bit):

Generic Routing Encapsulation (PPP)
  Protocol Type: PPP (0x880b)
Point-to-Point Protocol
  Protocol: Compression Control Protocol (0x80fd)
PPP Compression Control Protocol
  Code: Configuration Nak (0x03)
  Identifier: 0x00
  Length: 10
  Options: (6 bytes)
   Microsoft PPC: Supported Bits: 0x00000041
    .... .... .... .... .... .... .... ...1 = Desire to negotiate MPPC
    .... .... .... .... .... .... ...0 .... = Obsolete
    .... .... .... .... .... .... ..0. .... = 40-bit encryption OFF
    .... .... .... .... .... .... .1.. .... = 128-bit encryption ON
    .... .... .... .... .... .... 0... .... = 56-bit encryption OFF
    .... ...0 .... .... .... .... .... .... = Stateless mode OFF


Having said that, I agree the version in CVS is "more correct", you 
should NAK with what you can permit.

Thanks again,
Phil