Problem with rml_sqlcounter with GigaByte datavolume

[Suman Dash]

It is a matter which needs attention of Alan or Arran. Kindly send a Bug
Report so that this situation can be evaluated by the developers.

On Wed, Sep 14, 2011 at 6:29 PM, nfourel <nicolas.fourel at adipsys.com> wrote:

> I have the same result with integer rather than integer64. I tried on a 32
> bit server, and indeed, if I put a value bigger than 2^32 octets in
> Max-Input-Octets check-item, it wraps to 4294967295 octets and not to zero.
> So the problem seems to be with 64bit architecture and value bigger than
> 2^32 octets (like 100GB). Very strange behavior.****
>
> ** **
>
> Nicolas****
>
> ** **
>
> *De :* Suman Dash [via FreeRadius] [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=4802672&i=0>]
>
> *Envoyé :* mercredi 14 septembre 2011 14:53
>
> *À :* nfourel
> *Objet :* Re: Problem with rml_sqlcounter with GigaByte datavolume****
>
> ** **
>
> I have a working setup which takes Check-Item over 100GB But being a 32Bit
> counter is wraps in 2GB limit. I have not tried Integer64. Can you check
> what happens when you change it to 32bit in dictionary instead of declaring
> it as 64bit ?
>
>
> ****
>
> On Wed, Sep 14, 2011 at 5:53 PM, nfourel <[hidden email]<http://user/SendEmail.jtp?type=node&node=4802642&i=0>>
> wrote:****
>
> The « check_item=0 » is reason why I posted my messages on this ML. If I
> put a value lesser than 2^32 (for example 1000000) for “Max-Input-Octets” in
> radcheck for username ‘click here. ****
>
> ------------------------------
> View this message in context: RE: Problem with rml_sqlcounter with
> GigaByte datavolume<http://freeradius.1045715.n5.nabble.com/Problem-with-rml-sqlcounter-with-GigaByte-datavolume-tp4455164p4802672.html>
> Sent from the FreeRadius - User mailing list archive<http://freeradius.1045715.n5.nabble.com/FreeRadius-User-f2740693.html>at Nabble.com.
>
> -
> 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/20110914/03a60292/attachment.html>