Hello everyone - There have been a number of questions recently about the way Radiator handles radius accounting requests, specifically multiple accounting records inserted into accounting databases. I thought it might be useful to explain exactly why this occurs, and how it should be dealt with. Firstly, the radius protocol is based on UDP, which means that radius packets can and do go missing from time to time. The radius protocol has a mechanism to deal with this, with retransmissions, which normally can be configured with a delay time and number of retries. When a retransmission of an accounting packet occurs, the Acct-Delay-Time attribute is set to the number of seconds that have passed between the actual accounting event occuring and the retransmission being sent. This is to allow downstream billing systems to understand what has happened and to deal with potential multiple accounting records. Note that all of the information in the accounting packet will be identical except for the Acct-Delay-Time value, which will result in a new radius identifier being inserted in the retransmitted packet. Secondly, Radiator, as a radius server is configured to do certain things, including writing accounting records. Specifically, Radiator is configured to write accounting records to an accounting database (of whatever form), which is what it does. Note that Radiator does not try to do anything special with retransmitted accounting records - it just writes them to whatever database has been specified. This is because, as mentioned above, the radius packet identifier will have changed due to the different value of the Acct-Delay-Time attribute, so to Radiator, it is just another packet. So what does all this mean? Simply that it is the job of the billing system that processes the accounting data to detect (and ignore) duplicate accounting records that have Acct-Delay-Time's indicating that these are retransmitted accounting packets for records that have already been processed. All of the commercial ISP billing packages do this as a matter of course. Note that this is simply the way things are, due to the design of the radius protocol. Hopefully this clarifies things a little, and if anyone has any further questions, I'm always happy to assist. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
