Bug on Accouting-Requests proxying

Alan DeKok aland at deployingradius.com
Wed Nov 1 05:40:58 CET 2006

Geoffroy Arnoud <garnoud at yahoo.co.uk> wrote:

> I agree on this. Nevertheless (correct me if I'm wrong), when
> FreeRADIUS acts as a proxy, it can be synchronous or asynchronous,
> right?

  Yes, but I'm starting to think that's wrong.  The server should just
act synchronously.  It's a LOT easier on the server, and can't be

> We need to set different timeout and retransmit per realm (customer
> request / patch under contruction).
> Using NAS restransmissions as you suggest supposes to be
> synchronous, but we need asynchronous behaviour (different TO /
> retries per realm - independant from the client).

  Why?  OK, the customers request it, that's nice... but why?  What
problem do they think it solves?

  I really don't think per-realm asynchronous retransmits help.  I
just don't see why they would matter to the home server.  Retransmits
matter to the NAS, but the NAS controls it's retransmissions...

> Using radrelay may prove to be interesting, but was not considered
> useful because, at design time, we thought FreeRADIUS did respect RFC
> regarding retransmissions of accounting requests. Maybe in a future
> release of the project, we can think about using radrelay, but not for the
> moment.

  So maintain local patches.

> For accounting requests, if retransmissions are not managed, this
> may result in billing issues for operators. Interconnection rules
> tell that if more than a number a accounting interim are missing,
> then it means that end-user session is over and that session can be
> terminated and billed. If session is not really terminated, this
> leads to a revenue loss.

  Yes, but that's what radrelay is for.  If you're using the proxy
RADIUS server as a buffer for accounting packets, then it should log
the packets, and do nothing else.  A separate process should then
forward the packets, and that process should do retransmits.

> Nevertheless, we are not in position to tell you what to do or not
> in the server, but we hope that such a modification (no proxy of
> accounting) will be marked as a major update of the server in the
> release notes.

  I think you misunderstood what I said.  I did NOT say that the
server would stop proxying accounting packets.  That would be stupid.
I *did* say it would stop handling the retransmits itself.

  If the home server doesn't respond to the proxy, then the proxy
won't respond to the NAS, and the NAS will re-transmit, and the proxy
will forward the new packet.

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

More information about the Freeradius-Devel mailing list