Reemission bug in multi-threaded mode + FreeRADIUS 2.0 roadmap questions
garnoud at yahoo.co.uk
Wed Nov 15 14:35:54 CET 2006
> Let me illustrate our situation and let's see if the
> same can be
> achieved in synchronous mode. We operate a proxy
> radius for a DSL
> service in Greece.
> For each realm (around 5 realms) we maintain a
> primary and a backup
> radius server. What we don't want to happen is for
> the *NAS* to mark the
> *proxy* radius dead because one home proxy is not
> responding. That's
> where asynchronous mode comes useful. We set
> retry_delay * retry_times *
> number of home servers < retry_delay * retry_times
> on the NAS so that we
> can mark home servers and realms dead *before* the
> NAS marks the whole
> proxy radius service dead (which we want to avoid
> except if the proxy
> service itself is not available). How can we achieve
> a similar setup in
> synchronous mode?
I work with Nicolas who did send the first mail. We
are facing the same problematic, as we are
implementing a RADIUS proxy, interconnecting lots of
access networks with lots of home networks.
We are not directly linked to NASes, but with access
networks RADIUS servers.
We are developping a patch to allow timeout/retires to
be configured for each realm, but onr can imagine a
configuration per relationship (access network / home
I think that synchronous is not bad, but for such
implentations, a way must be find to allow FreeRADIUS
to detect that the proxying failed, and maybe execute
some module on such an event (post-proxy section?).
On could think of attaching TO/retries (or expiration
timer) to incoming requests, matching the NAS that
originated the request, based on RADIUS attributes for
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses
More information about the Freeradius-Devel