radrelay in 1.1.x and in 2.x

[Alan DeKok]

Geoffroy Arnoud wrote:
> There's a program named radrelay in branch_1_1 and there's a way
> of launching FreeRADIUS in HEAD that is called 'radrelay'.
> 
> It seems that the difference between them is that radrelay program
> disappeared to be merged with radiusd.

  Yes.

> Are the behaviours of radrelay program and radiusd/radrelay different.

  The functionality is similar, the behaviors are different.

  In 1.1.x, if you want to log to a "detail" file, and then later write
that information to SQL, you would need a radiusd to write the detail
file, radrelay to read it, and another radiusd to accept the packets
from radrelay, and write them to SQL.

  In 2.0, the two "radrelay + radiusd" programs have been replaced with
"radiusd -n radrelay".  With slightly more work, all of that could be
replaced by one copy of radiusd, which would be much better.

> It seems that radrelay program sends the request to only one radius
>  server until it gets a response and that the requests are sent
> to the same server.

  Yes.

> For radiusd/radrelay, it seems that the behaviour is configurable
> with modules and so on, but, is the proxy behaviour different?

  No.  FreeRADIUS can send a packet to one home server, and only one
home server.

> My problem is that I would like to send accounting requests the
> more reliably as possible. I mean that if I have 3 remote
> servers for a given realm and that at east one is available,
> I want my accounting request to be sent to the alive server.
> FreeRADIUS could try the first remote server, if dead, try
> the second server, if dead try the last server...

  That failover is already part of radiusd.  The re-transmission of
accounting requests when there's no response SHOULD be part of the new
"integrated radrelay" code, but it isn't there yet.  It shouldn't be too
hard to add, though...

> For accounting, this has 2 main advantages:
> - If at least one remote server is up, the request is delivered
> - If several remote servers are dead, they are all marked dead
> with only one accounting request

  It will take more than that.  You don't want to mark a server dead if
it doesn't respond to *one* packet.  But I do know what you mean...

> For authentication request, our position is that synchronous proxy
> is the best approach - given that dead server timers can evolve
> to become very flexible (per NAS, based on RADIUS request content...).

  Yes.

> Maybe this is not very complicated to implement, with a well
> written module and a small modification of proxy code
> in request_list.c?

  That code is being re-written in the CVS head.  It will be infinitely
better than what's there now.  i.e. simpler, smaller, easier to
understand, and with more functionality.

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