sqlcounter returning wrong value?

tnt at kalik.net tnt at kalik.net
Thu Oct 30 22:09:39 CET 2008


It does make sense. rlm_sqlcounterworks like this toward the time of the
reset: lets say you have an hour left, your limit is 20 hours and you
have signed in 15 minutes before counter reset time.  When code
calculates that you can be online at reset time it doesn't return your
allowance (1 hour) but adds the limit for the next conting period (20
hours) to the remaining time (15 minutes) and returns that value (20
hours and 15 minutes). Reasoning is that your session shouldn't be
discontinued after an hour becouse 15 minutes into the session new limit
should come into force (and session limit can't be changed during the
session).

In your case there is about 2,000,000 left on the counter but only a few
thousand seconds left to the end of the reset period, so code will add
those few thousands to the next period limit (26,000,000) and return
that value. Code doesn't "know" are you counting data or time as
there is  no such configuration item.

Venkatesh had posted the patch that switches off this peace of code for
data counters by introducing that configuration item. You should try it.

Ivan Kalik
Kalik Informatika ISP


Dana 30/10/2008, "liran tal" <liransgarage at gmail.com> piše:

>Well, taking this issue back to the begining - it all started with my report
>that using the attribute Chilli-Max-Total-Octets
>in the sqlcounter provided as follows yields wrong results for all of the
>reset times (daily/weekly/monthly):
>
>        sqlcounter counterChilliSpotMaxDailyOctets {
>                counter-name = ChilliSpot-Max-Daily-Octets
>                check-name = ChilliSpot-Max-Daily-Octets
>                reply-name = ChilliSpot-Max-Total-Octets
>                sqlmod-inst = sql
>                key = User-Name
>                reset = daily
>                error-msg = "Sorry, your maximum traffic usage (download and
>upload) has exceed the provided limit"
>                query = "SELECT (SUM(AcctInputOctets + AcctOutputOctets))
>FROM radacct WHERE UserName='%{%k}' AND UNIX_TIMESTAMP(AcctStartTime) +
>AcctSessionTime > '%b'"
>        }
>
>For a user defined with the following entry in radcheck:
>| 346 | tester1 | ChilliSpot-Max-Daily-Octets | := | 26214400 |
>
>The result returned by freeradius is:
>check_item=26214400 and counter=24004370, return value=26239950 (which makes
>no sense).
>
>
>
>Regards,
>Liran.
>
>
>2008/10/30 Venkatesh K <kaevee at gmail.com>
>
>> The patch I posted was out of the hat just to skip the routine
>> which adds additional quota.
>>
>> We have stopped using rlm_sqlcounter long back as we moved
>> from radius schema to our own custom schema and patched
>> the rlm_sql to work with our custom schema.
>>
>> If you or someone list out what one would like to see in rlm_sql_counter,
>> I will try to come up with the patch. Back porting to previous versions
>> of radius should not be a big problem as rlm_sql and rlm_sqlcounter
>> have't changed much.
>>
>> Thanks,
>>
>> Venkatesh K
>>
>>
>
>




More information about the Freeradius-Users mailing list