src/usr.sbin/ppp/auth.h, branch release/6.0.0_cvs

This commit was manufactured by cvs2svn to create tag

2005-11-03T00:35:26+00:00

'RELENG_6_0_0_RELEASE'.

This commit was manufactured to restore the state of the 6.0-RELEASE image.

Make ppp WARNS=5 clean

2004-09-05T01:46:52+00:00

Add support for MS-CHAP authentication via a RADIUS server.

2002-05-10T03:11:35+00:00

Add support for Reply-Message and MS-CHAP-Error.

Sponsored by:	Monzoon

Convert IIJ copyrights to BSD copyrights.

2001-06-13T21:52:19+00:00

Approved by: Toshiharu OHNO

$Id$ -> $FreeBSD$

1999-08-28T01:35:59+00:00

Allow control over the number of ConfigREQ & TermREQ attempts

1999-02-26T21:28:14+00:00

that are made in each of the FSMs (LCP, CCP & IPCP) and the
number of REQs/Challenges for PAP/CHAP by accepting more arguments
in the ``set {c,ip,l}cpretry'' and ``set {ch,p}apretry'' commands.

Change the non-convergence thresholds to 3 times the number of configured
REQ tries (rather than the previous fixed ``10'').  We now notice
repeated NAKs and REJs rather than just REQs.

Don't suggest that CHAP 0x05 isn't supported when it's not configured.

Fix some bugs that expose themselves with smaller numbers of retries:
o Handle instantaneous disconnects (set device /dev/null) correctly
  by stopping all fsm timers in fsm2initial.
o Don't forget to uu_unlock() devices that are files but are not
  ttys (set device /dev/zero).

Fix a *HORRENDOUS* bug in RFC1661 (already fixed for an Open event in state
``Closed''):
  According to the state transition table, a RCR+ or RCR- received in
  the ``Stopped'' state are supposed to InitRestartCounter, SendConfigReq
  and SendConfig{Ack,Nak}.  However, in ``Stopped'', we haven't yet
  done a TLS (or the last thing we did is a TLF).  We must therefore
  do the TLS at this point !

  This was never noticed before because LCP and CCP used not use
  LayerStart() for anything interesting, and IPCP tends to go into
  Stopped then get a Down because of an LCP RTR rather than getting a
  RCR again.

Fully support both NT and LANMan CHAP type 0x80 as both

1999-02-18T00:52:15+00:00

authenticator and authenticatee.

Decouple pap & chap output routines from the corresponding

1999-02-06T02:54:47+00:00

input routines and take advantage of the new init/continue
interface in libradius.  This allows a timely response on
other links in an MP setup while RADIUS requests are in
progress as well as the ability to handle other data from
the peer in parallel.  It should also make the future addition
of PAM support trivial.

While I'm in there, validate pap & chap header IDs if
``idcheck'' is enabled (the default) for other FSM packet
types.

NOTE: This involved integrating the generation of chap
      challenges and the validation of chap responses
      (and commenting what's going on in those routines).
      I currently have no way of testing ppps ability
      to respond to M$Chap CHALLENGEs correctly, so if
      someone could do the honours, it'd be much
      appreciated (it *looks* ok!).

Sponsored by: Internet Business Solutions Ltd., Switzerland

Reimplement the previous fix (no response to PAP requests)

1999-02-02T09:35:17+00:00

at the authentication layer rather than at the PAP layer
so that it also applies to CHAP (no response to CHAP
challenges).

If we receive no answer from the server when sending PAP

1999-02-01T13:42:25+00:00

requests, give up (don't sit there indefinitely).