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