Peculiar Input/Output Octet Data In Alive/Stop Packets

Seferovic Edvin edvin.seferovic at kolp.at
Wed Jun 14 01:09:58 CEST 2006


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




More information about the Freeradius-Users mailing list