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@lists.freeradius.org [mailto:freeradius-users-bounces+edvin.seferovic=kolp.at@lists.freeradius.or g] On Behalf Of Tim O'Donovan Sent: Dienstag, 13. Juni 2006 21:19 To: freeradius-users@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@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