Hi Yves,<br>thanks for your response. I understand the difference between the storing gigawords in the database and the sqlcounter response. I do not speak C, but have no doubt that what you are saying is correct. I just find it hard to believe that FreeRadius has such a basic limitation, which it appears can be easily overcome (if you can do so with a PERL script using rlm_perl, it must be possible to do it with C in rlm_sqlcounter, right), but so far no one has bothered to address. While this might have been OK in former times, when data traffic was expensive and limited, in a broadband scenario multi GigaByte data allowances over 4GB per month are very common, and I am gobsmacked that FreeRadius cannot handle what seems a very basic requirement.<br>
<br>So accepting the point that this is a limitation of FreeRadius in its current version, I reword my question to Alan:<br>Are there any plans to address this shortcoming of FreeRadius in the near future?<br><br>Failing that, are there any rlm_perl scripts out there on the wiki or in the wider user community, that can handle gigawords on the radcheck values that actual usage is checked against? My language is PHP and I know from experience that while PHP code can be embedded into FreeRadius, it is probably the least performing option. So I would love to avoid to roll my own in PHP, if at all possible.<br>
<br><br><br>YvesDM wrote:<br><br>You confuse gigawords storage in the database coming from acct updates/stop packets of the nas with the reply from sqlcounter.<br>
FR is capable of saving gigawords in the database when a nas is sending them, that's not the problem. <br>But, the sqlcounter's code was never changed to reply gigawords to the nas. Check the C code and you will see.<br>
<br>Kind regards<br>Y. <br><br><br>On Mon, Jun 6, 2011 at 1:24 PM, Hanno Schupp <span dir="ltr"><<a href="mailto:hanno.schupp@gmail.com" target="_blank">hanno.schupp@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div lang="EN-NZ"><div><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)">Thank you for this reply.</span></p><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)">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:</span></p>
<div><p class="MsoNormal"> </p><p class="MsoNormal">Sat Jun 4 23:10:21 2011 : Debug: rlm_sqlcounter: Rejected user lapzel14, check_item=1705032704, counter=2147513300</p><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)"> </span></p>
</div><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)">Exactly the 1705032704 one would expect based on highest 32bit unsigned integer.</span></p><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)">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.</span></p><p class="MsoNormal">
<span style="font-size:11pt;color:rgb(31, 73, 125)"> </span></p><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)">Also,
the FAQ is containing instructions how to deal with gigawords in terms
of the sql statements that handle 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. </span></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)"> </span></p><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)">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? </span></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)">Or am I missing something?</span></p><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)"> </span></p><p class="MsoNormal">
<span style="font-size:11pt;color:rgb(31, 73, 125)">Alan, can you enlighten us on this issue?</span></p><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)"> </span></p><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)">Regards</span></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)"> </span></p><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)">Hanno</span></p><p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125)"> </span></p></div></div></blockquote><br>