1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-21 11:13:30 +00:00
Commit Graph

16 Commits

Author SHA1 Message Date
Brian Somers
442f849547 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 Wemm
97d92980a9 $Id$ -> $FreeBSD$ 1999-08-28 01:35:59 +00:00
Brian Somers
8d14e328f9 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 Somers
411675bae3 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 Somers
5d9e610366 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 Somers
aad80d9f1b 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 Somers
479508cf28 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 Somers
972a1bcf5d 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 Somers
8e1fea3105 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 Somers
9fddf73ad0 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 Somers
f6f122b486 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 Somers
359b523392 Warn about (but process anyway) CBCP messages with an incorrect id. 1998-10-17 12:28:11 +00:00
Brian Somers
0e0c8ee5fc 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 Somers
f21c8aecd1 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 Somers
653ead3365 Remove redundant include file. 1998-08-26 17:39:38 +00:00
Brian Somers
0581dfeff0 Missed these... 1998-08-07 18:44:16 +00:00