Proxying accounting to create a 'tee'

[Arran Cudbard-Bell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/08/2009 18:17, Fajar A. Nugraha wrote:
> On Sun, Aug 23, 2009 at 11:54 PM, Ivan Kalik<tnt at kalik.net> wrote:
>>> On Sat, Aug 22, 2009 at 5:53 PM, Arran
>>> Cudbard-Bell<a.cudbard-bell at sussex.ac.uk> wrote:
>>>> Fajar A. Nugraha wrote:
>>>>> In that setup, where does one get AcctStartTime and AcctStopTime
>>>>> values?
>>>
>>>> Or just use whatever functions are available in your scripting
>>>> environment.
>>>>> - is it from the NAS?
>>>>>
>>>> No, the NAS doesn't include any timestamps.
>>>
>>> Your answer is the complete opposite of Ivan's response :D So which
>>> one is correct?
>>
>> His. Packet timestamp is generated by radius server.
>>
> 
> So %S in dialup.conf is packet timestamp, and if I'm reading from
> detail file I should make use of the attribute
> Packet-Original-Timestamp (or similar) to get the real packet
> timestamp?
> 

No, that'll get you the timestamp of when the packet was read back into the server. The only way to calculate the original received timestamp is to write the original Acct-Delay-Time into a custom
attribute (say Acct-Delay-Time-Orig), subtract that from the current Acct-Delay-Time, then that from the current UNIX timestamp.

received_time = current_unix_ts - (Acct-Delay-Time - Acct-Delay-Time-Orig)

If you just want an accurate start time, you need to subtract Acct-Delay-Time from the current timestamp.

start_time = current_unix_ts - Acct-Delay-Time

See it's all pretty simple :) You can do the above calculations with the expressions module (expr) which operates in pretty much the same way as the TCL expressions module.

> Thanks for the help. I'm trying to deploy a setup similar to John's,
> proxying acct packets only, where proxying failure should not affect
> response to the NAS. Decoupled accounting along with getting the
> original packet timestamp seems to be the key of getting this right.
> 

Yeah it's a pretty common setup, we do it too. One thing you have to watch out for is  packets with fatal errors. Where the remote accounting server never acknowledged receipt of the packet, so it
gets stuck in an infinite loop in the proxying queue.

I haven't figured out how to solve this properly with the current setup, so it'd be good to see some discussion on list about it.

- -- 
Arran Cudbard-Bell <A.Cudbard-Bell at sussex.ac.uk>,
Systems Administrator (AAA),
Infrastructure Services (IT Services),
E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT
DDI+FAX: +44 1273 873900 | INT: 3900
GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqSh58ACgkQcaklux5oVKJ2dwCfRfTa/8sX9l1UzzGOmErC0d6E
pfYAn2cJc/RZvOog6r2mAW2xbo96upaV
=/n/e
-----END PGP SIGNATURE-----