Reemission bug in multi-threaded mode + FreeRADIUS 2.0 roadmap questions
garnoud at yahoo.co.uk
Fri Nov 17 08:08:18 CET 2006
--- Alan DeKok <aland at deployingradius.com>:
> Geoffroy Arnoud <garnoud at yahoo.co.uk> wrote:
> > That sounds interesting. I suppose that this
> > configuration could be a *per realm* parameter?
> Again, why per realm? The should be at least one
> setting: global.
> Then, maybe per *NAS* settings, because the timeouts
> may be different
> on each NAS.
> To put it another way, the problem is the NAS
> timing out and
> thinking you're dead because some home server is
Ok, sorry for not being enough specific. I agree that
it is linked to the NAS, or I whould say, the RADIUS
client that initiated the original request, in the
case where the request goes thourgh several proxies.
We can imagine that several NAS with dirrent
TO/retries are sending packets that comes to
freeradius through a unique RADIUS proxy.
Here is a quick sample of what RADIUS interconnections
can be in our case. Our implemenation is *FreeRADIUS*.
+->RADIUS Server 1 +->RADIUS Server A
| ^ |
+->RADIUS Server 2 | +->RADIUS Server B
+->RADIUS Server 3
In this case, we need to set the expiration time by
identifying the network (1, 2 or 3) that originated
the request (based on RADIUS attributes).
As always, thank you for the answers you gave.
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