Hello John -
On Fri, 17 Mar 2000, [EMAIL PROTECTED] wrote:
> On Fri, 17 Mar 2000, Hugh Irvine wrote:
>
> > > I was wondering if there is a way to make radiator send accounting info to
> > > two different dbs. I'm using AuthBy Rodopi and the accounting attributes
> > > recorded are minimal. I'd like to be able to log more information to
> > > another sql db at the same time. Is this possible?
> > >
> >
> > Sure - chain two AuthBy's like this:
>
> This just gave me an idea. First, what happens if a single request is
> handled by more than 1 <AuthBy ...>'s resulting in some mix of accepts and
> rejects? Would the first returned result win and be the only one returned
> to the client?
>
Exactly what happens is determined by the AuthByPolicy used to chain the
<AuthBy ...>'s. There will only be one reply returned to the Client however,
except with <AuthBy RADIUS> which continues processing asynchronously.
> We have problems on our Cisco access servers when an <AuthBy RADIUS>
> request times out because the radius server it was proxied to is
> unreachable or not responding. We thought about trying to hack radiator
> to return a reject in these cases...but what happens with AuthByPolicy
> ContinueWhileIgnore if multipel <AuthBy ...>'s fork, and one returns a non
> Ignore result while the other is still running? Is the remaining <AuthBy
> ...> killed? I was thinking "what if we did an <AuthBy External> that
> jjust slept for X seconds and returned a reject?" Doing this for every
> login would result in too many radiusd processes sitting around unless
> they were killed off when the first <AuthBy RADIUS> returned a non-ignore
> result.
>
The thought with <AuthBy RADIUS> is that it is better to Ignore if a proxy is
unreachable, because then the NAS can walk through a list of alternative Radius
servers. If you return a Reject, of course, the NAS will simply Reject the call.
Also, from your description above, it does not make sense to chain AuthBy's and
then specify Fork, as the two concepts are mutually exclusive. Ie - you can't
chain <AuthBy ...>'s that depend on returned results before moving to the next
one, and then not wait for the result.
> I think it's getting too late at night for rational thought though.
>
> Can timeout() in AuthRADIUS.pm return ($main::REJECT) to fake a reject
> packet?
>
You could probably achieve the same result by not specifying a retry count on
the NAS, or possibly a relatively short timeout and only one retry.
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
