From: Phil Mayers <p.mayers@imperial.ac.uk>
To: linux-ppp@vger.kernel.org
Subject: Re: final repost - MPPE incorrect REJECT/NAK behaviour (was Re: Windows
Date: Sun, 19 Feb 2006 23:40:29 +0000 [thread overview]
Message-ID: <43F901ED.20900@imperial.ac.uk> (raw)
In-Reply-To: <43F8F60F.70106@imperial.ac.uk>
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
prev parent reply other threads:[~2006-02-19 23:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-19 22:49 final repost - MPPE incorrect REJECT/NAK behaviour (was Re: Windows Phil Mayers
2006-02-19 23:02 ` final repost - MPPE incorrect REJECT/NAK behaviour (was Re: Windows mobile 2005 clients) James Cameron
2006-02-19 23:40 ` Phil Mayers [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43F901ED.20900@imperial.ac.uk \
--to=p.mayers@imperial.ac.uk \
--cc=linux-ppp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.