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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
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 = "[EMAIL PROTECTED]"
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
