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@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