| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Mention more rfc numbers.
Don't ``.Nm Ppp'' (just use ``.Nm'').
|
|
|
|
script, expand words in the same way as !bg does.
|
|
|
|
|
|
|
|
each time rather than making up a new one.
Increase the authname/authkey max sizes to 100 characters.
Allow ``authkey'' specifications beginning with ``!''.
When a challenge is received, the text following the
``!'' is executed as a program (expanding stuff in the same
way that ``sh'' and ``!bg'' do). The program is passed the
peer name, peer challenge and local ``authname'' on standard
input and is expected to output the name/key combination that
should be used to build the CHAP response.
This provides support for Secure ID cards (guess what I was
given at work recently!) using CHAP.
Examples will follow.
|
|
|
|
(broken with last commit).
|
|
|
|
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
|
|
|
|
|
|
|
|
item is scheduled rather than interrupting 10 times per second
and finding that there's nothing to do most of the time.
This change reduces interrupt overheads but will expose any
(previously small) latency problems.
Be more careful about building VJ compression requests - we
can't htonl/ntohl the entire four bytes ! Also, when we get
a NAK, try to get as close as possible to what the peer NAKs
with when sending our next REQ. Similarily when we send a NAK,
pick values as close as possible to what the peer REQd.
Fix a couple of man page typos (compliments of billf@FreeBSD.org)
|
|
|
|
|
|
|
|
the command line.
Revise the error diagnostics so that invalid labels
are reported immediately.
|
|
at the authentication layer rather than at the PAP layer
so that it also applies to CHAP (no response to CHAP
challenges).
|
|
|
|
requests, give up (don't sit there indefinitely).
|
|
|
|
section.
Submitted by: Dan Lukes <dan@obluda.cz>
|
|
|
|
|
|
|
|
got an open link, we want it to be select()d on - otherwise
we get a freeze when ``openmode'' is passive.
|
|
Increase requested by: "Clement T. Cole" <clemc@echo.ccc.com>
|
|
USER is expected to be expanded.
|
|
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>
|
|
lines; lcamtuf@IDS.PL
|
|
found in the various config files.
|
|
|
|
|
|
CALLBACK protocol and end up agreeing CBCP, DTRT and go
into CBCP phase rather than mistakenly terminating as
if CBCP wasn't agreed.
Problem reported by: Alexander Dubinin <alex@nstl.nnov.ru>
|
|
Noted & partially submitted by: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>
|
|
the answer.
If we later get a descriptor exception from select(), we know
that it's a tty (isatty() returns 0 after the exception on a
tty) and remember to call modem_LogicalClose().
The upshot of it all is that descriptor exceptions dont leave
the tty locked any more.
|
|
resulting NULL FILE *.
|
|
dial & login are successful.
Submitted by: Toshiomi Moriki <Toshiomi.Moriki@ma1.seikyou.ne.jp>
|
|
mode, not in -ddial and -direct.
Pointed out by: Chris Timmons <skynyrd@opus.cts.cwu.edu>
|
|
is 0.0.0.0. This isn't a problem as the sticky route is still
added.
Suggested by: Chris Timmons <skynyrd@opus.cts.cwu.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
