27-Jan-03 at 16:27, Tim Jung ([EMAIL PROTECTED]) wrote : > Well the issue is that yes you do need everything stored in Rodopi so that > total time for the given period is correct. For example say you limit an > account to 300 hours per month, and they use 295 hours, then call up for 2 > hours hang up, then 2 minutes later call back. The system should know that > they now only have 3 hours left and thus set a session limit of 3 hours. If > the data is not being processed real-time then there is no way for the > RADIUS server to accurately know what the exact limit of the session should > be. Without real-time processing of the RADIUS accounting packets then on > the second call it would think it still had 5 hours left rather than only 3 > hours left.
In my setup, RODOPI creates a users file from Radius attributes specified on a per-plan basis. This users file is only uploaded to the Radius server when there is a change in password or an update to attributes. It is therefore not Rodopi that holds the actual db for users, but the Radius server. Session limits are usually used in the context where someone might only be able to stay online x minutes before having to re-authenticate. Now, if you want a prepaid system where the limit is over a long time (and not just one session) then you have to get a bit cleverer. That means that the Radius server has to keep track of a user's session time over a number of sessions, each time decrementing the remaining time based on online time in previous sessions over a given time period. This is the problem I have been faced with and I don't have an easy solution. Rodopi will not update the users file after every Acct-Stop packet on my setup. This is how I see a possible setup working: - Rodopi creates users file with a Session Time and Date range? - Some selfmade daemon watches the Detail file / SQL server accouting details and decrements the Session Time on each Acct-Stop packet - This goes on until period is up, then the Session Time is reset / expires completely. You still have the problem that a change of password means that Rodopi now gives back a Session Time which is too high. Rodopi says that with Steel-Belted Radius the solution is already set, however this is a commercial solution and I don't want it. If things have changed in a recent Rodopi version I'd like to know. By definition, a "session" is one login/logout. I'm still looking at this. Regards, -- |-Simon White, Internet Services Manager, Certified Check Point CCSA. |-MTDS Internet, Security, Anti-Virus, Linux and Hosting Solutions. |-MTDS 14, rue du 16 novembre, Agdal, Rabat, Morocco. |-MTDS tel +212.3.767.4861 - fax +212.3.767.4863 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
