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