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

Geoffroy Arnoud garnoud at
Fri Nov 17 08:08:18 CET 2006

--- Alan DeKok <aland at>:

> Geoffroy Arnoud <garnoud at> 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
> down.
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 proxy-->*FreeRADIUS*
     |                  ^      |
 +->RADIUS Server 2     |      +->RADIUS Server B
 |                      |
NAS2                    |
             +->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 mailing list