[Chilli] daily reset changes counter behaviour

[Daniel Collier]

Hi all,

coovachilli version 1.3, freeradius version 2.1, OS ubuntu 12.04

I'm not sure if this is the right place to bring this up, it may be better
with the freeradius people, please let me know if so.

I am using sql accounting and i have defined a custom counter called
input-octets in counter.conf, it works nicely when the reset value is set
to never but changing reset to daily changes its behaviour in a way that i
find difficult to understand. The counter is based on the
ChilliSpot-Max-Input-Octets value and in the radgroupcheck table i have
ChilliSpot-Max-Input-Octets := 10000000.

debug output should tell the story;

with 'reset' set to never
Fri Mar  1 19:54:11 2013 : Info: [input-octets] expand: %{sql:SELECT
SUM(AcctInputOctets) FROM radacct WHERE UserName='alice' AND acctstarttime
> CURDATE()} -> 354144
Fri Mar  1 19:54:11 2013 : Debug: rlm_sqlcounter: Check item is greater
than query result
Fri Mar  1 19:54:11 2013 : Debug: rlm_sqlcounter: Authorized user alice,
check_item=10000000, counter=354144
Fri Mar  1 19:54:11 2013 : Debug: rlm_sqlcounter: Sent Reply-Item for user
alice, Type=ChilliSpot-Max-Input-Octets, value=9645856

with 'reset' set to daily
Fri Mar  1 19:57:03 2013 : Info: [input-octets] expand: %{sql:SELECT
SUM(AcctInputOctets) FROM radacct WHERE UserName='alice' AND acctstarttime
> CURDATE()} -> 365632
Fri Mar  1 19:57:03 2013 : Debug: rlm_sqlcounter: Check item is greater
than query result
Fri Mar  1 19:57:03 2013 : Debug: rlm_sqlcounter: Authorized user alice,
check_item=10000000, counter=365632
Fri Mar  1 19:57:03 2013 : Debug: rlm_sqlcounter: Sent Reply-Item for user
alice, Type=ChilliSpot-Max-Input-Octets, value=10014577

If you look at the value sent as the reply item in the first instance the
result pulled from the radacct table is subtracted from the check value, in
the second instance it is... weird.

Obviously i do not need to use the daily reset as i have worked around it
bysubstituting the unlang version of the date variable for the mysql one,
but still it would be nice to know what is going on here for future
reference.

regards

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.coova.org/pipermail/chilli/attachments/20130301/7eb316ce/attachment.html>