Hello All,
On Aug 31, 8:00am, Ingvar Berg (ERA) wrote:
> Subject: RE: (RADIATOR) <AuthBy RADIUS> Problems with ContinueWhileReject
> > -----Original Message-----
> > From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> >
> > On Tue, 31 Aug 1999, Robert Mann wrote:
> > > This is the last portion of my config file. The result I
> > am looking for is
> > > as follows.
> > >
> > > We want to authenticate until we have an accept. We have
> > two ISP's so what
> > > happens is that we try to authenticate from the primary
> > ISP's radius server
> > > first and if authentication fails then it moves to the
> > second ISP's radius
> > > server and try's to pass there.
> > >
> >
> > Thanks for this - the problem you are seeing has to do with
> > the asynchronous
> > nature of AuthBy RADIUS processing which is handled
> > differently to all the
> > other AuthBy's. Basically what happens is this: when a
> > request is passed to an
> > AuthBy RADIUS clause, the request is proxied out to the
> > remote radius server
> > and we return from that clause immediately and continue
> > processing as much as
> > we can. Then when the remote radius response arrives, we
> > continue at that
> > point. Now what you are seeing is that *both* remote requests
> > are sent, and
> > whichever one responds first is the one that gets returned to
> > the client (the
> > second one also gets returned to the client). This is clearly
> > not what you want.
> >
> > We have discussed this issue here a couple of times and at
> > the moment it is not
> > clear what the best approach to take is. Does anyone else
> > have any comments to
> > make on this topic?
>
> It is obviously so that there are valid cases for both an async and a sync
behaviour. So it should be configurable, either by a config switch or by having
two versions of AuthRADIUS (whichever gives the best performance :-)
Ingvar is correct.
I have uploaded a new experimental version of AuthRADIUS.pm to the 2.14.1
patches area.
This new version implements a new parameter called Synchronous which will cause
the AuthBy RADIUS to block until a reply is received from the remote radius
server (or it times out). It will only continue to process following AuthBy
clauses after the remote has responded (or timed out).
As Ingvar points out, there can be a serious performace hit with this, since
incoming requests will not be handled until the reply (or timeout) is received
from the remote radius server.
You might consider using the Fork flag to reduce the effect of this, at the
cost of increased memory usage.
In any case, use it with caution.
Let me know if there are any problems.
Cheers.
>
> /Ingvar
> >
> > thanks
> >
> > Hugh
> >
> > --
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> > Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
> > NT, Rhapsody
> >
> > ===
> > Archive at http://www.thesite.com.au/~radiator/
> > To unsubscribe, email '[EMAIL PROTECTED]' with
> > 'unsubscribe radiator' in the body of the message.
> >
>
> ===
> Archive at http://www.thesite.com.au/~radiator/
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
>-- End of excerpt from Ingvar Berg (ERA)
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, Rhapsody
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
