Hello, We are developping a RADIUS platform for our customer based on FreeRADIUS 1.1.3. We plan to patch the kernel code to implement a timeout/reries configuration per realm, for the RADIUS proxy feature. I saw in the archive that some time ago, someone planned to perform this modification (http://lists.freeradius.org/mailman/htdig/freeradius-devel/2004-October/0075...). I am wondering if such a patch is available? If not, we will develop it and provide it to the community. For this purpose, we may need some tips on how proxy is implemented, in terms of configuration and behaviour (for example, How is managed timeout detection for a given request?). Furthermore, are there tests suite available on the server kernel so we can perform/enhance them to check non-regression? Any information will be welcome. Best regards, Geoff.
Geoffroy Arnoud <garnoud@yahoo.co.uk> wrote:
I am wondering if such a patch is available? If not, we will develop it and provide it to the community.
I haven't seen a patch.
For this purpose, we may need some tips on how proxy is implemented, in terms of configuration and behaviour (for example, How is managed timeout detection for a given request?).
Don't bother with that, just set the timeout per realm in src/main/proxy.c, proxy_send(). The total amount of work is probably less than 100 lines.
Furthermore, are there tests suite available on the server kernel so we can perform/enhance them to check non-regression?
Uh... no. That would be a great idea, though. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
I took a rapid look to the code (on a 1.1.2 I have on my desktop), and I looked into proxy_send. Globally, is it just a matter of changing those 2 lines: request->proxy_try_count = mainconfig.proxy_retry_count - 1; request->proxy_next_try = request->timestamp + mainconfig.proxy_retry_delay; with new configuration parameters? (impacts on config.c of course!) I think that proxy_next_try will have to get updated further for next retransmissions. I'll find it for sure! Thanks for your answer. Geoff.
Geoffroy Arnoud <garnoud@yahoo.co.uk> wrote:
I took a rapid look to the code (on a 1.1.2 I have on my desktop), and I looked into proxy_send. Globally, is it just a matter of changing those 2 lines:
request->proxy_try_count = mainconfig.proxy_retry_count - 1; request->proxy_next_try = request->timestamp + mainconfig.proxy_retry_delay;
with new configuration parameters? (impacts on config.c of course!)
Yes. The REALM structure should have two new entries added, with default value of -1. The proxy_send code should use the REALM values, unless they're -1, in which case it should use the global configq.
I think that proxy_next_try will have to get updated further for next retransmissions. I'll find it for sure!
Ok. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (2)
-
Alan DeKok -
Geoffroy Arnoud