perform a key change, *and* our sequence numbers have wrapped,
ensure that the number of key changes is calculated correctly.
The previous code counted down from a negative number to zero,
re-encrypting the current key on each iteration - this took some
time and strangely enough got the answer wrong !!!
Fix a(nother) spelling mistake while I'm there.
This is necessary because MPPE will combine the protocol id with the
payload received on the tun interface, encrypt it, then prepend its
own protocol id, effectively increasing the payload by two bytes.
encryption compatibility with Windows 2000. Stateful encryption
uses less CPU but is bad on lossy transports.
The ``set mppe'' command has been expanded. If it's used with any
arguments, ppp will insist on encryption, closing LCP if the other
end refuses.
Unfortunately, Microsoft have abused the CCP reset request so that
receiving a reset request does not result in a reset ack when using
MPPE...
Sponsored by: Monzoon Networks AG and FreeBSD Services Limited
is called prior to sending a CCP configure request for a
given protocol. The default is to send the request, but
this is overridden for MPPE which checks to see if the lcp
negotiations agreed CHAP81, and if not fails.
Use the same function to decide if we should reject peer
requests for MPPE.
This should get rid of those boring messages about not being
able to initialise MPPE when we don't negotiate CHAP81.
MPPE session keys correctly.
I'm a bit dubious about this code. It seems that the session keys
are initialised differently based on whether you're the client or
the server. One side is the server if it issues the first challenge,
but of course you can issue a challenge from both sides.... at the
same time. Sounds like another wonderful M$ assumption...
Ppp can now talk to itself correctly using encryption.
Problem solved by: Ustimenko Semen <semen@iclub.nsu.ru>
Hair torn out by: me
