(RADIATOR) Inconsistant Accounting with MySQL

[Hugh Irvine]

Hello Michael -

This looks to me like a problem with signed and unsigned 32 bit  
integers.

How are your database columns defined? And have you tested the  
inserts manually to see where the problem is occurring?

regards

Hugh


On 16 Mar 2006, at 12:20, Michael Priest wrote:

> After looking at some of the accounting data generated by radiator  
> I was noticing what seemed to be very strange accounting for  
> generic data usage some counters seemed to stop at exactly 2048MB  
> (2147483647 Bytes it isn’t happening all the time I have seen  
> records exceed 2048mb and Create Giga-Word Values how ever this  
> seems to be happening frequently and I just don’t understand why.
>
>
>
> I've tracked down the following information:
>
>
>
>
>
> Part of the Radiator log which indicates my periodic update from  
> our LNS
>
>
>
>       Acct-Session-Time = 137632
>
>       Acct-Input-Octets = 259766795
>
>       Acct-Output-Octets = 4001408988
>
>       Acct-Input-Packets = 3056688
>
>       Acct-Output-Packets = 4747255
>
>       Acct-Status-Type = Alive
>
>
>
> Thu Mar 16 11:37:16 2006: DEBUG: do query is: 'insert into  
> ACCOUNTING  
> (ACCTDELAYTIME,ACCTINPUTOCTETS,ACCTOUTPUTOCTETS,ACCTSESSIONID,ACCTSESS 
> IONTIME,ACCTSTATUSTYPE,FRAMEDIPADDRESS,NASPORT,TIME_STAMP,USERNAME)  
> values (0,259766795,4001408988,'00000005', 
> 137632,'Alive','ip.ip.ip.ip',3,1142469436,'xxxxxxx at xxxxxx')':
>
>
>
> Data on our LNS Shows much the same to above.
>
>
>
> LNS-SYD-01#sh caller user xxxxxxx at xxxxxx
>
>
>
>   User: xxxxxxx at xxxxxx, line Vi5, service PPPoVPDN
>
>         Connected for 1d14h, Idle for 1d14h
>
>   Timeouts:    Limit     Remaining Timer Type
>
>                -         -         -
>
>   PPP: LCP Open, multilink Closed, CHAP (<-), IPCP
>
>   IP: Local ip.ip.ip.ip, remote ip.ip.ip.ip
>
>   Counts: 3085920 packets input, 262376691 bytes, 0 no buffer
>
>           0 input errors, 0 CRC, 0 frame, 0 overrun
>
>           4787632 packets output, 4027949729 bytes, 0 underruns
>
>           0 output errors, 0 collisions, 0 interface resets
>
>
>
>
>
>
>
> Now all of that matches up except for the odd time difference  
> except for a little bit of time difference between the results, now  
> this is where it just doesn’t make sense once I look in the  
> database I see the following. This record below is exactly the same  
> as the log above indicates should have been inserted.
>
>
>
> mysql> SELECT USERNAME, TIME_STAMP, ACCTINPUTOCTETS,  
> ACCTOUTPUTOCTETS FROM `ACCOUNTING` where username =  
> 'xxxxxxx at xxxxxx' and time_stamp = '1142469436';+-------------------- 
> +------------+-----------------+------------------+|  
> USERNAME           | TIME_STAMP | ACCTINPUTOCTETS |  
> ACCTOUTPUTOCTETS |+--------------------+------------ 
> +-----------------+------------------+| xxxxxxx at xxxxxx     |  
> 1142469436 |       259766795 |       2147483647 | 
> +--------------------+------------+----------------- 
> +------------------+1 row in set (0.00 sec) As you can see the  
> Output-Octets are completely wrong, and if I pull back the previous  
> few Accounting updates I see this.  +-------------------- 
> +------------+-----------------+------------------+|  
> USERNAME           | TIME_STAMP | ACCTINPUTOCTETS |  
> ACCTOUTPUTOCTETS |+--------------------+------------ 
> +-----------------+------------------+| 0294519111 at hotline |  
> 1142469436 |       259766795 |       2147483647 ||  
> 0294519111 at hotline | 1142468585 |       254452546 |        
> 2147483647 || 0294519111 at hotline | 1142467647 |       248165578  
> |       2147483647 || 0294519111 at hotline | 1142466773 |        
> 241210305 |       2147483647 || 0294519111 at hotline | 1142465842  
> |       236030193 |       2147483647 || 0294519111 at hotline |  
> 1142464941 |       230506303 |       2147483647 ||  
> 0294519111 at hotline | 1142464024 |       224926037 |        
> 2147483647 || 0294519111 at hotline | 1142463160 |       221474014  
> |       2147483647 || 0294519111 at hotline | 1142462264 |        
> 219840952 |       2147483647 || 0294519111 at hotline | 1142461335  
> |       218378041 |       2147483647 || 0294519111 at hotline |  
> 1142460418 |       217118361 |       2147483647 ||  
> 0294519111 at hotline | 1142459507 |       215858539 |       2147483647 |
> +--------------------+------------+----------------- 
> +------------------+
>
>
>
>
>
> Any help on this would be appreciated.
>
>
>
> Cheers,
>
> Michael
>
>


NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.