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

[Geoffroy Arnoud]

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


NAS1
 |
 +->RADIUS Server 1        +->RADIUS Server A
     |                     |
     +->RADIUS proxy-->*FreeRADIUS*
     |                  ^      |
 +->RADIUS Server 2     |      +->RADIUS Server B
 |                      |
NAS2                    |
                        |
             +->RADIUS Server 3
             |
            NAS3


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.

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