Managing Data Volume Control More Than 4GB FR & CoovaChilli

Russell Mike radius.sir at gmail.com
Tue Oct 8 16:40:39 CEST 2013


Dear Arran C. Bell,

Thank you very much, i am extremely grateful for your advise and guidelines
for troubleshoot also. i am currently experimenting a different
rlm_sqlcounter using CoovaChilli dictionary "All-In-MB". In result, i can
store short number in db. This counter would reset at 2TB with same 32bit
number. i have actually tested up to 6GB. it just works!!!. Next test is in
progress to logout user when 7GB downloaded. i really appreciated your
input and TIME.

i will try your proposed solution as well after "All-In-MB" has tested. After
the successful practical of both solutions. i would like to document this
topic on one page for archives, so that it can help others. i may need your
support incase i came across some challenges during the test of your
solution.

Thanks once again !!!

Regards --RM




On Tue, Oct 8, 2013 at 12:16 PM, Arran Cudbard-Bell <
a.cudbardb at freeradius.org> wrote:

> >
> >
> > It might actually be an idea to add those to the internal dictionary to
> make it a bit easier.
>
> Just to clarify there are two reasons why your current config isn't
> working:
> 1. rlm_sql stores the value as a proper 64bit integer, not in the two
> 32bit chunks represented by Acct-Input-Gigawords and Acct-Input-Octets.
> When this value is pulled out into rlm_sqlcounter the value is truncated
> because internally it only deals with 32bit unsigned ints. I've now fixed
> this.
>
> 2. You're comparing gigawords to bytes, with no conversion, so even with
> the updated module you'll find the user is rejected way way too early.
>
> You also invented "counter-type" and "check-unit" config pairs. The server
> isn't magic, just because it doesn't error out, doesn't mean it knows about
> those config pairs or will use values assigned to them.
>
> Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> FreeRADIUS Development Team
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20131008/b973e5a5/attachment.html>


More information about the Freeradius-Users mailing list