Re : Re : Bug on Accouting-Requests proxying
Maybe can you explain us why it SHOULD NOT retransmit accounting packets?
Because the NAS will retransmit them. Having the proxying server re-transmit them, too is unecessary.
I agree on this. Nevertheless (correct me if I'm wrong), when FreeRADIUS acts as a proxy, it can be synchronous or asynchronous, right? We are developping a RADIUS proxy interconnecting many clients to many servers. We need to proxy both authentication and accounting requests. 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).
If the server logs them locally, and then uses something like "radrelay" to proxy them, then radrelay should take care of the retransmits.
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.
Our implementations of FreeRADIUS need to retransmit all types of packets
Why?
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. I hope that you understand the context and our concerns. 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. Best regards and thank you for your great opensource. Geof. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Geoffroy Arnoud <garnoud@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 wrong...
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
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...
I agree with you, and we explained them that allowing bigger TO/retries on proxy to address slow Home AAA won't have any result, because the NAS is the one that controls end-users' traffic. It's just that we are migrating their AAA proxy from an existing non-free RADIUS server to FreeRADIUS, and they want to keep the same features. Anyway. We will do the job for the migration with 1.1.3 and some locally maintained patches. Next we will see how FreeRADIUS evolves, and take it into consideration for next releases. Thanks Geof. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
participants (2)
-
Alan DeKok -
Geoffroy Arnoud