Bug on Accouting-Requests proxying
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,
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
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.
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
More information about the Freeradius-Devel