Freeradius proxy code questions and proposed patch

[Alan DeKok]

Kostas Zorbadelos wrote:
> I had described a strange behavior in our large proxy setup. After
> running the server in debug mode (radiusd -xxx) in our production
> systems we found out what was causing our problems. The problem was
> that the home server in our proxy setup was marked dead quite often
> during the day and with a dead_time of 30 secs every request that came
> within these 30 secs was rejected.

  Yes.  In 1.x, the proxy code does this.  It's fixed in 2.0, which
should be released real soon now.

> +                       /*
> +                        * If we are running in synchronous proxy mode, there's no point marking the target
> +                        * server(s) dead, since this should be done by the radius client

  Uh, no.  The RADIUS client doesn't know about the home servers.  It
only knows about the server it's sending packets to.

> The purpose of this patch is to not have the freeradius server mark
> the home server dead when working in synchronous mode. We believe that
> in synchronous operation it is a good idea to leave the job of marking
> the server dead to the NAS client.

  Which server?  All your patch does is make sure that the NAS marks the
proxying server as dead.

...
> It seems that in some "strange" occations the code enters the above
> path. A decision is made in case the current time is older than
> mainconfig.proxy_retry_delay * mainconfig.proxy_retry_count. If this
> is the case, the request is rejected and the code tries to disable the
> realm. However in the proxy.conf configuration file it is mentioned:

  All of that code is *gone* in 2.0.  The new code is so much better
that it's really quite hard to describe how much better it is.

> Please let me know your thoughts on these matters (also on the patch
> we provide)

  Take a look at the current CVS snapshot.  It should be pretty robust
with some recent bug fixes, and it will solve *all* of your proxying
problems.

  And I do mean ALL of the problems.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog