2012-06-19 - Re: [GRASE-Hotspot] 5Gb ticket problem

Header Data

From: Timothy White <ti***8@gmail.com>
Message Hash: 01af762cdaefb1cf75a8a8ee5d2006ac1df10e99fab1f7a98f339a5fb49f0a1f
Message ID: <CAESLx0Lt16q7d6UmzHnc=r9EUoVrvz0mMbtw9qM76kgPvP75ow@mail.gmail.com>
Reply To: <1F5DC1C2-DBCF-4770-816C-DA871ABD4936@gmail.com>
UTC Datetime: 2012-06-19 23:10:36 UTC
Raw Date: Wed, 20 Jun 2012 14:10:36 +0800

Raw message 

On Wed, Jun 20, 2012 at 12:48 PM, Hanno Schupp <ha***p@gmail.com> wrote:
> Hi Tim,
>
> You are right, the old problem with the ~2.15GB limit related to the actual data traffic counter; this has been resolved and there is no issue. I have users with hundreds of GB of data consumption being recorded over a few months, no problem.
>
> The remaining ~4.3GB issue relates to the data limit stored in radcheck. It appears that while on a 64bit system there is no issue storing the data limit number, as the variable is not stored with appropriate length the comparison fails. Aparently this has not even been resolved in freeradius 3.
>
> Unless you speak C and mod freeradius (is that advisable) you need to write your own freeradius module in perl or php and perform that check yourself in your custom code, return a return-code to freeradius that confirms whether or not the check was successful and what the remaining data volume is. You can write and link your own modules in freeradius without having to alter the core code.

Thankfully I do speak C, so will probably just patch rlm_sqlcounter
which is where the problem appears to be. (The MySQL database can
store the numbers fine on both 32bit and 64bit systems). I really
don't want a non-standard module, so patching the rlm_sqlcounter is
the best way forward, even if it doesn't get included in upstream for
sometime.
I believe some of the work was done in freeradius 3 to fix the
problem, just not enough.

Tim

Thread