Reemission bug in multi-threaded mode + FreeRADIUS 2.0 roadmap questions

[Geoffroy Arnoud]

> 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?
> 
Hi,

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
network)

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
example.

Geoff.



	

	
		
___________________________________________________________________________ 
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 
http://fr.answers.yahoo.com