Supply RAD_NAS_IDENTIFIER if we have a `hostname` and
RAD_IP_ADDRESS if that hostname resolves.
Supply RAD_NAS_PORT using the ttyslot() of the tty that
we're authenticating on if it's a tty device.
Partially submitted by: Andriy I Pilipenko <bamby@marka.net.ua>
PR: 12225
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''.
This was pretty harmless as netmasks on a POINTOPOINT
interface are pretty much ignored, but it looked funny.
Mention the configured netmask in ``show ipcp''.
Describe in more detail what a proxy arp entry is.
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
configured. This isn't strictly necessary according to the
rfc, but it's suggested there....
o Don't forget to include our authname when sending a
CHAP challenge when RADIUS is configured.
o Don't supply the ``16'' representing the chap answer
length to radius_Authenticate() - libradius does this
for us.
o When we successfully authenticate via radius_Authenticate(),
continue with datalink_AuthOk() as expected.
Sponsored by: Internet Business Solutions Ltd., Switzerland
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
