Problem with rml_sqlcounter with GigaByte datavolume

[YvesDM]

On Mon, Jun 6, 2011 at 1:24 PM, Hanno Schupp <hanno.schupp at gmail.com> wrote:

> Thank you for this reply.
>
> I thought the limitation might come from the wrapping around 4.3 GB due to
> the limitations of a 32bit system with 2147483648 being the highest signed
> and 4294967296 being the highest unsigned number. 1705032704 is then exactly
> the difference to 6GB, after the system wrapped at 4.29GB. I requite the
> log:
>
>
>
> Sat Jun  4 23:10:21 2011 : Debug: rlm_sqlcounter: Rejected user lapzel14,
> check_item=1705032704, counter=2147513300
>
>
>
> Exactly the 1705032704 one would expect based on highest 32bit unsigned
> integer.
>
>
>
> Now here is my problem: Why does it wrap at 32Bit, if the system is a x64
> server? Does not make a lot of sense to me.
>
>
>
> Also, the FAQ is containing instructions how to deal with gigawords in
> terms of the sql statements that handel the calculation of the counter
> value. And as this is implemented, the counter value is not the problem here
> – it is the check_item value that as I understand is based on my
> configuration, taken straight out of the radcheck table.
>
>
>
> I am sorry, but this sounds like a limitation/bug of the standard system,
> that could be overcome. After all, if it can be resolved with custom perl
> code as I understand you suggest, why should the standard system not be able
> to handle data limits larger than 4.29GB out of the box?
>
> Or am I missing something?
>
>
>
> Alan, can you enlighten us on this issue?
>
>
>
> Regards
>
>
>
> Hanno
>
>
>
>
>


You confuse gigawords storage in the database coming from acct updates/stop
packets of the nas with the reply from sqlcounter.
FR is capable of saving gigawords in the database when a nas is sending
them, that's not the problem.
But, the sqlcounter's code was never changed to reply gigawords to the nas.
Check the C code and you will see.

Kind regards
Y.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20110606/884b7365/attachment.html>