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

Tue Jun 13 16:55:43 CDT 2000

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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.schulte.org/mailman/private/pptp-server/attachments/20000613/b5a31619/attachment.bin>