[pptp-server] Req. help w/ MPPE support (against Win2K)

[Eric H]

I haven't played around with Win2k yet, but from what I understand, you
must manually enable the older encryption methods and LanMan Hashes
and so forth. I believe it's a registry key that needs to be changed.

If you're expieriencing lost/dropped packets, then there's another
issue... The easiest fix is to use stateless encryption and in ppp_mppe.c
(under your usr/src/linux dir) in the decrypt/decompress function make it
loop through the update_count method until the count matches and NOT
return an error (just continue).


On Tue, 13 Jun 2000, Charles Duffy wrote:

#=- Would someone with MPPE working with Windows 2000 clients be so kind
#=- as to give me some debugging info?
#=-
#=- My symptoms: When I attempt to send info through the PPP tunnel, it
#=- decrypts improperly, resulting in garbage (and "unsupported protocol"
#=- errors from pppd). This appears to be happening in both directions, as
#=- I receive LCP ProtRej errors from random protocols from the NT box as
#=- well.
#=-
#=-
#=- First off, the Win2K boxen I've been testing with (both directly off
#=- the CD and after downloading the crypto update) refuse to use
#=- stateless mode; it's not even in the bitmask with which they
#=- negotiate. As I would expect it to be enabled, I'm somewhat surprised.
#=- This is true both before and after applying MS's 128-bit crypto patch.
#=-
#=- Incidentally, the problem (which has been occuring with the stock RPMs
#=- of the PPP daemon, PoPToP and the standard RH62 kernel as well as with
#=- my hand-patched kernel and pppd and the current CVS implementation of
#=- PoPToP)
#=-
#=- Second, as I read the MPPE docs, the beginning of the buffer being
#=- passed to the crypto routines is offset by a few bytes from what it
#=- should be. I've put some debugging instrumentation into my kernel;
#=- what follows is a dump and my interpretation thereof. (Btw, anyone
#=- care to explain what the trailing 5As are?)
#=-
#=- kernel: ppp: mppe_decrypt, count = 68
#=- kernel: 00 FD 90 02 B0 36 B3 3E .....6.>
#=- kernel: 2C B0 77 AD A4 AA 14 0D ,.w.....
#=- kernel: 5E C6 C9 89 DD 2A 1D D6 ^....*..
#=- kernel: A4 D6 34 F8 AA AD F5 52 ..4....R
#=- kernel: F9 C3 9A CE 76 4A EA D8 ....vJ..
#=- kernel: 91 0F E5 94 53 07 5E 48 ....S.^H
#=- kernel: 96 ED E5 10 B7 04 0D F1 ........
#=- kernel: 4C CC 16 88 6F 58 52 4D L...oXRM
#=- kernel: 71 FC 3B 20 q.;
#=- kernel: Decryption beginning with character 0x2c.
#=- kernel: Decryption ending at position 68 with character 0x5a.
#=- kernel: ppp: mppe_decrypt, count = 68
#=- kernel: 00 FD B2 A7 5D A9 78 CD ....].x.
#=- kernel: 18 F4 B8 80 21 EB 65 81 ....!.e.
#=- kernel: 55 E8 D4 E1 4A 14 B5 06 U...J...
#=- kernel: 99 C8 69 EE AE 6D B2 CD ..i..m..
#=- kernel: 66 FD CD 0B 66 AE 1A 79 f...f..y
#=- kernel: 9C EC A4 6D C4 FE FA 6B ...m...k
#=- kernel: 9C 76 9F AC 0E F6 C1 65 .v.....e
#=- kernel: 45 42 CD A1 46 68 5A 5A EB..FhZZ
#=- kernel: 5A 5A 5A 5A ZZZZ
#=- kernel: Unhandled proto 0xb2a7 in ppp_receive_nonmp_frame.
#=-
#=- To quote from the MPPE draft, 4th revision:
#=-
#=- --- BEGIN QUOTE
#=- 3.1. Packet Format
#=-
#=- A summary of the MPPE packet format is shown below. The fields are
#=- transmitted from left to right.
#=-
#=- 0 1 2 3
#=- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
#=- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#=- | PPP Protocol |A|B|C|D| Coherency Count |
#=- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#=- | Encrypted Data...
#=- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#=-
#=- ..<snip>...
#=-
#=- When MPPE is successfully negotiated by the PPP Compression Control
#=- Protocol, the value of this field is 0x00FD. This value MAY be
#=- compressed when Protocol-Field-Compression is negotiated.
#=- --- END QUOTE
#=-
#=- So we have the two PPP protocol bytes, as we should, then followed by
#=- the coherency count bytes... which means we should be starting the
#=- decryption at the byte 0xB0 rather than 0x2C -- which is to say, at an
#=- offset of 4 rather than 8. (Rather oddly, the hardcoded offset appears
#=- to be 6 -- apparently, some shifting is happening elsewhere that I've
#=- failed to follow). This 6, I'm guessing, is calculated as follows:
#=- PPP_HDRLN + MPPE_OVHD - 2, where PPP_HDRLEN and MPPE_OVHD are both 4.
#=- The 2, I presume, is to make up for the section of the PPP header
#=- which is included in the encrypted data -- it's these two bytes which
#=- are causing the unsupported protocol errors. However, since only 2
#=- bytes of the PPP protocol are being included unencrypted, followed by
#=- only 2 bytes of MPPE (according to the draft spec), it should be only
#=- MPPE_OVHD (without PPP_HDRLN) included, or MPPE_OVHD should be reduced
#=- (though I haven't looked into where else in the code it's referenced).
#=-
#=- Okay, that's how it looks to me.
#=-
#=- The funny part, though, is that it apparently actually works for the
#=- rest of 'yall the way it is. If someone familiar with the code would
#=- be so kind as comment, I'd be very appreciative. (I'd do more
#=- trial-and-error, but my access to Windows here is limited to
#=- after-hours when I can dual-boot my cubemate's machine). If someone
#=- with a working MPPE setup would be so kind as to insert debug
#=- instrumentation similar to my own, I'd be greatly appreciative (if
#=- you're willing, ask and I'll send a patch).
#=-
#=- For completeness, a dump from the encryption routines (though I doubt
#=- much can be gained from them without also dumping the keys, which I
#=- haven't done). The following dump is a ping packet, both before and
#=- after encryption.
#=-
#=- kernel: ppp: mppe_encrypt, count = 88
#=- kernel: 5A 5A 00 21 45 00 00 54 ZZ.!E..T
#=- kernel: 00 00 40 00 40 01 B8 54 .. at .@..T
#=- kernel: C0 A8 00 02 C0 A8 01 02 ........
#=- kernel: 08 00 BA 46 68 04 00 00 ...Fh...
#=- kernel: 3E B5 3A 39 65 C3 0C 00 >.:9e...
#=- kernel: 08 09 0A 0B 0C 0D 0E 0F ........
#=- kernel: 10 11 12 13 14 15 16 17 ........
#=- kernel: 18 19 1A 1B 1C 1D 1E 1F ........
#=- kernel: 20 21 22 23 24 25 26 27 !"#$%&'
#=- kernel: 28 29 2A 2B 2C 2D 2E 2F ()*+,-./
#=- kernel: 30 31 32 33 34 35 36 37 01234567
#=- kernel: ppp: mppe_encrypt out, count = 92
#=- kernel: 5A 5A 00 FD 90 00 9B 42 ZZ.....B
#=- kernel: 81 97 5E 82 36 3E C6 9E ..^.6>..
#=- kernel: 85 2A BF 7C 51 6E F1 02 .*.|Qn..
#=- kernel: 01 6C 7F 39 0E 17 98 95 .l.9....
#=- kernel: AD 55 31 8B 3B F0 E3 D6 .U1.;...
#=- kernel: E9 F7 44 90 50 44 8F 22 ..D.PD."
#=- kernel: 9A DF 39 8D 6C AE E6 38 ..9.l..8
#=- kernel: 4C CC 50 4F 25 2E A9 14 L.PO%...
#=- kernel: 9D 18 F5 08 3B 03 9D AD ....;...
#=- kernel: C9 2D E1 CD F1 B7 96 3F .-.....?
#=- kernel: 56 E8 38 9B 14 AB 6F 78 V.8...ox
#=- kernel: FD 05 2D B4 ..-.
#=-
#=- Looks fine to me, as best I can tell -- but if it truly were fine, the
#=- Windows machine wouldn't be sending back ProtRej's.
#=-
#=- Any suggestions would be appreciated.
#=- Thanks for caring enough to read this far. :)
#=-

Eric Harashevsky (eharashe at mediaone.net)
----------------------------------------------------------------
If I were two faced, would I wear this one?