Adding Matt Domsch as author of in-kernel MPPE.

Begin forwarded message:

Date: Wed, 4 Jan 2006 12:53:40 -0800
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 5827] New: pppd with MPPE fails


http://bugzilla.kernel.org/show_bug.cgi?id=5827

           Summary: pppd with MPPE fails
    Kernel Version: 2.6.15
            Status: NEW
          Severity: high
             Owner: jgarzik@pobox.com
         Submitter: krzysiek.pawlik@people.pl


Most recent kernel where this bug did not occur: none
Distribution: Gentoo
Hardware Environment: ASUS A3E-5018
Software Environment: Gentoo
Problem Description:

pppd with MPPE doesn't work properly, logs such messages:

Jan  4 17:13:53 nelchael pppd[7651]: pppd 2.4.3 started by root, uid 0
Jan  4 17:13:53 nelchael pppd[7651]: Using interface ppp0
Jan  4 17:13:53 nelchael pppd[7651]: Connect: ppp0 <--> /dev/pts/2
Jan  4 17:13:55 nelchael pppd[7651]: CHAP authentication succeeded
Jan  4 17:13:55 nelchael pppd[7651]: MPPE 128-bit stateful compression enabled
Jan  4 17:13:58 nelchael pppd[7651]: local  IP address x.x.x.8
Jan  4 17:13:58 nelchael pppd[7651]: remote IP address x.x.x.13
Jan  4 17:14:15 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xf3
Jan  4 17:14:16 nelchael pppd[7651]: Protocol-Reject for unsupported protocol
'Encryption' (0x53)
Jan  4 17:14:17 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x5afc
Jan  4 17:14:18 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xc25a
Jan  4 17:14:19 nelchael pppd[7651]: Protocol-Reject for unsupported protocol
'NETBIOS Framing' (0x3f)
Jan  4 17:14:20 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xe3
Jan  4 17:14:21 nelchael pppd[7651]: Protocol-Reject for unsupported protocol
'MP+' (0x73)
Jan  4 17:14:23 nelchael pppd[7651]: Protocol-Reject for unsupported protocol
'SNA over 802.2' (0x4b)
Jan  4 17:14:24 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xa8b6
Jan  4 17:14:25 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x50dc
Jan  4 17:14:26 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x2c52
Jan  4 17:14:27 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x1d
Jan  4 17:14:28 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x8432
Jan  4 17:14:29 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x40e4
Jan  4 17:14:30 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xe2f3
Jan  4 17:14:32 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x347d
Jan  4 17:14:33 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x1e35
Jan  4 17:14:34 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x1842
Jan  4 17:14:35 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x641e
Jan  4 17:14:36 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x44f1
Jan  4 17:14:37 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xcd
Jan  4 17:14:38 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xf07a
Jan  4 17:14:39 nelchael pppd[7651]: Protocol-Reject for unsupported protocol
'MPLS Unicast' (0x281)
Jan  4 17:14:40 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x3012
Jan  4 17:14:41 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xf8e4
Jan  4 17:14:42 nelchael pppd[7651]: Protocol-Reject for unsupported protocol
'AppleTalk SmartBuffered' (0x3b)


Everything was ok with 2.6.14(.*) with this ( http://mppe-mppc.alphacron.de/ )
patch applied, but MPPE and above situation happens with the in-kernel version
of MPPE.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

the in-kernel MPPE module doesn't implement MPPC, and it won't.  Try disabling 
MPPC, and/or following the debugging tips at http://pptpclient.sourceforge.net 
for how to resolve this.

The server disables MPPC, so it's disabled.

http://pptpclient.sourceforge.net/howto-diagnosis.phtml#lcp_protrej_1

seems to cover this, does it not?

Ok, I'll test it in a few days (when I get near that network which uses pptp).

Reply-To: james.cameron@hp.com

This is expected, and similar output has been seen before.

Jan Dubiec's pppd works with Jan Dubiec's PPP MPPE/MPPC kernel module,
and does not always work with the PPP MPPE module maintained by the PPP
team.

In upgrading to 2.6.15, one should also convert to the upstream pppd
from ppp.samba.org.  Please do that and tell us the outcome.

I'm using pppd with some patch (it starts with:

This patch have been adapted for current (2005-05-05) CVS version of ppp-2.4.3.
The original could be found at
    http://www.polbox.com/h/hs001/ppp-2.4.3-mppe-mppc-1.1.patch.gz

). It misses information about author.

The same with MPPE-40 (128 and 56 disabled):

Jan 12 09:09:00 nelchael pppd[6423]: pppd 2.4.3 started by root, uid 0
Jan 12 09:09:00 nelchael pppd[6423]: Using interface ppp0
Jan 12 09:09:00 nelchael pppd[6423]: Connect: ppp0 <--> /dev/pts/3
Jan 12 09:09:02 nelchael pppd[6423]: CHAP authentication succeeded
Jan 12 09:09:02 nelchael pppd[6423]: MPPE 40-bit stateful compression enabled
Jan 12 09:09:05 nelchael pppd[6423]: local  IP address x.x.202.10
Jan 12 09:09:05 nelchael pppd[6423]: remote IP address x.x.96.13
Jan 12 09:09:14 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0xb498
Jan 12 09:09:29 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0xa1f
Jan 12 09:09:30 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0x224f
Jan 12 09:09:31 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0x8d
Jan 12 09:09:33 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0xdd
Jan 12 09:09:34 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0xe22d
Jan 12 09:09:35 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0x5658
Jan 12 09:09:36 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0xe3
Jan 12 09:09:37 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0x9eed
Jan 12 09:09:38 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0xd264
Jan 12 09:09:39 nelchael pppd[6423]: Protocol-Reject for unsupported protocol 0xb22e

I've seen this same behaviour, I've tried ppp-2.4.2 and 2.4.3 with mppe-mppc-1.1
patches.  Works perfectly with 2.6.14 and the MPPE_MPPC kernel patch, but with
MPPE built into 2.6.15 I can authenticate, but every packet that comes back is
rejected with unsupported protocol.

I went through the whole list of debugging tips at pptp.sourceforge.net -
disabling compression with nopcomp and noaccomp,
turning off the various key lengths, adding stateless option etc. 
all to no avail.  

I'm also using Gentoo.

Any further suggestions would be appreciated.

Ok, I just got this figured out.

On Gentoo, the mppe-mppc USE flag adds an mppe-mppc patch that strips out the
mppe support that is built into ppp and replaces it with what I expect is Jan
Dubiec's mppe-mppc code.

Simply turning off the mppe-mppc flag and reinstalling ppp solved my problem. 
This has the happy side effect of resolving a number of minor issues with
pptpconfig.

I will suggest that this problem be listed at pptpconfig.sourceforge.net, and
suggest that the gentoo ebuild for ppp spit out a warning.

PPPd without mppe-mppc patch still doesn't work - the same situation with
"Protocol-Reject for unsupported protocol".

Created attachment 7734 [details]
PPP MPPE: do not accept unsupported MPPE options

Apparently the MPPE code which went into the kernel does not fully check MPPE
options - it just ignores bits which it does not support.  Therefore all pppd
checks for kernel capabilities succeed, and pppd might negotiate an MPPE
configuration which is not supported by the kernel.  Unfortunately, all
comments in this bug lack CCP negotiation messages (produced by pppd with the
"debug" option), so I cannot determine whether this happens here.

Can someone try this kernel patch with different pppd versions and determine if
it fixes the problem?

Kernel 2.6.16.16 with patch:

May 15 10:04:58 laptok pppd[7538]: pppd 2.4.3 started by root, uid 0
May 15 10:04:58 laptok pppd[7538]: using channel 1
May 15 10:04:58 laptok pppd[7538]: Using interface ppp0
May 15 10:04:58 laptok pppd[7538]: Connect: ppp0 <--> /dev/pts/2
May 15 10:04:58 laptok pppd[7538]: sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap
0x0> <magic 0x943604dc> <pcomp> <accomp>]
May 15 10:05:00 laptok pppd[7538]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth
chap MS-v2> <magic 0x39b2dcfe> <pcomp> <accomp>]
May 15 10:05:00 laptok pppd[7538]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth
chap MS-v2> <magic 0x39b2dcfe> <pcomp> <accomp>]
May 15 10:05:00 laptok pppd[7538]: rcvd [LCP ConfAck id=0x1 <mru 1000> <asyncmap
0x0> <magic 0x943604dc> <pcomp> <accomp>]
May 15 10:05:00 laptok pppd[7538]: sent [LCP EchoReq id=0x0 magic=0x943604dc]
May 15 10:05:00 laptok pppd[7538]: rcvd [CHAP Challenge id=0x8a
<7ba75d3072c2c6675711862da3621a18>, name = "wifi"]
May 15 10:05:00 laptok pppd[7538]: sent [CHAP Response id=0x8a
<2dc585176d1ab88b373189b10f721b6c00000000000000007c4e05d44ad16e23bfd3e71aee08e8b8c078e5eb20e7369800>,
name = "yaq"]
May 15 10:05:00 laptok pppd[7538]: rcvd [LCP EchoRep id=0x0 magic=0x39b2dcfe]
May 15 10:05:00 laptok pppd[7538]: rcvd [CHAP Success id=0x8a
"S=C0944EF2703FC59A1EF32F914465E7A8B7705DE0 M=Access granted"]
May 15 10:05:00 laptok pppd[7538]: CHAP authentication succeeded
May 15 10:05:00 laptok pppd[7538]: sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D
-C>]
May 15 10:05:00 laptok pppd[7538]: rcvd [CCP ConfReq id=0x1 <mppe -H +M +S +L -D
-C>]
May 15 10:05:00 laptok pppd[7538]: Refusing MPPE stateful mode offered by peer
May 15 10:05:00 laptok pppd[7538]: MPPE required but peer negotiation failed
May 15 10:05:00 laptok pppd[7538]: sent [LCP TermReq id=0x2 "MPPE required but
peer negotiation failed"]
May 15 10:05:00 laptok pppd[7538]: sent [CCP ConfRej id=0x1 <mppe -H +M +S +L -D
-C>]
May 15 10:05:00 laptok pppd[7538]: rcvd [CCP ConfNak id=0x1 <mppe -H -M +S -L -D
-C>]
May 15 10:05:00 laptok pppd[7538]: Discarded non-LCP packet when LCP not open
May 15 10:05:00 laptok pppd[7538]: rcvd [LCP TermAck id=0x2]
May 15 10:05:00 laptok pppd[7538]: Connection terminated.
May 15 10:05:01 laptok pppd[7538]: Exit.



with mppe-stateful added, and pinging result after connection is established:

May 15 10:05:43 laptok pppd[7617]: pppd 2.4.3 started by root, uid 0
May 15 10:05:43 laptok pppd[7617]: using channel 3
May 15 10:05:43 laptok pppd[7617]: Using interface ppp0
May 15 10:05:43 laptok pppd[7617]: Connect: ppp0 <--> /dev/pts/2
May 15 10:05:43 laptok pppd[7617]: sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap
0x0> <magic 0x51f69a53> <pcomp> <accomp>]
May 15 10:05:45 laptok pppd[7617]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth
chap MS-v2> <magic 0xc65cdeee> <pcomp> <accomp>]
May 15 10:05:45 laptok pppd[7617]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth
chap MS-v2> <magic 0xc65cdeee> <pcomp> <accomp>]
May 15 10:05:45 laptok pppd[7617]: rcvd [LCP ConfAck id=0x1 <mru 1000> <asyncmap
0x0> <magic 0x51f69a53> <pcomp> <accomp>]
May 15 10:05:45 laptok pppd[7617]: sent [LCP EchoReq id=0x0 magic=0x51f69a53]
May 15 10:05:45 laptok pppd[7617]: rcvd [CHAP Challenge id=0x16
<4b88b0584867d7bc053880ebedf5066f>, name = "wifi"]
May 15 10:05:45 laptok pppd[7617]: sent [CHAP Response id=0x16
<fad7d22a997cfd212e644c37e3cd8e7500000000000000003b4562b484485ac67a6fc6d7b86fd773f2fccb82f2bfc23900>,
name = "yaq"]
May 15 10:05:45 laptok pppd[7617]: rcvd [LCP EchoRep id=0x0 magic=0xc65cdeee]
May 15 10:05:45 laptok pppd[7617]: rcvd [CHAP Success id=0x16
"S=E6B1510D9CECB50A3C3ED00CE986CFC0699FF90C M=Access granted"]
May 15 10:05:45 laptok pppd[7617]: CHAP authentication succeeded
May 15 10:05:45 laptok pppd[7617]: sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D
-C>]
May 15 10:05:45 laptok pppd[7617]: rcvd [CCP ConfReq id=0x1 <mppe -H +M +S +L -D
-C>]
May 15 10:05:45 laptok pppd[7617]: sent [CCP ConfNak id=0x1 <mppe -H -M +S -L -D
-C>]
May 15 10:05:45 laptok pppd[7617]: rcvd [CCP ConfNak id=0x1 <mppe -H -M +S -L -D
-C>]
May 15 10:05:45 laptok pppd[7617]: sent [CCP ConfReq id=0x2 <mppe -H -M +S -L -D
-C>]
May 15 10:05:45 laptok pppd[7617]: rcvd [CCP ConfReq id=0x2 <mppe -H -M +S -L -D
-C>]
May 15 10:05:45 laptok pppd[7617]: sent [CCP ConfAck id=0x2 <mppe -H -M +S -L -D
-C>]
May 15 10:05:45 laptok pppd[7617]: rcvd [CCP ConfAck id=0x2 <mppe -H -M +S -L -D
-C>]
May 15 10:05:45 laptok pppd[7617]: MPPE 128-bit stateful compression enabled
May 15 10:05:45 laptok pppd[7617]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01>
<addr 0.0.0.0>]
May 15 10:05:45 laptok pppd[7617]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01>
<addr 149.156.96.13>]
May 15 10:05:45 laptok pppd[7617]: sent [IPCP ConfAck id=0x1 <compress VJ 0f 01>
<addr 149.156.96.13>]
May 15 10:05:45 laptok pppd[7617]: rcvd [IPCP ConfNak id=0x1 <addr 149.156.202.14>]
May 15 10:05:45 laptok pppd[7617]: sent [IPCP ConfReq id=0x2 <compress VJ 0f 01>
<addr 149.156.202.14>]
May 15 10:05:45 laptok pppd[7617]: rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01>
<addr 149.156.202.14>]
May 15 10:05:45 laptok pppd[7617]: Cannot determine ethernet address for proxy ARP
May 15 10:05:45 laptok pppd[7617]: local  IP address 149.156.202.14
May 15 10:05:45 laptok pppd[7617]: remote IP address 149.156.96.13
May 15 10:05:45 laptok pppd[7617]: Script /etc/ppp/ip-up started (pid 7629)
May 15 10:05:45 laptok pppd[7617]: Script /etc/ppp/ip-up finished (pid 7629),
status = 0x1
May 15 10:05:50 laptok pppd[7617]: rcvd [CCP ResetReq id=0x3]
May 15 10:05:50 laptok pppd[7617]: sent [CCP ResetAck id=0x3]
May 15 10:05:51 laptok pppd[7617]: rcvd [LCP ProtRej id=0x2 30 58 08 92 19 6c f7
4e 39 67 c4 54 5e 78 a7 95 16 f5 37 55 dc 4f 61 1d 80 a5 03 ba 12 39 0e 45 ...]
May 15 10:05:51 laptok pppd[7617]: Protocol-Reject for unsupported protocol 0x3058
May 15 10:05:52 laptok pppd[7617]: rcvd [LCP ProtRej id=0x3 00 f9 f6 03 e0 be 39
f9 19 73 0f 6d 64 72 b3 19 05 db 73 41 d9 35 98 74 4d b6 85 04 1f 96 f3 ec ...]
May 15 10:05:52 laptok pppd[7617]: Protocol-Reject for unsupported protocol 0xf9
May 15 10:05:53 laptok pppd[7617]: rcvd [LCP ProtRej id=0x4 d4 2b 1c 80 d2 cc 7e
8d 7f 99 c0 57 c8 68 b0 0d 3a 42 4f bc 93 8c bf 31 6e 22 cc 08 93 35 a0 29 ...]
May 15 10:05:53 laptok pppd[7617]: Protocol-Reject for unsupported protocol 0xd42b
May 15 10:05:54 laptok pppd[7617]: rcvd [LCP ProtRej id=0x5 56 88 03 0a 39 38 86
3d ef e0 1e de e1 d3 b8 9c 91 b9 de 47 38 ad 3b 41 00 86 34 9a 36 d6 fe 7c ...]
May 15 10:05:54 laptok pppd[7617]: Protocol-Reject for unsupported protocol 0x5688
May 15 10:05:55 laptok pppd[7617]: rcvd [LCP ProtRej id=0x6 ce f2 5f ae 94 08 4d
0b 23 eb 5b d6 f1 20 14 97 4f 10 02 6c 5a c4 c3 d5 07 2c cc 7f a0 55 dd 3a ...]

I too have this problem on a pppoe server (rp-pppoe). I've tried 2.6.15.5,
2.6.16.20 and 2.6.17.7 (and from what I see in the git web interface mppe has
not changed in these versions). 
pppd is 2.4.4, rp-pppoe is 3.8 without any patches (on Slackware).

Some more information, Windows only supports stateful MPPE with PPPoE (but
interestingly it seems to support stateless with PPtP). 

This problem appears when pppd negotiates a stateful MPPE on a PPPoE connection.
I've tried to connect with a Linux client, and since Linux supports stateless
MPPE on PPPoE it all worked fine.

I've also tried user-space/kernel pppoe and also tried sync (n_hdlc)/async PPP
nothing changed the situation.

I can provide debugs if something else is needed.

Here's the CCP negotiation

sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]
rcvd [CCP ConfReq id=0x5 <mppe -H -M -S -L -D +C>]
sent [CCP ConfNak id=0x5 <mppe +H -M +S +L -D -C>]
rcvd [IPCP ConfReq id=0x6 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0>
<ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP TermAck id=0x6]
rcvd [CCP ConfNak id=0x1 <mppe -H -M +S -L -D -C>]
sent [CCP ConfReq id=0x2 <mppe -H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x7 <mppe -H -M +S -L -D -C>]
sent [CCP ConfAck id=0x7 <mppe -H -M +S -L -D -C>]
rcvd [CCP ConfAck id=0x2 <mppe -H -M +S -L -D -C>]
MPPE 128-bit stateful compression enabled
sent [IPCP ConfReq id=0x1 <addr 2.3.4.5>]
rcvd [IPCP ConfAck id=0x1 <addr 2.3.4.5>]
rcvd [IPCP ConfReq id=0x8 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0>
<ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP ConfRej id=0x8 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
rcvd [IPCP ConfReq id=0x9 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
sent [IPCP ConfNak id=0x9 <addr 1.2.3.4> <ms-dns1 xx.xx.xx.xx> <ms-dns3
yy.yy.yy.yy>]
rcvd [IPCP ConfReq id=0xa <addr 1.2.3.4> <ms-dns1 xx.xx.xx.xx> <ms-dns3
yy.yy.yy.yy>]
sent [IPCP ConfAck id=0xa <addr 1.2.3.4> <ms-dns1 xx.xx.xx.xx> <ms-dns3
yy.yy.yy.yy>]
local  IP address 2.3.4.5
remote IP address 1.2.3.4

BTW.
At the same time that pppd logs:
MPPE 128-bit stateful compression enabled
dmesg says
mppe_comp_init[0]: initialized with 128-bit stateful mode
mppe_comp_init[0]: keys: master: 9e93a1c83f125f8545a265512a8037db initial
session: e228e95462341b3e5850d60f2cf5ba9e

And on the windows client side, it reports that it uses 128-bit stateful MPPE,
and no compression.

Is this still a problem?  What were the results of the testing with the
suggested patch?

Matt how does the patch help with MPPE 128-bit stateful encription?
The kernel claims to support it, but obviosuly it does something wrong.

Am already fix this problem by setting a MTU 1500 on every interface that use 
pptp connections.

Thnx 2all

Any updates on this problem? Did anyone get chance to test the patch and/or latest kernel?
Thanks.

I've not tested this but it seems 2.6.23 (and 2.6.22.10) finally solve this. I suspect it's the commit 45dfd5b5dd20f17fe23dafc5cfe921474d27f849.

Will test it on monday.

Damjan, can you confirm this works for you now?

Thanks,
Matt

Sorry.. I got ill that week, and then forgot to make the test.


The verdict is, NO it still doesn't work as of 2.6.23.1

I got a ton of these messages from pppd
Nov  3 20:50:53 archaeopteryx pppd[7306]: Unsupported protocol 0xd5 received
Nov  3 20:50:54 archaeopteryx pppd[7306]: Unsupported protocol 0x2af0 received
Nov  3 20:50:54 archaeopteryx pppd[7306]: Unsupported protocol 0xdd received

Closing out stale bugs

How do you mean stale bugs when the problem is not resolved. 

From: james.cameron@hp.com [mailto:james.cameron@hp.com] 

Reviewed #8009 and #5827.

The peer initially tries to negotiate compression (+C), but the host
negotiates out of it, and the peer agrees.

Then during the connection, the peer transmits packets with compression,
despite saying it agrees not to.  The host does not recognise them.

We've seen this plenty of times.  It is as if the peers ignore the
negotiated options.  "You've got MPPE, you must have MPPC."

Or the host is not obeying the options it has negotiated.

Alas, I have no peers that do this.  A pppdump and lengthy analysis of
the data stream would be required.  I don't know the kernel code that
well, and I don't know the data structures in the stream at all.