Peculiar Input/Output Octet Data In Alive/Stop Packets

[Tim O'Donovan]

Hi,

The data transfer figures sent in these accounting packets are important 
to us because we have capped services as well as unmetered. Without 
being able to accurately keep track of the data transferred during 
sessions, it is impossible to tell if users are exceeding the caps. This 
in turn means that they can receive the same service as the unmetered 
users at a much cheaper rate.

I have written an application to analyse the incoming alive and stop 
packets to gather the input and output octet values and to produce daily 
transfer statistics. When it determines that a transfer value is of a 
timestamp type, it ignores the data. But as some user's sessions only 
ever receive this type their transfer stats are never updated.


Kind regards,
Tim O'Donovan

Seferovic Edvin wrote:
> Hello,
> 
> is the timestamp in the Accounting packet really important for your
> monitoring puroposes?
> 
> Regards,
> Edvin
> 
> -----Original Message-----
> From: freeradius-users-bounces+edvin.seferovic=kolp.at at lists.freeradius.org
> [mailto:freeradius-users-bounces+edvin.seferovic=kolp.at at lists.freeradius.or
> g] On Behalf Of Tim O'Donovan
> Sent: Dienstag, 13. Juni 2006 21:19
> To: freeradius-users at lists.freeradius.org
> Subject: Peculiar Input/Output Octet Data In Alive/Stop Packets
> 
> Hi,
> 
> The majority of alive and stop packets received by our FreeRadius server
> contain correct input and output octet data, but there are a number of
> users that receive a UNIX time formatted integer translating to midnight
> of the day the packet was received instead of the correct data.
> 
> Here's an example of such a packet, note the output octets:
> 
> Tue Jun 13 16:05:30 2006
>          User-Name = "xxx at xxx"
>          NAS-IP-Address = xxx.xxx.xxx.xxx
>          NAS-Port = 29
>          Service-Type = Framed-User
>          Framed-Protocol = PPP
>          Framed-IP-Address = xxx.xxx.xxx.xxx
>          Proxy-State = 0x42543030326436336366643134
>          Acct-Status-Type = Alive
>          Acct-Delay-Time = 0
>          Acct-Input-Octets = 899858807
>          Acct-Output-Octets = 1150153200
>          Acct-Session-Id = "0002576E"
>          Acct-Authentic = RADIUS
>          Acct-Session-Time = 1583103
>          Acct-Input-Packets = 7437599
>          Acct-Output-Packets = 8973389
>          NAS-Port-Type = Virtual
>          Client-IP-Address = xxx.xxx.xxx.xxx
>          Acct-Unique-Session-Id = "372fc40c32b2b500"
>          Timestamp = 1150211130
> 
> 
> The output octets figure 1150153200 translates to Tue Jun 13 00:00:00
> 2006 GMT.
> 
> We currently do not have direct access to the NAS servers that are
> sending across this data, but we have worked together with our provider
> towards replicating this through testing. In each case the expected data
> is reported and we have yet to reproduce the error manually.
> 
> As the data transfer has only recently become an area we wish to monitor
> and log, it is impossible to tell whether this has always been occurring.
> 
> Has anyone experienced this before?
> 
> Any help or advice would be greatly appreciated.
> 
> 
> Kind regards,
> Tim O'Donovan
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> - 
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
> 
> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>