Commit Graph

18 Commits

Author SHA1 Message Date
brian
d4de4f097d Add a bunch of `const's and fix a typo.
Submitted by: Rich Neswold <rneswold@MCS.Net>
1999-12-27 11:54:57 +00:00
brian
919d0f538f Cosmetic: Make struct mbuf more like kernel mbufs. 1999-12-20 20:29:47 +00:00
brian
e896a92b45 o Split the two IPCP queues into three - one for FSM data
(LCP/CCP/IPCP), one for urgent IP traffic and one for
  everything else.
o Add the ``set urgent'' command for adjusting the list of
  urgent port numbers.  The default urgent ports are 21, 22,
  23, 513, 514, 543 and 544 (Ports 80 and 81 have been
  removed from the default priority list).
o Increase the buffered packet threshold from 20 to 30.
o Report the number of packets in the IP output queue and the
  list of urgent ports under ``show ipcp''.
1999-09-04 00:00:21 +00:00
peter
b6784c4210 $Id$ -> $FreeBSD$ 1999-08-28 01:35:59 +00:00
brian
caf44157f7 If we've negotiated CBCP and have also specified ``none'' as a possible
callback option, and the server sends us CBCP_NONUM, proceed directly
to the network phase rather than insisting on our configured CBCP
option.

Mostly submitted by: kkphang <phang@dgate.po.my>
1999-07-27 13:47:59 +00:00
brian
bbbd0aef90 o Alter the mbuf type as it's processed by different layers.
o Show more information about missing MP fragments in ``show mp''.
o Do away with mbuf_Log().  It was showing mbuf stats twice on
  receipt of LCP/CCP/IPCP packets.... ???!!?
o Pre-allocate a bit extra when creating LQR packets to avoid having
  to allocate another mbuf in mbuf_Prepend().
1999-06-02 15:59:09 +00:00
brian
5e107593b8 o Redesign the layering mechanism and make the aliasing code part of
the layering.

  We now ``stack'' layers as soon as we open the device (when we figure
  out what we're dealing with).  A static set of `dispatch' routines are
  also declared for dealing with incoming packets after they've been
  `pulled' up through the stacked layers.

  Physical devices are now assigned handlers based on the device type
  when they're opened.  For the moment there are three device types;
  ttys, execs and tcps.

o Increment version number to 2.2
o Make an entry in [uw]tmp for non-tty -direct invocations (after
  pap/chap authentication).
o Make throughput counters quad_t's
o Account for the absolute number of mbuf malloc()s and free()s in
  ``show mem''.
o ``show modem'' becomes ``show physical''.
1999-05-08 11:07:56 +00:00
brian
3b5efef0cd Ensure that the thing we're casting to struct ip
is aligned for non-i386 architectures.
1999-03-29 08:21:28 +00:00
brian
795be649bf Allow control over the number of ConfigREQ & TermREQ attempts
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.
1999-02-26 21:28:14 +00:00
brian
346d7ad3fe Initial RADIUS support (using libradius). See the man page for
details.  Compiling with -DNORADIUS (the default for `release')
removes support.

TODO: The functionality in libradius::rad_send_request() needs
      to be supplied as a set of routines so that ppp doesn't
      have to wait indefinitely for the radius server(s).  Instead,
      we need to get a descriptor back, select() on the descriptor,
      and ask libradius to service it when necessary.
      For now, ppp blocks SIGALRM while in rad_send_request(), so
      it misses PAP/CHAP retries & timeouts if they occur.

      Only PAP is functional.  When CHAP is attempted, libradius
      complains that no User-Password has been specified... rfc2138
      says that it *mustn't* be used for CHAP :-(

Sponsored by: Internet Business Solutions Ltd., Switzerland
1999-01-28 01:56:34 +00:00
brian
d1349ae967 Send the peer-decided PSTN address with the CBCP Ack,
otherwise windows clients will keep resending the
response :-/
It'd be nice if M$ would document this sort of thing !
Problem reported by: Andrzej Tobola <san@tmp.iem.pw.edu.pl>
1999-01-19 22:15:25 +00:00
brian
cf18a6636d If the CBCP callee offsers no callback, send our configured
response anyway.  This is what Win95 does, despite it not
being documented in the cbcp spec....
Reported by: Bill <petheram@acm.org>
1998-10-31 17:38:48 +00:00
brian
dc817dbd4a Don't send a DELAY value when sending CBCP_NONUM
(as per the spec).
Spotted by: Andrzej Tobola <san@koziolek.lublin.top.pl>
1998-10-25 23:35:15 +00:00
brian
49b7e39b2a Warn about (but process anyway) CBCP messages with an incorrect id. 1998-10-17 12:28:11 +00:00
brian
12b8595c89 Adjust our CBCP RESP id so that it's the same as the REQ.
Submitted by: Tom <root@majestix.cmr.no>
1998-10-17 12:28:09 +00:00
brian
936ff13c27 If the client asks for CBCP, then replies with CBCP_NONUM
to our REQ, allow no dialback - but only if we've
``set cbcp *''..
Suggested by: Andrzej Tobola <san@koziolek.lublin.top.pl>
1998-10-17 12:28:08 +00:00
brian
ee2bb826f4 Remove redundant include file. 1998-08-26 17:39:38 +00:00
brian
2dd00704c3 Missed these... 1998-08-07 18:44:16 +00:00