[RADIATOR] Top level radius servers problems

[Heikki Vatiainen]

On 05/25/2011 01:39 PM, Esmeralda Pires wrote:

Hello Esmeralda,

> We add to all our peers handler configurations a “NoReplyHook”
> (Paul Dekkers from Surfnet is also helping us on this problem)

I have attached another version of a NoReplyHook. This is from the
Finnish eduroam root that I am also involved with. This version tries to
handle Proxy-State attribute (generated by UseExtentedIds in Radiator)
and shows how to call AuthLog clauses to log the generated reject.

If someone enhances the hook, please post the changes to the list too.

> We have already try to check the values of “Retries” and “RetryTimeout” 
> from our radius institutions, we have recommend this values:
> • RetryTimeout ( 5s)
> • Retries ( 0 or 1)
> Do you have any recommendations on this?

eduroam cookbook has this:
RetryTimeout          3
Retries               1
FailureBackoffTime    0

In my opinion this looks good. If the timeout was from a random packet
loss, then a quick single retry should take care of the problem.
Otherwise there is the possibility there will never be a reply, at least
within a reasonable time that a human is willing to wait.

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: proxyTimedOutHook.pl
Type: application/x-perl
Size: 1309 bytes
Desc: not available
Url : http://www.open.com.au/pipermail/radiator/attachments/20110525/4f8c7bd9/attachment.bin