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